writing 0x0A to a bin file without having it automatically write 0x0D

[MCondon77]

This is probably a common problem, but as a novice programmer I'm
trying to figure out how to write 0x0A to a BIN file without having it
automatically write 0x0D. Here's an example of the code:
tmp_ifp = fopen("tmp_name.bin", "w");
fprintf(tmp_ifp, "%c", 0x0A);

When I open the tmp_name.bin file with a hex editor you notice that
both 0x0D and 0x0A are written. I tried using fwrite, but the same
thing occurs. Any ideas?

Thanks....

 

[John Devereux]

This is probably a common problem, but as a novice programmer I'm
trying to figure out how to write 0x0A to a BIN file without having it
automatically write 0x0D. Here's an example of the code:
tmp_ifp = fopen("tmp_name.bin", "w");
fprintf(tmp_ifp, "%c", 0x0A);

When I open the tmp_name.bin file with a hex editor you notice that
both 0x0D and 0x0A are written. I tried using fwrite, but the same
thing occurs. Any ideas?

You need to open the file in "binary" mode, e.g.

tmp_ifp = fopen("tmp_name.bin", "wb");

 

[Ben Pfaff]

This is probably a common problem, but as a novice programmer I'm
trying to figure out how to write 0x0A to a BIN file without having it
automatically write 0x0D. Here's an example of the code:
tmp_ifp = fopen("tmp_name.bin", "w");

Use binary mode: "wb" instead of "w".

 

[Richard G. Riley]

This is probably a common problem, but as a novice programmer I'm
trying to figure out how to write 0x0A to a BIN file without having it
automatically write 0x0D. Here's an example of the code:
tmp_ifp = fopen("tmp_name.bin", "w");
fprintf(tmp_ifp, "%c", 0x0A);

When I open the tmp_name.bin file with a hex editor you notice that
both 0x0D and 0x0A are written. I tried using fwrite, but the same
thing occurs. Any ideas?

Thanks....

I think these routines can convert 0xa to a system defined
line terminator : which I guess in your case is 0xD,0xA.

Check the options which can follow "w" in your fopen : b or t might
help if memory serves correctly. Since you talk about "bin" file then
"wb" might be your man.

 

[Jordan Abel]

This is probably a common problem, but as a novice programmer I'm
trying to figure out how to write 0x0A to a BIN file without having it
automatically write 0x0D. Here's an example of the code:
tmp_ifp = fopen("tmp_name.bin", "w");
"wb".

fprintf(tmp_ifp, "%c", 0x0A);

When I open the tmp_name.bin file with a hex editor you notice that
both 0x0D and 0x0A are written. I tried using fwrite, but the same
thing occurs. Any ideas?

Thanks....

 

[Jordan Abel]

I think these routines can convert 0xa to a system defined
line terminator : which I guess in your case is 0xD,0xA.

Check the options which can follow "w" in your fopen : b or t might
help if memory serves correctly. Since you talk about "bin" file then
"wb" might be your man.

t is not standard C<OT>, and where it is used, it means text mode</OT>.

 

[Barry Schwarz]

This is probably a common problem, but as a novice programmer I'm
trying to figure out how to write 0x0A to a BIN file without having it
automatically write 0x0D. Here's an example of the code:
tmp_ifp = fopen("tmp_name.bin", "w");
fprintf(tmp_ifp, "%c", 0x0A);

When I open the tmp_name.bin file with a hex editor you notice that
both 0x0D and 0x0A are written. I tried using fwrite, but the same
thing occurs. Any ideas?

You opened the file in text mode. Therefore, it is not a binary file,
regardless of what the three character extension is. If you want to
process the file in binary mode, open it binary mode.

For additional insurance, don't use fprintf. Use fwrite.


Remove del for email

 

[Richard Tobin]

For additional insurance, don't use fprintf. Use fwrite.

Huh? How can these be different?

-- Richard

 

[MikeC_EE99]

