K&R C (was Re: Bugs in enhanced mode)

[Hans-Bernhard B. <br...@ph...>]

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, 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.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.