robertj@yale-zoo-suned..arpa (Rob Jellinghaus) (10/13/87)
I recently got bitten badly by a bug in LSC 2.11's stdio routines (at least I think that's where the bug is). I was trying to use the unix emulation routines that simulate redirection of output. The problem I discovered is that when I try to send a character code 13 (octal 15) to a file, when I next read the file, the character code has changed to 10 (12 octal). This screwed me up, badly, until I found it. (My program worked when I ported it to our unix system.) Here are two short demo programs to illustrate the bug: /* #1: I ran this, entering
singer@endor.harvard.edu (Richard Siegel) (10/13/87)
Your demo program didn't make it, but the bug is in fwrite, and occurs
when you're trying to write to a binary file. The offending line is in
the source file called "stdfwrite.c", one of the stdio source files.
The offending line is:
*(who->filebuf + who->fpos++) = ((!who->binary) && (*ptr == '\n'))?'\r':*ptr;
I'm not a C guru, and this line is nearly incomprehensible, but I'd
guess that this is where it happens.
Since you have the sources, the fix won't be too difficult to make, and I've
noted the problem, and it will be fixed in a future release of the libraries.
--Rich
**The opinions stated herein are my own opinions and do not necessarily
represent the policies or opinions of my employer (THINK Technologies, Inc).
* Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer *
* Customer Support | singer@endor.harvard.edu *
* THINK Technologies, Inc. (No snappy quote) *gardner@prls.UUCP (Robert Gardner) (10/13/87)
In article <17539@yale-celray.yale.UUCP> robertj@yale.UUCP writes: >I recently got bitten badly by a bug in LSC 2.11's stdio >routines (at least I think that's where the bug is). >The problem I discovered is that >when I try to send a character code 13 (octal 15) to a file, >when I next read the file, the character code has changed to 10 This is a 'feature' (quite useful, actually) since C string routines usually expect 10 for new lines, but Mac routines such as text edit expect 13 for new lines, so on output stdio changes 10's to 13's so the file can be used by other Mac programs and on input changes 13's to 10's so C routines are happy. This can be over-ridden with the "b" flag when opening the file. Unless there is a bug I haven't encountered, everything works fine as long as LSC both writes and reads the file (and most other times, as well). (Megamax, and I suppose most other C compilers, does the same.) (MacWorld didn't even mention Megamax in their recent "review" of C compilers -- is it still available?) The reason I'm answering this instead of letting the THINK person do it is that I've found what I consider to be a bad bug with this conversion process. It only happens when going to/from disk and not to/from the console (at least when using getchar()). I ported cdecl to LSC and found I had to change its NEWLINE definition from 10 to 13 to get it to recognize Returns as end-of-line. This means that this program will NOT work correctly if I redirect stdin to a file. I have used LSC very happily for a long time and only recently started using stdio, unix, etc. since I am now writing programs that need to be run on a Unix VAX. In the two or three weeks I've been doing this I have come across several bugs, this is the third I've posted already. It seems that THINK was not very careful with their stdio implementation and verification, though the rest of it is wonderful. Luckily, most Mac programmers don't use stdio and unix routines, though I've found I'd much rather program in LSC than on our VAX! Robert Gardner P.S. cdecl is a very useful program that declares variables and explains variable declarations for you. For instance, it will tell you how to declare a "pointer to function returning pointer to function returning pointer to char" or what on earth int **(xx())(); is declaring (if anything). Source is available in comp.sources.unix. You need access to a unix machine, yacc, and lex, however. Anyone wanting LSC source that doesn't have such access can contact me.
socha@drivax.UUCP (Henri J. Socha (7-x6628)) (10/13/87)
In article <17539@yale-celray.yale.UUCP> robertj@yale.UUCP writes: >I recently got bitten badly by a bug in LSC 2.11's stdio >routines (at least I think that's where the bug is). I was >trying to use the unix emulation routines that simulate >redirection of output. The problem I discovered is that >when I try to send a character code 13 (octal 15) to a file, >when I next read the file, the character code has changed to 10 >(12 octal). I got it too for the longest time but know the fix! In my case it was a demo programme that generate test patterns wrote them to a file and read the result and kept getting the same error, got a 10 (on re-read) expected 13. In the fopen (or whatever, I don't have LSC or my code here). there are options available defining the TYPE of file being opened. One of the type flags (letters?) specifies a BINARY file. I forget the LSC term but its bin called: O_BINARY, O_RAW, or something like that. Anyway, if you specify that flag, the test inside stdio.??? is not made. So, in your open, specify the flag and the problems go away. -- UUCP:...!amdahl!drivax!socha WAT Iron'75 "Everything should be made as simple as possible but not simpler." A. Einstein
kearns@garfield.columbia.edu (Steve Kearns) (10/14/87)
Hi. Are you sure that this is a bug? I was bitten by this "feature" before. Actually, if it is the same problem I have, then the problem is that you should open the file for reading with the options "wb" instead of just "w". Changing cr to cr/lf or just to lf is a feature that ensures that all text files look the same. Adding the "b" option when you open the file sets a flag that determines whether the stdio code makes the cr/lf substitution or not. Obviously, if you have a binary file you dont want it randomly substituting numbers for numbers; this is what the "b" option is for. I didn't look closely at the line, but I bet it is correct.
singer@endor.harvard.edu (Richard Siegel) (10/14/87)
In article <6769@prls.UUCP> gardner@prls.UUCP (Robert Gardner) writes: >It seems that THINK was not very careful with their stdio implementation >and verification, though the rest of it is wonderful. Luckily, most Well, um, er.... As a matter of fact, the stdio and unix libraries *are* going to get reworked, and will be available for the next release of LightspeedC, if not sooner. I do appreciate the comments... --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies, Inc). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * THINK Technologies, Inc. (No snappy quote) *