stream io in c

Discussion in 'C Programming' started by Ron Ford, Jul 30, 2008.

  1. Ron Ford

    Ron Ford Guest

    A question came up in a syntax which is a common C extension, and I wanted
    to answer how to solve it in C, as I believe that the solution is less than
    ten lines and one that I could step through with gdb, my untoward debugger.

    %- Writing $00-$FF via Fortran
    %-
    %- I am in need for an important project to write out simple
    %- unsigned-char values in the range $00 through $FF,
    %- without any extraneous data being added:
    %-
    %- open: Open the file for "raw 8-bit binary output"
    %- Sequential writes; nothing fancy.
    %- write: Write out individual unsigned 8-bit values with no
    %- extraneous data whatsoever being involved
    %- (a single value results in a single value going to output
    %- file)
    %- close: Close the file with no extraneous data being appended.
    %- Size: File size is only the number of actual values written!

    I think the solution in c could be as easy as instantiating a loop from
    zero to 255, putchar'ing in the body of the loop, then redirecting output
    to a file. If the creation of the file comes from the source, I suspect it
    would have to be in 'rb' mode.

    But I don't know. I'm hoping to use 8-bit devices, so I better get a good
    handle on it. Thanks and cheers,
    --
    Wealth - any income that is at least one hundred dollars more a year than
    the income of one's wife's sister's husband. 6
    H. L. Mencken
    Ron Ford, Jul 30, 2008
    #1
    1. Advertising

  2. Ron Ford <> writes:

    > A question came up in a syntax which is a common C extension, and I wanted
    > to answer how to solve it in C, as I believe that the solution is less than
    > ten lines and one that I could step through with gdb, my untoward debugger.
    >
    > %- Writing $00-$FF via Fortran
    > %-
    > %- I am in need for an important project to write out simple
    > %- unsigned-char values in the range $00 through $FF,
    > %- without any extraneous data being added:
    > %-
    > %- open: Open the file for "raw 8-bit binary output"
    > %- Sequential writes; nothing fancy.
    > %- write: Write out individual unsigned 8-bit values with no
    > %- extraneous data whatsoever being involved
    > %- (a single value results in a single value going to output
    > %- file)
    > %- close: Close the file with no extraneous data being appended.
    > %- Size: File size is only the number of actual values written!
    >
    > I think the solution in c could be as easy as instantiating a loop from
    > zero to 255, putchar'ing in the body of the loop, then redirecting output
    > to a file.


    The output stream should be binary. On a system where there is no
    distinction between text and binary streams you don't really need to
    bother, but I would do a:

    if (freopen(NULL, stdout, "wb") != NULL) {
    /* OK, of we go... */
    }

    to be sure. Of course, if you are writing to a device/file, just open
    with mode "wb".

    > If the creation of the file comes from the source, I suspect it
    > would have to be in 'rb' mode.


    Parse error. Can you re-phrase?

    --
    Ben.
    Ben Bacarisse, Jul 30, 2008
    #2
    1. Advertising

  3. Ron Ford

    Ron Ford Guest

    On Tue, 29 Jul 2008 19:49:54 -0600, Ron Ford posted:

    > I think the solution in c could be as easy as instantiating a loop from
    > zero to 255, putchar'ing in the body of the loop, then redirecting output
    > to a file. If the creation of the file comes from the source, I suspect it
    > would have to be in 'rb' mode.


    I've tried some variations with this.

    int i;
    for (i = 0; i <= UCHAR_MAX; i++) putchar (i);

    When stdout is redirected to a file, I get a file of size 257 bytes. I
    wanted to see if that would also be the case if I created the file from
    source, but I've got type mismatches here:

    #include <stdio.h>
    int main(void)
    {
    FILE *fp;
    char name[]="text58.txt";

    fp=&name;
    int c;

    if ((fp = fopen(fp, "rb")) == NULL)
    {
    printf("can't open %s\n", fp);
    return 1;
    }
    else
    {
    for (c = 0; c <= 255; c ++) {
    putc(c, fp);
    }
    fclose(fp);
    }
    return 0;
    }
    // gcc -o chars mkchars1.c

    This compiles but gcc warns of incompatible pointer types. As of now, it
    tells me it can't open. I can't find an example in K&R where they hard-code
    a filename like this, so I'm a little stuck.:-(

    --
    We are here and it is now. Further than that, all human knowledge is
    moonshine. 3
    H. L. Mencken
    Ron Ford, Jul 31, 2008
    #3
  4. Ron Ford <> writes:

    > On Tue, 29 Jul 2008 19:49:54 -0600, Ron Ford posted:
    >
    >> I think the solution in c could be as easy as instantiating a loop from
    >> zero to 255, putchar'ing in the body of the loop, then redirecting output
    >> to a file. If the creation of the file comes from the source, I suspect it
    >> would have to be in 'rb' mode.

    >
    > I've tried some variations with this.
    >
    > int i;
    > for (i = 0; i <= UCHAR_MAX; i++) putchar (i);
    >
    > When stdout is redirected to a file, I get a file of size 257 bytes. I
    > wanted to see if that would also be the case if I created the file from
    > source, but I've got type mismatches here:
    >
    > #include <stdio.h>
    > int main(void)
    > {
    > FILE *fp;
    > char name[]="text58.txt";
    >
    > fp=&name;


    No need to set fp here. Just use name in the fopen call. This
    assignment does no make sense anyway, since the types don't match.

    > int c;
    >
    > if ((fp = fopen(fp, "rb")) == NULL)


    Use fopen(name, "wb") here. You are opening for reading but plan to
    write to this stream.

    > {
    > printf("can't open %s\n", fp);


    printf("can't open %s\n", name);

    > return 1;
    > }
    > else
    > {
    > for (c = 0; c <= 255; c ++) {
    > putc(c, fp);
    > }
    > fclose(fp);
    > }
    > return 0;
    > }
    > // gcc -o chars mkchars1.c
    >
    > This compiles but gcc warns of incompatible pointer types. As of now, it
    > tells me it can't open.


    This is because you try to open it for reading and, presumably, the
    file does not yet exist.

    > I can't find an example in K&R where they hard-code
    > a filename like this, so I'm a little stuck.:-(


    --
    Ben.
    Ben Bacarisse, Jul 31, 2008
    #4
  5. Ron Ford <> writes:
    > On Tue, 29 Jul 2008 19:49:54 -0600, Ron Ford posted:
    >
    >> I think the solution in c could be as easy as instantiating a loop from
    >> zero to 255, putchar'ing in the body of the loop, then redirecting output
    >> to a file. If the creation of the file comes from the source, I suspect it
    >> would have to be in 'rb' mode.

    >
    > I've tried some variations with this.
    >
    > int i;
    > for (i = 0; i <= UCHAR_MAX; i++) putchar (i);
    >
    > When stdout is redirected to a file, I get a file of size 257 bytes. I
    > wanted to see if that would also be the case if I created the file from
    > source, but I've got type mismatches here:


    Please indent your code. Run it through "indent -kr" if necessary
    (and if you have the "indent" program).

    > #include <stdio.h>
    > int main(void)
    > {
    > FILE *fp;
    > char name[]="text58.txt";


    Ok, so far, so good.

    > fp=&name;


    What?

    fp is a FILE*, something you use for things like fopen. You're
    assigning the address of a character array to it. What exactly is
    "fp=&name;" intended to accomplish?

    Just delete that line.

    > int c;
    >
    > if ((fp = fopen(fp, "rb")) == NULL)


    And here you're trying to use fp both to hold the result of fopen and
    to hold the name of the file.

    A FILE* and the name of a file are two entirely different things. You
    pass the name of a file to fopen, and it gives you a FILE*. (A FILE*
    is a pointer to some blob of information; you don't need to know the
    details, which will vary from system to system.)

    You already have a variable that holds the name of the file. Use it.

    ... fp = fopen(name, "rb") ...

    > {
    > printf("can't open %s\n", fp);


    Mis-using fp again. You want name. And consider printing the error
    message to stderr rather than stdout (that's not a high priority).

    > return 1;


    Add "#include <stdlib.h> and change this to "return EXIT_FAILURE;".
    The value 1 isn't necessarily meaningful.

    > }
    > else
    > {
    > for (c = 0; c <= 255; c ++) {
    > putc(c, fp);


    You opened fp as an input file. Now you're trying to write to it.

    If you wanted to write to the file, you should have used mode "wb"
    rather than "rb".

    > }
    > fclose(fp);
    > }
    > return 0;
    > }
    > // gcc -o chars mkchars1.c
    >
    > This compiles but gcc warns of incompatible pointer types. As of now, it
    > tells me it can't open. I can't find an example in K&R where they hard-code
    > a filename like this, so I'm a little stuck.:-(


    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jul 31, 2008
    #5
  6. Ron Ford

    CBFalconer Guest

    Ron Ford wrote:
    >

    .... snip ...
    >
    > I've tried some variations with this.
    >
    > int i;
    > for (i = 0; i <= UCHAR_MAX; i++) putchar (i);
    >
    > When stdout is redirected to a file, I get a file of size 257
    > bytes. I wanted to see if that would also be the case if I
    > created the file from source, but I've got type mismatches here:


    The system you are using affects this. Some will expand '\n' to cr
    and lf, others just to lf, others to just cr, or even a line with a
    length flag. Some will insist on adding an EOF marker, some wont.
    If your system is ASCII you wrote a '\n' with the 11th character.
    You wrote a '\0' with the first.

    What you ARE guaranteed is that you get back what you wrote
    (assuming proper file modes in the open argument).

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
    CBFalconer, Jul 31, 2008
    #6
  7. CBFalconer <> writes:
    > Ron Ford wrote:
    >>

    > ... snip ...
    >>
    >> I've tried some variations with this.
    >>
    >> int i;
    >> for (i = 0; i <= UCHAR_MAX; i++) putchar (i);
    >>
    >> When stdout is redirected to a file, I get a file of size 257
    >> bytes. I wanted to see if that would also be the case if I
    >> created the file from source, but I've got type mismatches here:

    >
    > The system you are using affects this. Some will expand '\n' to cr
    > and lf, others just to lf, others to just cr, or even a line with a
    > length flag. Some will insist on adding an EOF marker, some wont.
    > If your system is ASCII you wrote a '\n' with the 11th character.
    > You wrote a '\0' with the first.
    >
    > What you ARE guaranteed is that you get back what you wrote
    > (assuming proper file modes in the open argument).


    I believe that's guaranteed only for binary file (except that they may
    be padded at the end with an arbitrary number of zero bytes). There's
    no such guarantee for text files.

    For example, on a system that uses character 26 as an end-of-file
    marker for text files, if you write character 26 in the middle of an
    output file, you'll only see half the file when you try to read it.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jul 31, 2008
    #7
  8. Ron Ford

    Ron Ford Guest

    On Thu, 31 Jul 2008 01:26:25 +0000, Richard Heathfield posted:

    > Ron Ford said:
    >
    >> On Tue, 29 Jul 2008 19:49:54 -0600, Ron Ford posted:
    >>
    >>> I think the solution in c could be as easy as instantiating a loop from
    >>> zero to 255, putchar'ing in the body of the loop, then redirecting
    >>> output
    >>> to a file. If the creation of the file comes from the source, I suspect
    >>> it would have to be in 'rb' mode.

    >>
    >> I've tried some variations with this.
    >>
    >> int i;
    >> for (i = 0; i <= UCHAR_MAX; i++) putchar (i);
    >>
    >> When stdout is redirected to a file, I get a file of size 257 bytes. I
    >> wanted to see if that would also be the case if I created the file from
    >> source, but I've got type mismatches here:
    >>
    >> #include <stdio.h>
    >> int main(void)
    >> {
    >> FILE *fp;
    >> char name[]="text58.txt";
    >>
    >> fp=&name;

    >
    > Huh? fp has type FILE *, but &name has type char (*)[11]. How can it
    > possibly make sense to you to assign the one to the other?


    It would seem that I was trying to shoe-horn a char* into a file*. I
    believed that the & operator hands the LHS the address of the object, in
    this case, the name of a file.


    > Serious
    > question. What on earth do you think this assignment means? Why did you
    > type it? (Answering that question might be the most important way you can
    > learn from this thread.)


    LHS is a pointer. Since I could not create a sensical thingamajig of type
    FILE--everything I tried was a syntax error--I tried chars. There's no
    guarantees on pointers like this; why would there be a prohibition?


    >
    >> int c;
    >>
    >> if ((fp = fopen(fp, "rb")) == NULL)

    >
    > fopen's first parameter is declared as being const char *, so why are you
    > passing it a FILE *?
    >
    > Fixing that, we get:
    >
    > if((fp = fopen(name, "rb")) != NULL) /* but see below */
    >
    >> {
    >> printf("can't open %s\n", fp);
    >> return 1;

    >
    > Better: return EXIT_FAILURE; but you'll need <stdlib.h> for that.
    >
    >> }
    >> else
    >> {
    >> for (c = 0; c <= 255; c ++) {
    >> putc(c, fp);

    >
    > Wait a minute. Didn't you just try to open that file for reading? So why
    > are you trying to write to it?
    >
    >> This compiles

    >
    > <cough> Yes, I know. But compilation does not indicate correctness. It
    > merely indicates that the compiler has managed, sometimes against heavy
    > odds, to produce an executable program. Unless the program is correct,
    > however, the program won't make a lot of sense.



    --
    We are here and it is now. Further than that, all human knowledge is
    moonshine. 3
    H. L. Mencken
    Ron Ford, Jul 31, 2008
    #8
  9. Ron Ford

    santosh Guest

    Ron Ford wrote:
    > On Thu, 31 Jul 2008 01:26:25 +0000, Richard Heathfield posted:
    >> Ron Ford said:


    [ ... ]

    >>> #include <stdio.h>
    >>> int main(void)
    >>> {
    >>> FILE *fp;
    >>> char name[]="text58.txt";
    >>>
    >>> fp=&name;

    >>
    >> Huh? fp has type FILE *, but &name has type char (*)[11]. How can it
    >> possibly make sense to you to assign the one to the other?

    >
    > It would seem that I was trying to shoe-horn a char* into a file*.


    You mean a FILE*?

    In any case the FILE type holds critical data that is needed to operate
    on the associated stream, like address of buffers, status flags etc.
    You simply cannot stuff a FILE* object with the address of any object
    other than a FILE, and hope get anything right. This is in fact an
    illustration of a general rule in C, viz., object pointers of type T*
    can only hold NULL or addresses of objects of type T. An exception is
    the void* which can hold NULL or values of any object pointer type.

    > I believed that the & operator hands the LHS the address of the
    > object, in this case, the name of a file.


    The & operator indeed computes the address of it's operand, but in your
    case the address generated is the address of the array name, not the
    address of it's first element. The values would be identical, but the
    type differs.

    >> Serious
    >> question. What on earth do you think this assignment means? Why did
    >> you type it? (Answering that question might be the most important way
    >> you can learn from this thread.)

    >
    > LHS is a pointer. Since I could not create a sensical thingamajig of
    > type FILE


    That's what the fopen function is for.

    > --everything I tried was a syntax error--I tried chars. There's
    > no guarantees on pointers like this; why would there be a prohibition?


    Because there are implementations were the sizes and representations of
    various pointer types are different and a value of type A* need not
    make any sense when interpreted as a value of type B*.

    <snip>
    santosh, Jul 31, 2008
    #9
  10. Ron Ford

    Ron Ford Guest

    On Wed, 30 Jul 2008 18:35:48 -0700, Keith Thompson posted:

    > Ron Ford <> writes:
    >> On Tue, 29 Jul 2008 19:49:54 -0600, Ron Ford posted:
    >>
    >>> I think the solution in c could be as easy as instantiating a loop from
    >>> zero to 255, putchar'ing in the body of the loop, then redirecting output
    >>> to a file. If the creation of the file comes from the source, I suspect it
    >>> would have to be in 'rb' mode.

    >>
    >> I've tried some variations with this.
    >>
    >> int i;
    >> for (i = 0; i <= UCHAR_MAX; i++) putchar (i);
    >>
    >> When stdout is redirected to a file, I get a file of size 257 bytes. I
    >> wanted to see if that would also be the case if I created the file from
    >> source, but I've got type mismatches here:

    >
    > Please indent your code. Run it through "indent -kr" if necessary
    > (and if you have the "indent" program).
    >
    >> #include <stdio.h>
    >> int main(void)
    >> {
    >> FILE *fp;
    >> char name[]="text58.txt";

    >
    > Ok, so far, so good.
    >
    >> fp=&name;

    >
    > What?
    >
    > fp is a FILE*, something you use for things like fopen. You're
    > assigning the address of a character array to it. What exactly is
    > "fp=&name;" intended to accomplish?
    >
    > Just delete that line.
    >
    >> int c;
    >>
    >> if ((fp = fopen(fp, "rb")) == NULL)

    >
    > And here you're trying to use fp both to hold the result of fopen and
    > to hold the name of the file.
    >
    > A FILE* and the name of a file are two entirely different things. You
    > pass the name of a file to fopen, and it gives you a FILE*. (A FILE*
    > is a pointer to some blob of information; you don't need to know the
    > details, which will vary from system to system.)
    >
    > You already have a variable that holds the name of the file. Use it.
    >
    > ... fp = fopen(name, "rb") ...
    >
    >> {
    >> printf("can't open %s\n", fp);

    >
    > Mis-using fp again. You want name. And consider printing the error
    > message to stderr rather than stdout (that's not a high priority).
    >
    >> return 1;

    >
    > Add "#include <stdlib.h> and change this to "return EXIT_FAILURE;".
    > The value 1 isn't necessarily meaningful.
    >
    >> }
    >> else
    >> {
    >> for (c = 0; c <= 255; c ++) {
    >> putc(c, fp);

    >
    > You opened fp as an input file. Now you're trying to write to it.
    >
    > If you wanted to write to the file, you should have used mode "wb"
    > rather than "rb".
    >
    >> }
    >> fclose(fp);
    >> }
    >> return 0;
    >> }
    >> // gcc -o chars mkchars1.c
    >>
    >> This compiles but gcc warns of incompatible pointer types. As of now, it
    >> tells me it can't open. I can't find an example in K&R where they hard-code
    >> a filename like this, so I'm a little stuck.:-(


    Thanks, Keith, I seem to be doing much better:


    #include <stdio.h>
    int main(void)
    {
    FILE *fp;
    char name[]="text58.txt";


    int c;

    if ((fp = fopen(name, "wb")) == NULL)
    {
    printf("can't open %s\n", fp);
    return 1;
    }
    else
    {
    for (c = 0; c <= 255; c ++) {
    putc(c, fp);
    }
    fclose(fp);
    }
    return 0;
    }
    // gcc -o chars mkchars2.c

    It seems to compile and behave:

    C:\MinGW\source> gcc -o chars mkchars2.c

    C:\MinGW\source>chars

    C:\MinGW\source>dir
    Volume in drive C has no label.
    Volume Serial Number is 486B-CFF3

    Directory of C:\MinGW\source

    [...]
    07/31/2008 02:58 AM 309 mkchars1.c
    07/30/2008 06:31 PM 257 text55.txt
    07/30/2008 06:56 PM 2,592 mkchars1.o
    07/30/2008 06:56 PM 19,581 new.exe
    07/31/2008 03:06 AM 312 mkchars2.c
    07/31/2008 03:06 AM 256 text58.txt
    07/31/2008 03:06 AM 17,203 chars.exe
    27 File(s) 108,824 bytes
    3 Dir(s) 492,433,408 bytes free

    I think this shows a difference between a way to get a file with 257 bytes
    (> .txt) and one without an ultimate -1.

    I'll tune up the minor points when I can follow through. Best regards,

    --
    We are here and it is now. Further than that, all human knowledge is
    moonshine. 3
    H. L. Mencken
    Ron Ford, Jul 31, 2008
    #10
  11. Ron Ford

    Richard Bos Guest

    Ron Ford <> wrote:

    > On Thu, 31 Jul 2008 01:26:25 +0000, Richard Heathfield posted:
    >
    > > Ron Ford said:


    > >> FILE *fp;
    > >> char name[]="text58.txt";
    > >>
    > >> fp=&name;


    > > question. What on earth do you think this assignment means? Why did you
    > > type it? (Answering that question might be the most important way you can
    > > learn from this thread.)

    >
    > LHS is a pointer. Since I could not create a sensical thingamajig of type
    > FILE--everything I tried was a syntax error--I tried chars. There's no
    > guarantees on pointers like this; why would there be a prohibition?


    That's a nice example of magical thinking. "This looks, in one trivial
    detail, like that; therefore, this should work, in all essentials, like
    that." No. A pointer to FILE and a pointer to array of char are quite
    different, and what's much more important, a FILE and an array of char
    are very different. If you want to be a programmer, you must learn to
    make sure that you _know_, rather than guess.

    Richard
    Richard Bos, Jul 31, 2008
    #11
  12. Ron Ford

    santosh Guest

    Ron Ford wrote:

    <snip>

    > Thanks, Keith, I seem to be doing much better:
    >
    >
    > #include <stdio.h>
    > int main(void)
    > {
    > FILE *fp;
    > char name[]="text58.txt";


    If you are using tabs to indent your code, consider switching to spaces,
    since tabs are often stripped out by Usenet software.

    > int c;
    >
    > if ((fp = fopen(name, "wb")) == NULL)
    > {
    > printf("can't open %s\n", fp);


    The 's' type specifier expects a char* argument that must point at a
    string. You have supplied it a FILE* argument, a certain route to
    undefined behaviour.

    > return 1;


    And one is not a portable return value. The portable values are 0,
    EXIT_SUCCESS and EXIT_FAILURE.

    Surely you must have noted these elementary things as they are often
    mentioned in this group, besides being in it's FAQ.

    > }
    > else
    > {
    > for (c = 0; c <= 255; c ++) {
    > putc(c, fp);


    Since you are writing raw byte values, you might consider changing the
    misleading filename extension.

    Also the maximum value of an unsigned byte in C is given by UCHAR_MAX.
    It is not necessarily 256. And note that 'c' is declared as an int, not
    unsigned char.

    > }
    > fclose(fp);
    > }
    > return 0;
    > }
    > // gcc -o chars mkchars2.c


    This command is not a conforming implementation of ISO C. For that you
    need:

    gcc -ansi -pedantic /* For conformance to C90 */
    gcc -std=c99 -pedantic /* For incomplete but good conformance to C99
    */

    Also add the -Wall and -W flags for extra diagnostics which are always a
    help.

    <snip>
    santosh, Jul 31, 2008
    #12
  13. Ron Ford

    Ron Ford Guest

    On Thu, 31 Jul 2008 15:04:37 +0530, santosh posted:

    >> // gcc -o chars mkchars2.c

    >
    > This command is not a conforming implementation of ISO C. For that you
    > need:
    >
    > gcc -ansi -pedantic /* For conformance to C90 */
    > gcc -std=c99 -pedantic /* For incomplete but good conformance to C99
    > */
    >
    > Also add the -Wall and -W flags for extra diagnostics which are always a
    > help.


    //mkchars.c:



    #include <stdio.h>
    #include <stdlib.h>

    int main(void)
    {
    FILE *fp;
    char name[]="text62.txt";


    int c;

    if ((fp = fopen(name, "wb")) == NULL)
    {
    printf("can't open %s\n", fp);
    return EXIT_FAILURE;
    }
    else
    {
    for (c = 0; c <= 255; c ++) {
    putc(c, fp);
    }
    fclose(fp);
    }
    return 0;
    }
    // gcc -o chars -std=c99 -pedantic mkchars3.c

    --
    When a new source of taxation is found it never means, in practice, that
    the old source is abandoned. It merely means that the politicians have two
    ways of milking the taxpayer where they had one before. 8
    H. L. Mencken
    Ron Ford, Jul 31, 2008
    #13
  14. Ron Ford

    santosh Guest

    Ron Ford wrote:

    > On Thu, 31 Jul 2008 15:04:37 +0530, santosh posted:
    >
    >>> // gcc -o chars mkchars2.c

    >>
    >> This command is not a conforming implementation of ISO C. For that
    >> you need:
    >>
    >> gcc -ansi -pedantic /* For conformance to C90 */
    >> gcc -std=c99 -pedantic /* For incomplete but good conformance to
    >> C99
    >> */
    >>
    >> Also add the -Wall and -W flags for extra diagnostics which are
    >> always a help.

    >
    > //mkchars.c:
    >
    >
    >
    > #include <stdio.h>
    > #include <stdlib.h>
    >
    > int main(void)
    > {
    > FILE *fp;
    > char name[]="text62.txt";
    >
    >
    > int c;
    >
    > if ((fp = fopen(name, "wb")) == NULL)
    > {
    > printf("can't open %s\n", fp);


    Can you spot the mistake in this printf call?

    > return EXIT_FAILURE;
    > }
    > else
    > {
    > for (c = 0; c <= 255; c ++) {
    > putc(c, fp);
    > }
    > fclose(fp);
    > }
    > return 0;
    > }
    > // gcc -o chars -std=c99 -pedantic mkchars3.c


    If you had added the -Wall and -W flags to gcc, it would have warned you
    of your botch-up with printf.
    santosh, Jul 31, 2008
    #14
  15. On 31 Jul, 02:10, Ron Ford <> wrote:
    > On Tue, 29 Jul 2008 19:49:54 -0600, Ron Ford posted:
    >
    > > I think the solution in c could be as easy as instantiating a loop from
    > > zero to 255, putchar'ing in the body of the loop, then redirecting output
    > > to a file.  If the creation of the file comes from the source, I suspect it
    > > would have to be in 'rb' mode.

    >
    > I've tried some variations with this.
    >
    > int i;
    > for (i = 0; i <= UCHAR_MAX; i++) putchar (i);


    for (i = 0; i < UCHAR_MAX; i++) putchar (i);

    <snip>

    --
    Nick Keighley

    It's always September. But sometimes it is _more_ September.
    Jim Cameron (clc)
    Nick Keighley, Jul 31, 2008
    #15
  16. Nick Keighley <> writes:

    > On 31 Jul, 02:10, Ron Ford <> wrote:
    >> On Tue, 29 Jul 2008 19:49:54 -0600, Ron Ford posted:
    >>
    >> > I think the solution in c could be as easy as instantiating a loop from
    >> > zero to 255, putchar'ing in the body of the loop, then redirecting output
    >> > to a file.  If the creation of the file comes from the source, I suspect it
    >> > would have to be in 'rb' mode.

    >>
    >> I've tried some variations with this.
    >>
    >> int i;
    >> for (i = 0; i <= UCHAR_MAX; i++) putchar (i);

    >
    > for (i = 0; i < UCHAR_MAX; i++) putchar (i);


    I suspect a joke, but I'm not getting it. Can you labour the point
    for the rest of us?

    --
    Ben.
    Ben Bacarisse, Jul 31, 2008
    #16
  17. Ron Ford

    Richard Guest

    Ben Bacarisse <> writes:

    > Nick Keighley <> writes:
    >
    >> On 31 Jul, 02:10, Ron Ford <> wrote:
    >>> On Tue, 29 Jul 2008 19:49:54 -0600, Ron Ford posted:
    >>>
    >>> > I think the solution in c could be as easy as instantiating a loop from
    >>> > zero to 255, putchar'ing in the body of the loop, then redirecting output
    >>> > to a file.  If the creation of the file comes from the source, I suspect it
    >>> > would have to be in 'rb' mode.
    >>>
    >>> I've tried some variations with this.
    >>>
    >>> int i;
    >>> for (i = 0; i <= UCHAR_MAX; i++) putchar (i);

    >>
    >> for (i = 0; i < UCHAR_MAX; i++) putchar (i);

    >
    > I suspect a joke, but I'm not getting it. Can you labour the point
    > for the rest of us?


    I will hazard he meant:

    ,----
    | for (int i = 0; i < UCHAR_MAX; i++) putchar (i);
    `----

    as in C99.

    Although frankly I think it#s horrible layout. Hard to debug. Hard to
    see the body.

    ,----
    | for (int i = 0; i < UCHAR_MAX; i++)
    | putchar (i);
    `----

    ....
    Richard, Jul 31, 2008
    #17
  18. Richard<> writes:

    > Ben Bacarisse <> writes:
    >
    >> Nick Keighley <> writes:
    >>
    >>> On 31 Jul, 02:10, Ron Ford <> wrote:
    >>>> On Tue, 29 Jul 2008 19:49:54 -0600, Ron Ford posted:
    >>>>
    >>>> > I think the solution in c could be as easy as instantiating a loop from
    >>>> > zero to 255, putchar'ing in the body of the loop, then redirecting output
    >>>> > to a file.  If the creation of the file comes from the source, I suspect it
    >>>> > would have to be in 'rb' mode.
    >>>>
    >>>> I've tried some variations with this.
    >>>>
    >>>> int i;
    >>>> for (i = 0; i <= UCHAR_MAX; i++) putchar (i);
    >>>
    >>> for (i = 0; i < UCHAR_MAX; i++) putchar (i);

    >>
    >> I suspect a joke, but I'm not getting it. Can you labour the point
    >> for the rest of us?

    >
    > I will hazard he meant:
    >
    > ,----
    > | for (int i = 0; i < UCHAR_MAX; i++) putchar (i);
    > `----
    >
    > as in C99.


    The bit I am not getting is changing test from the correct one to one
    that does not do what the OP wants. If the intent was to change the
    scope of i, why change the test as well?

    --
    Ben.
    Ben Bacarisse, Jul 31, 2008
    #18
  19. Ron Ford

    CBFalconer Guest

    Nick Keighley wrote:
    > Ron Ford <> wrote:
    >

    .... snip ...
    >
    >> I've tried some variations with this.
    >>
    >> int i;
    >> for (i = 0; i <= UCHAR_MAX; i++) putchar (i);

    >
    > for (i = 0; i < UCHAR_MAX; i++) putchar (i);


    No, the original is correct. He wants to write out the entire
    range available to the char type.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
    CBFalconer, Jul 31, 2008
    #19
  20. Ron Ford <> writes:
    > On Thu, 31 Jul 2008 15:04:37 +0530, santosh posted:
    >
    >>> // gcc -o chars mkchars2.c

    >>
    >> This command is not a conforming implementation of ISO C. For that you
    >> need:
    >>
    >> gcc -ansi -pedantic /* For conformance to C90 */
    >> gcc -std=c99 -pedantic /* For incomplete but good conformance to C99
    >> */
    >>
    >> Also add the -Wall and -W flags for extra diagnostics which are always a
    >> help.

    >
    > //mkchars.c:
    >
    >
    >
    > #include <stdio.h>
    > #include <stdlib.h>
    >
    > int main(void)
    > {
    > FILE *fp;
    > char name[]="text62.txt";
    >
    >
    > int c;
    >
    > if ((fp = fopen(name, "wb")) == NULL)
    > {
    > printf("can't open %s\n", fp);
    > return EXIT_FAILURE;
    > }
    > else
    > {
    > for (c = 0; c <= 255; c ++) {
    > putc(c, fp);
    > }
    > fclose(fp);
    > }
    > return 0;
    > }
    > // gcc -o chars -std=c99 -pedantic mkchars3.c


    Compared to the previous version you posted, you added
    "#include <stdlib.h>", you changed the file name from "text58.txt" to
    "text62.txt", and you changed "return 1;" to "return EXIT_FAILURE;".

    Oh, and you didn't mention what changes you had made; I had to save
    both versions and compare them myself.

    You ignored the vast majority of santosh's excellent advice.
    Specifically:

    Your indentation is still non-existent.

    You're still trying to print a FILE* value using "%s".

    You're still using a misleading file name.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jul 31, 2008
    #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. Rasmusson, Lars
    Replies:
    1
    Views:
    753
    popov
    Apr 30, 2004
  2. Replies:
    9
    Views:
    627
    Alex Buell
    Apr 27, 2006
  3. Alexander Korsunsky

    get stream mode flags from an opened stream

    Alexander Korsunsky, Feb 17, 2007, in forum: C++
    Replies:
    1
    Views:
    450
    John Harrison
    Feb 17, 2007
  4. dolphin
    Replies:
    6
    Views:
    554
    Thomas Fritsch
    Mar 18, 2007
  5. mrstephengross
    Replies:
    3
    Views:
    396
    James Kanze
    May 10, 2007
Loading...

Share This Page