espen@well.UUCP (Peter Espen) (02/20/88)
Why doesn't the following code send a single character to the
stdio window when it is compiled???
#include <stdio.h>
main()
{
char c = 'A';
putchar(c);
}
This should just work, right???
Peter Espenclive@drutx.ATT.COM (Clive Steward) (02/22/88)
From article <5267@well.UUCP>, by espen@well.UUCP (Peter Espen): > > Why doesn't the following code send a single character to the > stdio window when it is compiled??? > > #include <stdio.h> > > main() > { > char c = 'A'; > > > putchar(c); Maybe because putchar () takes an int as a passed parameter, instead of a char? This is the sort of thing that function prototypes (turn that option on in your Lightspeed system) are for. And yes, there are good reasons why putchar takes an int. One wishes consistency, and all operations that return a char to be used, actually return it as an int, so that code (EOF) outside of the range of chars can be used to inform you of unavailability. The manual, or especially reading Kernighan and Ritchie, the C white book, will help. Clive Steward
clive@drutx.ATT.COM (Clive Steward) (02/23/88)
Subject: Lightspeed fputc problem -- easy answer, hope fix in 3.0 Newsgroups: comp.sys.mac References: <6802@drutx.ATT.COM> Well, I should have tried this one before posting. I wasn't accurate as to the real problem, and neither was Dave Platt coherent!dplatt, who sent unix-gruish mail on the subject. More on that at the end. The real difficulty, doped out in the library sources, is that the LSC library function Init_stdio () doesn't always get called automatically, as it's supposed to. For now (we can hope it'll be fixed in 3.0), it's sufficient to call Init_stdio () once yourself right at the beginning of your main () program. It will self-protect against being re-called later. The actual problem is that any variant which ends up internally calling fputc (), as putchar () does, will fail unless it's after something like printf (), which happens to actually force the initialization. The apparent problem is that the initial data for the _file[] array's stdout (_file[1]) is apparently now not correct. I don't have the source for the current (2.15) libraries, so can't see it there (in stddata_file.c), but did print out actual contents by copying the FILE structs into dummys before calling any print/put code. On stdin, the InUse bit is properly set; on stdout, it's not, though the other relevant info I checked seemed ok. Then when fputc checks for InUse as a file-active flag, it fails there, returning -1 (EOF) as it should. And thus never calls putch (), which would have done the Init_stdio () and fixed this. Please copy, Rich Siegal/ LightSpeed people.
dorner@uxc.cso.uiuc.edu (02/24/88)
>Maybe because putchar () takes an int as a passed parameter, instead of a char? > >This is the sort of thing that function prototypes (turn that option >on in your Lightspeed system) are for. I beg to differ. Kernighan and Ritchie (p. 42) guarantees that character arguments are widened to ints. To quote a wise man: >The manual, or especially reading Kernighan and Ritchie, the C white >book, will help. >Clive Steward ---- Steve Dorner, U of Illinois Computing Services Office Internet: dorner@uxc.cso.uiuc.edu UUCP: ihnp4!uiucuxc!dorner IfUMust: (217) 333-3339