Re: Bugs in enhanced mode

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>[Taken over to the list, because of the fundamental issue at the bottom.]
>
>On Wed, 26 May 2004, Ethan Merritt wrote:
>
>  
>
>>I thought it looked wrong at the time, but I haven't had time to look at
>>it in detail.
>>    
>>
>
>Feels familiar.  I handed out my PhD thesis to the institution yesterday,
>5 minutes before the deadline at noon.  Phew ;-)
>

(Feels familiar, the deadline thing.)

>>In paticular the change that broke things was in term.c:
>>    static void do_enh_writec __PROTO((int c));
>>  	   /* note: c is char, but must be declared int due to an old K&R ANSI-C strict HP cc */
>>    
>>
>
>Ah, now I see more clearly.
>
>But actually, as long as gnuplot is supposed to be compilable under K&R C,
>which it is(!), Petr's change did go in the right direction.  It just
>didn't go far enough. In K&R C, function arguments indeed can't be char
>without causing all kinds of problems.  But neither can you cast function
>pointers to functions of a different signature and expect the resulting
>code to work.
>
>So the choice is this: either we finally and officially discontinue all
>support for K&R compilers, or we make such parameters int everywhere.  
>
>Given all the troubles with TBOOLEAN (which are actually essentially the
>same thing, since TBOOLEAN ends up as char on K&R compilers), I tend
>towards declaring K&R C dead.  But if we do that, we should at least split
>off a development branch (4.1) first, and do it there.
>

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. 
 (And I'm not K&R biased.  Having learned C on PCs, I've come to toss 
software convention to the wind.)  The TBOOLEAN stuff didn't seem like 
all that much trouble.

What are the issues with char in K&R C functions?  Certainly, that is 
almost all they worked with at the time of its writing, i.e., putchar, 
getchar.  That is, do_enh_writec() is so similar to putchar() that I 
can't see where the trouble arises?  What's the deal with the old HP 
compiler?  Is that the thing causing problems?  What do some of its 
standard headers look like for compatibility, e.g., putchar()?

Dan