Thanks....I opened it with "wb" and it worked. I'm surprised that just
using "w" wouldn't. Why would you want to act on the data being
written to a file in that manner? Doesn't make sense. If someone
wanted a new line then they would just put "\n".
Thanks everyone else for your help too!

 

[Chris Dollin]

Thanks....I opened it with "wb" and it worked. I'm surprised that just
using "w" wouldn't. Why would you want to act on the data being
written to a file in that manner?

So that you write the correct data.

Doesn't make sense.
Does.

If someone wanted a new line then they would just put "\n".

But in a /file/, on some OSs incl Windows, a new line is represented
as \r\n, not just \n. So, for /text streams/, the C library converts
\r\n on input to \n, and \n on output to \r.

If you don't want that to happen, you're not writing a text stream,
so you have to tell C that you want a "binary" file.

 

[Richard G. Riley]

Thanks....I opened it with "wb" and it worked. I'm surprised that just
using "w" wouldn't. Why would you want to act on the data being
written to a file in that manner? Doesn't make sense. If someone
wanted a new line then they would just put "\n".
Thanks everyone else for your help too!

Different OSs terminate text lines with different combinations."b"
tells the routine to put what you want, not what the file "convention"
is on that system

 

[Barry Schwarz]

Huh? How can these be different?

fprintf is going to "massage" the format string, making the
"appropriate" substitutions for every conversion specification. As a
Windows system specific implementation detail, this massaging also
appears to include converting \n to \n\r (or is it \r\n). That this
happens on text files is obvious. I don't know whether it also
happens on binary files but fwrite definitely performs no such
massaging. Hence the phrase about insurance.


Remove del for email

 

[Richard Tobin]

fprintf is going to "massage" the format string, making the
"appropriate" substitutions for every conversion specification. As a
Windows system specific implementation detail, this massaging also
appears to include converting \n to \n\r (or is it \r\n). That this
happens on text files is obvious. I don't know whether it also
happens on binary files but fwrite definitely performs no such
massaging. Hence the phrase about insurance.

I don't have a Windows machine to test it on, but I can see nothing in
the standard to justify this behaviour. The conversion of characters
is controlled by the stream type, which is in turn controlled by the
"b" flag to fopen(), not by the choice of fprintf() or fwrite().

-- Richard

 

[Jordan Abel]

fprintf is going to "massage" the format string, making the
"appropriate" substitutions for every conversion specification. As a
Windows system specific implementation detail, this massaging also
appears to include converting \n to \n\r (or is it \r\n).

It is not printf that does this. It is putc, which is called [or as if
it is called] by every other output function. \n is not a conversion
specification.

That this happens on text files is obvious. I don't know whether it
also happens on binary files but fwrite definitely performs no such
massaging.

It is self-evident that it does, on text files. An implementation where
the output caused by fwrite is not as if putc were called in a loop is
non-conforming.

 

[Jordan Abel]

Thanks....I opened it with "wb" and it worked. I'm surprised that just
using "w" wouldn't. Why would you want to act on the data being
written to a file in that manner?

Compatibility with text files used by other programs on the platform,
some of which may not be written in C.

 

[Keith Thompson]

fprintf is going to "massage" the format string, making the
"appropriate" substitutions for every conversion specification. As a
Windows system specific implementation detail, this massaging also
appears to include converting \n to \n\r (or is it \r\n). That this
happens on text files is obvious. I don't know whether it also
happens on binary files but fwrite definitely performs no such
massaging. Hence the phrase about insurance.

#if USE_FWRITE
fwrite("hello, world\n", 1, strlen("hello, world\n"), stream);
#else
fprintf(stream, "hello, world\n");
#endif

If the data written to "stream" differs depending on whether
USE_FWRITE is defined, then the implementation of either fwrite() of
fprintf() is broken. Both are equivalent to a sequence of calls to
fputc(). Both will translate '\n' to a system-specific end-of-line
representation if stream is opened in text mode; neither will do so if
stream is opened in binary mode.