Question about the getchar() and eof !!!...

Discussion in 'C Programming' started by neras, Mar 15, 2006.

  1. neras

    neras Guest

    Hi..
    I can't well english..i'm korean;...

    At first,, You see the my source.

    -----------------------------------------------
    int main(void)
    {
    long nc=0;
    while( getchar()!=EOF )
    ++nc;
    printf("%ld\n",nc);
    return 0;
    }
    --------------------------------------------------------
    It is very short.
    I thinking the result but my thinking not like compiler;

    123ctrl+z123enter
    I Thinking the print 3 and program is exit.
    But program is not exit;

    and I add the 3 line the at like bottm
    123ctrl+z123enter
    123ctrl+z123enter
    123ctrl+z1231enter
    ctrl+zenter

    It Was Succed the program exit;
    Result is 12.

    Why don't the program was exit at first line ???
    Why result is 12????
    Is EOF at first in line???

    Thx.
    neras, Mar 15, 2006
    #1
    1. Advertising

  2. "neras" <> wrote in news:1142427532.205087.326390
    @e56g2000cwe.googlegroups.com:

    > -----------------------------------------------
    > int main(void)
    > {
    > long nc=0;
    > while( getchar()!=EOF )
    > ++nc;
    > printf("%ld\n",nc);
    > return 0;
    > }
    > --------------------------------------------------------
    > It is very short.
    > I thinking the result but my thinking not like compiler;


    This has nothing to do with the compiler.

    > 123ctrl+z123enter
    > I Thinking the print 3 and program is exit.
    > But program is not exit;
    >
    > and I add the 3 line the at like bottm
    > 123ctrl+z123enter
    > 123ctrl+z123enter
    > 123ctrl+z1231enter
    > ctrl+zenter
    >
    > It Was Succed the program exit;
    > Result is 12.
    >
    > Why don't the program was exit at first line ???


    Because that is just the way it works on Windows: You need to enter
    CTRL-Z all by itself on a line to signal end of console input.

    Sinan


    --
    A. Sinan Unur <>
    (remove .invalid and reverse each component for email address)

    comp.lang.perl.misc guidelines on the WWW:
    http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
    A. Sinan Unur, Mar 15, 2006
    #2
    1. Advertising

  3. neras

    Suman Guest

    neras wrote:
    > Hi..
    > I can't well english..i'm korean;...

    Welcome!

    > At first,, You see the my source.
    >
    > -----------------------------------------------
    > int main(void)
    > {
    > long nc=0;
    > while( getchar()!=EOF )


    My compiler (gcc version 3.3.3) doesn't like this line and has enough
    to crib:
    [1] warning: implicit declaration of function `getchar'
    which means, you need a prototype in scope for
    getchar()
    [2] error: `EOF' undeclared (first use in this function)
    and that, it has no idea what EOF is.
    So, to fix them, do a #include <stdio.h> anywhere before you use
    EOF/getchar()/
    printf() where it will:
    a. find a prototype: int getchar(void)
    b. and come to know that EOF is a macro: # define EOF (-1) /* or
    somesuch value */

    > ++nc;
    > printf("%ld\n",nc);


    And so for printf()...
    > return 0;
    > }
    > --------------------------------------------------------

    [ ... ]
    >
    > Why don't the program was exit at first line ???


    You need to be very sure about which key combination would be
    equivalent to
    EOF for your system. So...

    > Why result is 12????


    What were you expecting?

    > Is EOF at first in line???


    Which line?
    Suman, Mar 15, 2006
    #3
  4. neras wrote:
    > Hi..
    > I can't well english..i'm korean;...
    >
    > At first,, You see the my source.
    >
    > -----------------------------------------------


    You need to:

    #include <stdio.h>

    Otherwise, `printf`, `getchar`, and `EOF` are unknown. I'd be surprised
    if you were able to compile without it (for lack of `EOF` mostly).

    > int main(void)
    > {
    > long nc=0;
    > while( getchar()!=EOF )
    > ++nc;
    > printf("%ld\n",nc);
    > return 0;
    > }
    > --------------------------------------------------------
    > It is very short.
    > I thinking the result but my thinking not like compiler;
    >
    > 123ctrl+z123enter
    > I Thinking the print 3 and program is exit.
    > But program is not exit;
    >
    > and I add the 3 line the at like bottm
    > 123ctrl+z123enter
    > 123ctrl+z123enter
    > 123ctrl+z1231enter
    > ctrl+zenter
    >
    > It Was Succed the program exit;
    > Result is 12.
    >
    > Why don't the program was exit at first line ???
    > Why result is 12????
    > Is EOF at first in line???


    Works same for me, and I think it does what it should, and your program
    is correct (apart from missing #include). It just seems that you need
    Ctrl-Z on a line of it's own to force EOF condition. That is to do
    with your particular C implementation.

    --
    BR, Vladimir
    Vladimir S. Oka, Mar 15, 2006
    #4
  5. neras

    ranjmis Guest

    neras wrote:

    > Hi..
    > I can't well english..i'm korean;...
    >
    > At first,, You see the my source.
    >
    > -----------------------------------------------
    > int main(void)
    > {
    > long nc=0;
    > while( getchar()!=EOF )
    > ++nc;
    > printf("%ld\n",nc);
    > return 0;
    > }
    > --------------------------------------------------------


    Let me modify the program to print the value given by getchar
    Also include stdio.h
    --------------------------
    #include<stdio.h>
    int main(void)
    {
    long nc=0;
    int val=0;
    while( (val=getchar())!=12 ) {
    printf(" %d ",val);
    ++nc;
    }
    printf("%ld\n",nc);
    return 0;
    }

    ---------------------------

    > It is very short.
    > I thinking the result but my thinking not like compiler;
    >
    > 123ctrl+z123enter

    123^Z123
    49 50 51

    so it stops at ^Z

    > I Thinking the print 3 and program is exit.
    > But program is not exit;
    >
    > and I add the 3 line the at like bottm
    > 123ctrl+z123enter
    > 123ctrl+z123enter
    > 123ctrl+z1231enter
    > ctrl+zenter


    If I give above input it gives

    123^Z123
    49 50 51 123^Z123
    49 50 51 123^Z1231
    49 50 51 ^Z
    -1

    So If you give only "^zenter" in one line the value is -1 otherwise it
    just stops scanning at ^z.

    >
    > It Was Succed the program exit;
    > Result is 12.


    Result should be 9 instead

    >
    > Why don't the program was exit at first line ???
    > Why result is 12????
    > Is EOF at first in line???
    >
    > Thx.
    ranjmis, Mar 15, 2006
    #5
  6. ranjmis wrote:
    > neras wrote:
    >
    > > Hi..
    > > I can't well english..i'm korean;...
    > >
    > > At first,, You see the my source.
    > >
    > > -----------------------------------------------
    > > int main(void)
    > > {
    > > long nc=0;
    > > while( getchar()!=EOF )
    > > ++nc;
    > > printf("%ld\n",nc);
    > > return 0;
    > > }
    > > --------------------------------------------------------

    >
    > Let me modify the program to print the value given by getchar
    > Also include stdio.h
    > --------------------------
    > #include<stdio.h>
    > int main(void)
    > {
    > long nc=0;
    > int val=0;
    > while( (val=getchar())!=12 ) {


    This is not the same as `== EOF` test, and most likely still not what
    the OP wanted in the first place. You are not correcting it, you are
    breaking it.

    > printf(" %d ",val);
    > ++nc;
    > }
    > printf("%ld\n",nc);
    > return 0;
    > }


    <snip>

    > > It Was Succed the program exit;
    > > Result is 12.

    >
    > Result should be 9 instead


    Again, you are wrong, and OP was right. The problem was in Windows
    wanting a Ctrl-Z on a line of its own in order to trigger EOF
    condition.

    Please stop posting bad advice (this is your second today).

    --
    BR, Vladimir
    Vladimir S. Oka, Mar 15, 2006
    #6
  7. neras

    Pedro Graca Guest

    neras wrote:
    > Is EOF at first in line???


    EOF is *not* a character.

    When getchar() returns a character, that character will be an
    (implementation defined) unsigned char converted to int (probably
    something with a value between 0 and 255). When getchar() returns EOF
    that means getchar() didn't get a character but instead found out the
    input has ended.

    --
    If you're posting through Google read <http://cfaj.freeshell.org/google>
    Pedro Graca, Mar 15, 2006
    #7
  8. In article <>,
    Pedro Graca <> wrote:

    >EOF is *not* a character.


    The C macro EOF is not a character. Unfortunately when discussing
    end-of-file on terminal devices, you often - depending on the
    operating system - have to mention a character typed at the keyboard,
    which is often also referred to as EOF.

    -- Richard
    Richard Tobin, Mar 15, 2006
    #8
  9. (Richard Tobin) writes:
    > In article <>,
    > Pedro Graca <> wrote:
    >
    >>EOF is *not* a character.

    >
    > The C macro EOF is not a character. Unfortunately when discussing
    > end-of-file on terminal devices, you often - depending on the
    > operating system - have to mention a character typed at the keyboard,
    > which is often also referred to as EOF.


    I certainly hope it isn't referred to as EOF.

    At least in the context of this newsgroup, EOF has one clear meaning:
    the macro defined in <stdio.h> which expands to the negative value
    returned by getchar() on an end-of-file or error condition.

    (There is no ASCII control character called "EOF".)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Mar 15, 2006
    #9
  10. "neras" <> writes:
    > At first,, You see the my source.
    > -----------------------------------------------
    > int main(void)
    > {
    > long nc=0;
    > while( getchar()!=EOF )
    > ++nc;
    > printf("%ld\n",nc);
    > return 0;
    > }
    > --------------------------------------------------------
    > It is very short.

    [...]

    Yes, a bit *too* short.

    Others have already pointed out that you need a "#include <stdio.h>".
    Without it, your program won't compile, which means that the code you
    posted isn't the same as the code you actually compiled.

    If you post code here, always post the *exact* code that you actually
    compiled. Don't re-type it; copy-and-paste it. We know there's at
    least one missing line in what you posted. There's no way we can
    guess what else might be missing, which makes it difficult to help
    you.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Mar 15, 2006
    #10
  11. In article <>,
    Keith Thompson <> wrote:

    >> The C macro EOF is not a character. Unfortunately when discussing
    >> end-of-file on terminal devices, you often - depending on the
    >> operating system - have to mention a character typed at the keyboard,
    >> which is often also referred to as EOF.


    >I certainly hope it isn't referred to as EOF.


    I fear you may be disappointed...

    For example, the relevant manual page on the computer I am using
    refers to the "EOF character" (which can be set to any character
    of the user's choice).

    >At least in the context of this newsgroup, EOF has one clear meaning:


    But the people asking questions don't know that. Therir problem is
    precisely that they don't understand the relation and distinction
    between C's EOF and what they type, so anyone saying

    >>>EOF is *not* a character.


    needs to explain it.

    >(There is no ASCII control character called "EOF".)


    No, but many operating systems refer to an EOF character, meaning
    the character typed to signal end-of-file.

    -- Richard
    Richard Tobin, Mar 15, 2006
    #11
  12. neras

    Pedro Graca Guest

    Richard Tobin wrote:
    > so anyone saying
    >
    > >>>EOF is *not* a character.

    >
    > needs to explain it.


    Didn't I explain it when I said that?

    > but many operating systems refer to an EOF character, meaning
    > the character typed to signal end-of-file.


    Windows is stupid (... or I'm doing something terribly wrong)
    It seems there is, in fact, an EOF character in Windows.

    ==== producer.c ====
    #include <stdio.h>
    #include <limits.h>

    int main(void) {
    int i;
    for (i = 0; i <= UCHAR_MAX; ++i) {
    putchar(i);
    if (i % 32 == 15) putchar(EOF);
    if (i % 32 == 31) putchar('\n');
    }
    return 0;
    }


    ==== consumer.c ====
    #include <stdio.h>

    int main(void) {
    long nc = 0;
    int ch;

    printf("EOF is %d\n\n", EOF);

    while ((ch = getchar()) != EOF) {
    printf("%d ", ch);
    ++nc;
    }

    printf("\n\ncounted %ld characters.\n", nc);
    return 0;
    }


    Running "producer | consumer" we learn that the Linux version wrote and
    read 272 charcaters while the Windows version wrote and read 26.

    PS. I compiled with "gcc -W -Wall -std=c89 -pedantic -O2" on both
    platforms;
    Linux gcc is version 3.3.5; Windows 2000 gcc is version 3.3.3

    Will try the same thing tomorrow (at work) with the Microsoft compiler
    for Windows XP.


    --
    If you're posting through Google read <http://cfaj.freeshell.org/google>
    Pedro Graca, Mar 15, 2006
    #12
  13. On 15 Mar 2006 23:17:15 GMT, in comp.lang.c , Pedro Graca
    <> wrote:

    >Windows is stupid (... or I'm doing something terribly wrong)
    >It seems there is, in fact, an EOF character in Windows.


    EOF is a macro. It may well have an integer value, so you may well be
    able to print it. How DOS or Windows interprets it is another matter.

    DOS and dos-based osen (including some *nix derivants) are well known
    for considering ascii 26 to represent the end of a text file, and a
    DOS or Windows compiler might emit ascii 26 when handed (int) EOF.
    Similarly the system process reading a text file will consider ascii
    26 to mark the end of the file, and consequently signal EOF to the
    standard C library. This doesn't mean that ascii 26 /IS/ an EOF.

    >
    >Running "producer | consumer" we learn that the Linux version wrote and
    >read 272 charcaters while the Windows version wrote and read 26.


    What you probably learned is that stdin is a text stream, and the OS
    you're using considers ascii 26 to be a marker for end-of-file in text
    mode.
    Mark McIntyre
    --
    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
    Mark McIntyre, Mar 15, 2006
    #13
  14. (Richard Tobin) writes:
    > In article <>,
    > Keith Thompson <> wrote:

    [...]
    >>At least in the context of this newsgroup, EOF has one clear meaning:

    >
    > But the people asking questions don't know that. Therir problem is
    > precisely that they don't understand the relation and distinction
    > between C's EOF and what they type, so anyone saying
    >
    >>>>EOF is *not* a character.

    >
    > needs to explain it.


    Agreed. I thought it was explained.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Mar 15, 2006
    #14
  15. neras

    Micah Cowan Guest

    Mark McIntyre <> writes:

    > On 15 Mar 2006 23:17:15 GMT, in comp.lang.c , Pedro Graca
    > <> wrote:
    >
    > >Windows is stupid (... or I'm doing something terribly wrong)
    > >It seems there is, in fact, an EOF character in Windows.

    >
    > EOF is a macro. It may well have an integer value, so you may well be
    > able to print it. How DOS or Windows interprets it is another
    > matter.


    ???

    It /must/ have an integer value. A negative one. Of type int. See 7.19.1#3.
    Micah Cowan, Mar 16, 2006
    #15
  16. In article <>,
    Keith Thompson <> wrote:

    >> needs to explain it.

    >
    >Agreed. I thought it was explained.


    My reason for complaining about the article I replied to was that it
    only gave one half of the story: what EOF is in C. To correct
    someone's misunderstanding about this you typically need to explicitly
    contrast it with the operating system notion of end-of-file character,
    since that's what they're confusing it with. Some of the other articles
    did this.

    -- Richard
    Richard Tobin, Mar 16, 2006
    #16
  17. neras

    Pedro Graca Guest

    Mark McIntyre wrote:
    > On 15 Mar 2006 23:17:15 GMT, in comp.lang.c , Pedro Graca
    > <> wrote:
    >
    >>Windows is stupid (... or I'm doing something terribly wrong)
    >>It seems there is, in fact, an EOF character in Windows.

    >
    > EOF is a macro. It may well have an integer value, so you may well be
    > able to print it. How DOS or Windows interprets it is another matter.


    Well ... putchar() accepts an int and then converts it to unsigned char
    before printing, right?
    So, all these lines

    putchar(1024+65);
    putchar(10240+65);
    putchar(-1024+65);

    will print a character with code 65 (ascii 'A'), right?

    > DOS and dos-based osen (including some *nix derivants) are well known
    > for considering ascii 26 to represent the end of a text file, and a
    > DOS or Windows compiler might emit ascii 26 when handed (int) EOF.


    Not in my case.
    putchar(EOF); /* outputs character with code 255 */

    > Similarly the system process reading a text file will consider ascii
    > 26 to mark the end of the file, and consequently signal EOF to the
    > standard C library. This doesn't mean that ascii 26 /IS/ an EOF.


    Ah! A further test indicates you're right.

    while ((ch = getchar()) != EOF) {
    /* void */
    }
    printf("Character code that stopped the while: %d\n", ch);

    This will stop at the character with code 26, but report code -1.

    >>Running "producer | consumer" we learn that the Linux version wrote and
    >>read 272 charcaters while the Windows version wrote and read 26.

    >
    > What you probably learned is that stdin is a text stream, and the OS
    > you're using considers ascii 26 to be a marker for end-of-file in text
    > mode.


    <ot Windows text files>
    Oh, ok. I changed my `producer' to write to a binary file and `consumer'
    to read from the same file and the "EOF character" was gone.


    So ... Windows converts '\n' to "\r\n" for output to text files
    and the other way around for input from text files;

    *and*

    it converts '\x1A' to an EOF condition for input, discarding that
    particular character and all the following ones (and yet it allows one
    to output as many '\x1A's as one wants to ...)

    .... Stupid Windows
    </ot>

    --
    If you're posting through Google read <http://cfaj.freeshell.org/google>
    Pedro Graca, Mar 16, 2006
    #17
  18. neras

    Jordan Abel Guest

    On 2006-03-16, Pedro Graca <> wrote:
    > Mark McIntyre wrote:
    >> On 15 Mar 2006 23:17:15 GMT, in comp.lang.c , Pedro Graca
    >> <> wrote:
    >>
    >>>Windows is stupid (... or I'm doing something terribly wrong)
    >>>It seems there is, in fact, an EOF character in Windows.

    >>
    >> EOF is a macro. It may well have an integer value, so you may well be
    >> able to print it. How DOS or Windows interprets it is another matter.

    >
    > Well ... putchar() accepts an int and then converts it to unsigned char
    > before printing, right?
    > So, all these lines
    >
    > putchar(1024+65);
    > putchar(10240+65);
    > putchar(-1024+65);
    >
    > will print a character with code 65 (ascii 'A'), right?


    Wrong.
    Jordan Abel, Mar 16, 2006
    #18
  19. Pedro Graca <> writes:
    > Mark McIntyre wrote:
    >> On 15 Mar 2006 23:17:15 GMT, in comp.lang.c , Pedro Graca
    >> <> wrote:
    >>
    >>>Windows is stupid (... or I'm doing something terribly wrong)
    >>>It seems there is, in fact, an EOF character in Windows.

    >>
    >> EOF is a macro. It may well have an integer value, so you may well be
    >> able to print it. How DOS or Windows interprets it is another matter.

    >
    > Well ... putchar() accepts an int and then converts it to unsigned char
    > before printing, right?
    > So, all these lines
    >
    > putchar(1024+65);
    > putchar(10240+65);
    > putchar(-1024+65);
    >
    > will print a character with code 65 (ascii 'A'), right?


    Assuming that UCHAR_MAX < 1024, and assuming an ASCII character set:
    yes. (It may require some additional assumptions about CHAR_MAX; I'm
    too lazy to track down the details). I'm not sure what your point is.

    >> DOS and dos-based osen (including some *nix derivants) are well known
    >> for considering ascii 26 to represent the end of a text file, and a
    >> DOS or Windows compiler might emit ascii 26 when handed (int) EOF.

    >
    > Not in my case.
    > putchar(EOF); /* outputs character with code 255 */


    If EOF==-1 (which is very common, if not effectively universal), and
    UCHAR_MAX==255, then putchar(EOF) is equivalent to putchar(255).

    What that causes to be written to the file is system-specific. It's
    possible (but unlikely) that writing that particular value to a text
    file will cause and end-of-file condition at that point when the file
    is read (as the value 26 does under Windows). And mapping '\n' to the
    system-specific end-of-line representation isn't necessarily the only
    tranformation that's done when writing to a text file. C99 7.19.2p2:

    A text stream is an ordered sequence of characters
    composed into _lines_, each line consisting of zero or more
    characters plus a terminating new-line character. Whether
    the last line requires a terminating new-line character
    is implementation-defined. Characters may have to be
    added, altered, or deleted on input and output to conform
    to differing conventions for representing text in the
    host environment. Thus, there need not be a oneto- one
    correspondence between the characters in a stream and those in
    the external representation. Data read in from a text stream
    will necessarily compare equal to the data that were earlier
    written out to that stream only if: the data consist only of
    printing characters and the control characters horizontal tab
    and new-line; no new-line character is immediately preceded
    by space characters; and the last character is a new-line
    character. Whether space characters that are written out
    immediately before a new-line character appear when read in
    is implementation-defined.

    So if you write a control character (other than horizontal tab and
    new-line) to a text file, all bets are off.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Mar 16, 2006
    #19
  20. Jordan Abel <> writes:
    > On 2006-03-16, Pedro Graca <> wrote:
    >> Mark McIntyre wrote:
    >>> On 15 Mar 2006 23:17:15 GMT, in comp.lang.c , Pedro Graca
    >>> <> wrote:
    >>>
    >>>>Windows is stupid (... or I'm doing something terribly wrong)
    >>>>It seems there is, in fact, an EOF character in Windows.
    >>>
    >>> EOF is a macro. It may well have an integer value, so you may well be
    >>> able to print it. How DOS or Windows interprets it is another matter.

    >>
    >> Well ... putchar() accepts an int and then converts it to unsigned char
    >> before printing, right?
    >> So, all these lines
    >>
    >> putchar(1024+65);
    >> putchar(10240+65);
    >> putchar(-1024+65);
    >>
    >> will print a character with code 65 (ascii 'A'), right?

    >
    > Wrong.


    How so? If you're referring to the assumption of an ASCII character
    set, that makes it non-portable, not completely wrong. (For that
    matter, code 65 is ascii 'A', even if some particular implementation
    doesn't use ASCII -- though that's admittedly a bit of a stretch.)

    If UCHAR_MAX is very large, the conversion to unsigned char may not
    yield 65.

    Apart from that, it seems ok.

    Perhaps you'd care to expand on that a bit?

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Mar 16, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Martin Dickopp

    Re: EOF and getchar/fgetc

    Martin Dickopp, Feb 14, 2004, in forum: C Programming
    Replies:
    0
    Views:
    2,166
    Martin Dickopp
    Feb 14, 2004
  2. Luke Wu

    The need for int to capture getchar()'s EOF

    Luke Wu, Jan 23, 2005, in forum: C Programming
    Replies:
    6
    Views:
    580
    Lawrence Kirby
    Jan 26, 2005
  3. broeisi

    getchar function and EOF problem..

    broeisi, Mar 10, 2006, in forum: C Programming
    Replies:
    13
    Views:
    617
    Barry Schwarz
    Mar 12, 2006
  4. Michael Brennan

    getchar() after EOF

    Michael Brennan, Jun 12, 2006, in forum: C Programming
    Replies:
    11
    Views:
    848
    CBFalconer
    Jun 13, 2006
  5. arnuld

    getchar() and EOF confusion

    arnuld, Oct 15, 2008, in forum: C Programming
    Replies:
    21
    Views:
    987
    David Thompson
    Oct 27, 2008
Loading...

Share This Page