rlcarr@athena.mit.edu (Rich Carreiro) (08/11/88)
NOTE: I HAVE INSTALLED BOTH LATTICE C PATCHES.
I just had the misfortune to call Lattice's Tech support line.
My problem was over two things. First, on page 7-3 of the manual,
under the "Not enough memory" error message explanation it says
something like "if you get this error, try compiling with the -B
option to LC. This invokes the big compiler, etc., etc." Well,
whenever I tried to use it, it dies. When I type:
lc -B foo
I get:
<compiler startup messages>
Invalid option "--B" (yes, that's two dashes)
Upon calling Lattice all they cpuld say was that "it should work" and
"try playing around with command line order." Well, I did so, and if
I do 'lc foo -B' the -B is interpreted as a file to compile. Sad
customer support number example number 1. So, can anyone explain how
to use the damn -B option?
Problem 2:
I have the following code:
#include <stdio.h>
main()
{
int i;
puts("Enter any number to continue:\n");
scanf("%d",&i);
}
When I run it, the "Enter..." message IS NOT PRINTED until I enter a
number and hit <CR>. Then the message is printed and the program
ends. If I use printf(), the problem goes away. The Lattice tech
support man says this is not a bug, but is a problem with the C
language. I then tried this program under BSD 4.3, on a uVAX, Ultrix
5.5 on a uVAX, and BSD 4.2 on a Sun 3/160. It worked properly on all
three. So, can anyone explain this "bug" to me?
Thanks!
ARPA: rlcarr@athena.mit.edu
UUCP: ...!mit-eddie!athena.mit.edu!rlcarr
BIT: rlcarr%athena.mit.edu@mitvma.mit.edu
*******************************************************************************
* Rich Carreiro "MIT isn't Hell. It's where you go when *
* rlcarr@athena.mit.edu you've been bad in Hell." - Anon. *
*******************************************************************************rss@ece-csc.UUCP (ML) (08/12/88)
In a previous article rlcarr@athena.mit.edu (Rich Carreiro) wrote: > >I have the following code: >#include <stdio.h> >main() >{ > int i; > puts("Enter any number to continue:\n"); > scanf("%d",&i); >} > >When I run it, the "Enter..." message IS NOT PRINTED until I enter a >number and hit <CR>. Then the message is printed and the program >ends. If I use printf(), the problem goes away. The Lattice tech >support man says this is not a bug, but is a problem with the C >language. I then tried this program under BSD 4.3, on a uVAX, Ultrix >5.5 on a uVAX, and BSD 4.2 on a Sun 3/160. It worked properly on all >three. So, can anyone explain this "bug" to me? >Thanks! > The "bug" is that "puts" is not flushing the file buffer after writing the string to it. As a workaround, put "fflush(stdout);" after the "puts()" statement. I agree that this is annoying. I've noticed this problem also with "putc/putchar" -- doing a "putchar('\n');" really should cause the current line to be printed; but it in fact doesn't seem to. (This applies only to line buffered streams, i.e., stdout). "Stderr" should be completely unbuffered, as least to fall in line with typical Unix implementations, but I've noticed the same problems with it though. IMHO, the Lattice tech guy's answer was a cop out. "Putc()" should flush buffers for line buffered streams when it outputs a newline char, and commands like "printf" and "puts" should act as if they functioned by repeated calls to "putc". I suppose though that I couldn't accurately say his answer was *wrong*, being in that the stdio library is simply that -- a library -- and not part of the C language proper, so you can implement things however you feel (current efforts by ANSI committee notwithstanding). Warning: I'm still using Lattice 3.10 (I'll wait til the next version comes out before I consider upgrading), so not everything I say may apply. A question: With V4.x, have they fixed the annoying warning message which always pops up when you use "putchar/putc" with a character constant -- "Warning: constant converted to required type"? It's very bothersome seeing perfectly reasonable statements like "putchar('\n')" generate warning messages. Mark Lanzo c/o ...!mcnc!ece-csc!rss
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (08/12/88)
In article <6627@bloom-beacon.MIT.EDU>, rlcarr@athena.mit.edu (Rich Carreiro) writes: > So, can anyone explain how > to use the damn -B option? I don't find a -B option for LC. However, I do find a -b option. That's probably what went wrong here. When you talked to the Lattice Tech Support folks did you specify you were using a capital B? > #include <stdio.h> > main() > { > int i; > puts("Enter any number to continue:\n"); > scanf("%d",&i); > } > > When I run it, the "Enter..." message IS NOT PRINTED until I enter a > number and hit <CR>. Then the message is printed and the program > ends. I believe puts() simply writes characters to a buffer. It may be implemented as a macro. Consequently, whey you use puts() for a short prompt string you don't see anything until the buffer is flushed. The reason you see it when you press <CR> is that your program terminates and all the buffers are flushed. If you want to flush the buffers before that try flushall() or fflush() (described on page F-62). --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3 ...uunet!pdn!jc3b21!fgd3
peter@sugar.uu.net (Peter da Silva) (08/12/88)
In article <3750@ece-csc.UUCP>, rss@ece-csc.UUCP (ML) writes: > seem to. (This applies only to line buffered streams, i.e., stdout). > "Stderr" should be completely unbuffered... Even better would be to adopt the Berkeley stdio convention, and have filbuf on an interactive stream do a flush on all interactive output streams. That way you get the correct result when you print a prompt, and you don't have an extra check on every character output. Stderr should, indeed, be unbuffered. Or at least it should flush after every call to stdio. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
rlcarr@athena.mit.edu (Rich Carreiro) (08/13/88)
In article <446@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: >In article <6627@bloom-beacon.MIT.EDU>, rlcarr@athena.mit.edu (Rich Carreiro) writes: >> So, can anyone explain how >> to use the damn -B option? >I don't find a -B option for LC. However, I do find a -b option. That's >probably what went wrong here. When you talked to the Lattice Tech Support >folks did you specify you were using a capital B? Look on page 7-3 of your Lattice 4.0 manual, in the explanation of the "Not Enough Memory" compiler error. It says that in the event of this error, try 'LC -B foo' to get the "big compiler." This is the ONLY place in the manual where the flag is mentioned. Furthermore, the tech fool on the phone confirmed that the option is supposed to be there. It makes the compiler do things like use the disk rather than memory during the compile and things like that. He was utterly suprised that it didn't work. Mind you, he didn't check it either. I should probably post it to the Lattice BBS, maybe someone will notice it. Anyway, I'm not particularly thrilled with their support. Too bad more people weren't like Tom Rokicki. ******************************************************************************* * Rich Carreiro "MIT isn't Hell. It's where you go when * * rlcarr@athena.mit.edu you've been bad in Hell." - Anon. * *******************************************************************************
scott@applix.UUCP (Scott Evernden) (08/13/88)
In article <6627@bloom-beacon.MIT.EDU> rlcarr@athena.mit.edu (Rich Carreiro) writes: > lc -B foo >Upon calling Lattice all they cpuld say was that "it should work" and Heh, hmm. The obvious is true: a case of msdositis. This (-B switch) is a Lattice ->MSDOS<- 3.x feature (see page C-1 Vol 1 Lattice C Compiler V3 for MS-DOS Prog Ref). Have you (proudly) identified yourself as an Amigoid?? Lattice Tech Support should be saying "Never mind...". -scott
hah@mipon3.intel.com (Hans Hansen) (08/14/88)
In article <6627@bloom-beacon.MIT.EDU>, rlcarr@athena.mit.edu (Rich Carreiro) writes: > So, can anyone explain how > to use the damn -B option? I think I read that you need to use -B0. ^ Hans
rlcarr@athena.mit.edu (Rich Carreiro) (08/15/88)
In article <779@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: ]In article <6627@bloom-beacon.MIT.EDU> rlcarr@athena.mit.edu (Rich Carreiro) writes: ]] lc -B foo ]]Upon calling Lattice all they cpuld say was that "it should work" and ] ]Heh, hmm. The obvious is true: a case of msdositis. This (-B switch) is ]a Lattice ->MSDOS<- 3.x feature (see page C-1 Vol 1 Lattice C Compiler V3 ]for MS-DOS Prog Ref). ]Have you (proudly) identified yourself as an Amigoid?? ]Lattice Tech Support should be saying "Never mind...". ] ]-scott Oh yes, I most certainly said I had an Amiga. Mr. Technical Non-Support first tells mt that my disks should have the programs LC1B and LC2B on them. I assured him this was not the case. He seemed exceedingly puzzled then said "Oh, that's right, you have AmigaDOS. Then it's the same programs. However, he continued to insist that -B is a valid option. Not wanting to waste the money on another prime-time phone call from here to Illinois, I then decided to ask the Net, the members of which I am sure are more qualifies than that poor excuse for a technical supprt man. ******************************************************************************* * Rich Carreiro "MIT isn't Hell. It's where you go when * * rlcarr@athena.mit.edu you've been bad in Hell." - Anon. * *******************************************************************************
tope@enea.se (Tommy Petersson) (08/16/88)
In article <446@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: >In article <6627@bloom-beacon.MIT.EDU>, rlcarr@athena.mit.edu (Rich Carreiro) writes: >> puts("Enter any number to continue:\n"); >> scanf("%d",&i); > >I believe puts() simply writes characters to a buffer. It may be >implemented as a macro. Consequently, whey you use puts() for a short >prompt string you don't see anything until the buffer is flushed. The >reason you see it when you press <CR> is that your program terminates and >all the buffers are flushed. If you want to flush the buffers before that >try flushall() or fflush() (described on page F-62). (void) fflush (stdout) should work, but as observed it works anyway on a lot of computer systems. Normally a read from stdin flushes stdout first. Since the standard library is not a part of the C language, it's implementation dependent. This is just what I think, haven't started Amiga programming yet. (just VAX-es and VAX-es...). A lot of C systems (I think Lightspeed C on Mac, for one) includes the source for the standard library. Maybe something could be "stolen" from there. On a lot of systems the buffering or direct screen output is settable on a system level, the C or Fortran or Pascal program all calls the same system routine. The programmer doesn't notice this, it just works.