🚀 go-pugleaf

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.