From: Paul G. <pga...@qw...> - 2001-03-30 00:16:16
|
On 29 Mar 2001, at 14:13, the Illustrious Edmund Bertschinger wrote: > Hi, > > I am a new user of gcc-2.95.2 on a PC running Windows > 98. Right away I discovered what seems to be a bug in > the standard library routine fputc (and also fwrite): > If one tries to write a single byte with integer value > 10, fputc writes *two* bytes: 13,10. A simple test > code (appended) illustrates this. Thanks for the test. The two bytes you are talking about are: 13 <cr>, 10 <lf> Unix doesn't need these. Win32 api (Mingw default) platforms do. > > I didn't find any mention of this at the egroups > archive, which is why I am posting to this list. Is > anyone familiar with this bug? It's an MS "Feature". > Is there a workaround? Might really be a bug with gcc... Can anyone, off the top of their head, be more specific on this aspect of Mingw gcc? Thanks, Paul G. > > Thanks, > Bev > > > /* Test program to illustrate bug in Mingw gcc-2.95.2 > stdio/libc routine fputc. > The program is supposed to write a single byte to > test.dat, namely the > integer value entered at runtime. It works > correctly except for the > integer value 10. In that case, it writes out 2 > bytes: 13,10. */ > > #include <stdio.h> > > void main () > { > int a; > FILE *fp; > > printf("Enter integer (0-255) to write to file > test.dat: "); > scanf("%d",&a); > > fp = fopen("test.dat","w"); > putc(a,fp); > fclose(fp); > } > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/?.refer=text > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options at: > http://lists.sourceforge.net/lists/listinfo/mingw-users > Nothing real can be threatened. Nothing unreal exists. |
From: Paul G. <pga...@qw...> - 2001-03-31 02:44:24
|
Hi folks, On 29 Mar 2001, at 21:36, the Illustrious Greg Chicares wrote: > Paul Garceau wrote: > > > > On 29 Mar 2001, at 14:13, the Illustrious Edmund Bertschinger wrote: > > > [...] > > > Right away I discovered what seems to be a bug in > > > the standard library routine fputc (and also fwrite): > > > If one tries to write a single byte with integer value > > > 10, fputc writes *two* bytes: 13,10. > > > > Thanks for the test. > > > > The two bytes you are talking about are: > > > > 13 <cr>, 10 <lf> > > > > Unix doesn't need these. > > > > Win32 api (Mingw default) platforms do. > > In (default) text mode, dos/windows translates '\n' (linefeed) to > '\r\n' because that's the operating system's (default) convention > for terminating lines. Since C is historically associated with unix, ms > couldn't very well require people to write '\r' in > fprintf("This is a line with a line terminator\r\n"); > so they translated '\n' to '\r\n' in the output functions (and did > the reverse in the input functions). > > One consequence that may seem puzzling without that information > is that the program writes a two-byte file if '10' is entered, > but a one-byte file if '1' is entered. > > As Javier points out, you can prevent that translation by opening > the file in binary mode. > > > Might really be a bug with gcc... > > But doesn't mingw use a C runtime library written by ms? Nope. Peace, Paul G. > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options at: > http://lists.sourceforge.net/lists/listinfo/mingw-users > Nothing real can be threatened. Nothing unreal exists. |
From: Greg C. <chi...@mi...> - 2001-04-02 04:28:16
|
Paul Garceau wrote: > > On 29 Mar 2001, at 21:36, the Illustrious Greg Chicares wrote: > > > But doesn't mingw use a C runtime library written by ms? > > Nope. Perhaps I haven't been paying enough attention. This page http://www.mingw.org/index.shtml still says "At the basic level, MinGW is a set of include files and import libraries that allow a console-mode program to use Microsoft's standard C runtime library MSVCRT.DLL" Have we got a replacement for the ms C runtime now? |
From: Earnie B. <ear...@ya...> - 2001-04-02 12:26:57
|
Paul Garceau wrote: > > Hi folks, > > On 29 Mar 2001, at 21:36, the Illustrious Greg Chicares wrote: > > > > > But doesn't mingw use a C runtime library written by ms? > > Nope. > Paul, you need a nice strong cup of coffee!?! Yes, MinGW uses the C runtime supplied by Microsoft. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Paul G. <pga...@qw...> - 2001-03-31 02:54:30
|
Hi folks, On 30 Mar 2001, at 9:54, the Illustrious Earnie Boyd wrote: > Paul Garceau wrote: > > > > > > Might really be a bug with gcc... > > > > Can anyone, off the top of their head, be more specific on > > this aspect > > of Mingw gcc? > > > > Stop spreading such rumors. Yes sir...<g> > No, it's a MS feature as you said, not a > bug in gcc. Use the rule of thumb: > > If someone can create the file with Notepad then open the file in text > mode processing otherwise use binary mode processing. Peace, Paul G. > > Earnie. > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > Nothing real can be threatened. Nothing unreal exists. |
From: Greg C. <chi...@mi...> - 2001-03-30 12:54:21
|
Paul Garceau wrote: > > On 29 Mar 2001, at 14:13, the Illustrious Edmund Bertschinger wrote: > [...] > > Right away I discovered what seems to be a bug in > > the standard library routine fputc (and also fwrite): > > If one tries to write a single byte with integer value > > 10, fputc writes *two* bytes: 13,10. > > Thanks for the test. > > The two bytes you are talking about are: > > 13 <cr>, 10 <lf> > > Unix doesn't need these. > > Win32 api (Mingw default) platforms do. In (default) text mode, dos/windows translates '\n' (linefeed) to '\r\n' because that's the operating system's (default) convention for terminating lines. Since C is historically associated with unix, ms couldn't very well require people to write '\r' in fprintf("This is a line with a line terminator\r\n"); so they translated '\n' to '\r\n' in the output functions (and did the reverse in the input functions). One consequence that may seem puzzling without that information is that the program writes a two-byte file if '10' is entered, but a one-byte file if '1' is entered. As Javier points out, you can prevent that translation by opening the file in binary mode. > Might really be a bug with gcc... But doesn't mingw use a C runtime library written by ms? |
From: Earnie B. <ear...@ya...> - 2001-03-30 14:54:45
|
Paul Garceau wrote: > > > Might really be a bug with gcc... > > Can anyone, off the top of their head, be more specific on this aspect > of Mingw gcc? > Stop spreading such rumors. No, it's a MS feature as you said, not a bug in gcc. Use the rule of thumb: If someone can create the file with Notepad then open the file in text mode processing otherwise use binary mode processing. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Jeff S. <js...@de...> - 2001-03-30 20:09:47
|
On Fri, 30 Mar 2001, Earnie Boyd wrote: > Paul Garceau wrote: > > Might really be a bug with gcc... > > Stop spreading such rumors. No, it's a MS feature as you said, not a > bug in gcc. Use the rule of thumb: Earnie, that's still missing the point. It's an ISO C feature, which doesn't specify how text mode files are written. Don't blame MS. If you like, blame Unix for interpreting text and binary I/O the same, leading to scores of programs which use e.g. fopen(... "w+") to perform binary I/O. All these programs are incorrect, strictly speaking. GNU glibc handles "w+b" just fine (as it must) even though the `b' is ignored. -- Jeff Sturm jef...@co... |