From: Daniel J S. <dan...@ie...> - 2004-06-01 18:47:52
|
Hans-Bernhard Broeker wrote: >On Tue, 1 Jun 2004, Daniel J Sebald wrote: > > >>Hans-Bernhard Broeker wrote: >> >> > >[...] > > >>>So the choice is this: either we finally and officially discontinue all >>>support for K&R compilers, or we make such parameters int everywhere. >>> >>> > > > >>I'm beginning to follow this thread... My first thought is to not >>discard the K&R convention without a compelling argument, given that I'm >>sure a lot of people put a lot of effort into making it compatible. >> >> > >Well, let's just say that lack of people with regular exposition to >platforms to test K&R compatibility on is about as compelling an argument >as they come. Only after the release, when it was altogether too late, >did anybody even think of testing this on an actual K&R compiler. And >they failed. > > > >>The TBOOLEAN stuff didn't seem like all that much trouble. >> >> > >Trouble enough that it broke in rather subtle ways on some platforms >before I changed it in 3.8k.2 (?), a couple of weeks before the 4.0 >release. Now, after that change, it's broken in other, not quite as >subtle ways, on other platforms. > > > >>What are the issues with char in K&R C functions? >> >> > >The issue is not so much with char itself, but with the lack of function >prototypes. This means that all argument types of functions external to a >source module, and optionally those from inside, too, are implicitly >defined only, > That's the problem I'm experiencing. > and one of the effects of that is that all integer types >smaller than int (i.e. char, and maybe short, too) get casted to int >before being passed to a function. > > > >>Certainly, that is almost all they worked with at the time of its >>writing, i.e., putchar, getchar. >> >> > >No. Look at the actual definition of these functions, still conserved >from the K&R days, through both ANSI/ISO C standards, and still valid >for a current Linux box: > > int putchar(int c); > >That argument is an int, not a char, for exactly the reasons we're >discussing here. > Really?! A function called "putchar" whose argument is an "int" rather than "char"? Nice. Dan |