gnuplot-beta

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.

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

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

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

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

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

Daniel J Sebald wrote:

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


Would this be a tolerable hack?  Define a special type in some header 
for char's as function arguments

/* Throwback to K&R */
#ifdef __STDC__
#define ACHAR char
#else
#define ACHAR int
#endif

do_enh_writec(ACHAR c)

Hopefully there aren't too many, and it might be fairly easy to search 
them out, e.g.,

grep char */* > junk
xemacs junk
(in xemacs search for '\nchar' because function arguments start in first 
column)

.....

Anyway, is gnuplot.texi a generated file?  (I see something called 
doc2texi.el)  If so, should it be in the cvsignore list so that it isn't 
checked out when getting the latest CVS version?

Dan

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

[Allin C. <cot...@wf...>]

On Tue, 1 Jun 2004, Daniel J Sebald wrote:

> Would this be a tolerable hack?  Define a special type in some header
> for char's as function arguments
>
> /* Throwback to K&R */
> #ifdef __STDC__
> #define ACHAR char
> #else
> #define ACHAR int
> #endif

I strongly support the suggestion put forward by Hans-Berhard a few
days ago, namely that support for 'K&R' should be dropped.  I'm not
aware of any other serious software package that insists on supporting
pre-1989 C compilers.  The effect is simply to complicate and
obfuscate the gnuplot code.

I'm aware that I don't have much standing in this debate because I
have not contributed much to gnuplot.  On the other hand, I'd be more
inclined to contribute were it not for the weird archaisms in the
gnuplot code base.

How many people are there in the world who refuse to use an ISO/ANSI C
compiler, but who want to be able to compile the latest and greatest
gnuplot?

Allin Cottrell

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

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

Allin Cottrell wrote:

>On Tue, 1 Jun 2004, Daniel J Sebald wrote:
>
>  
>
>>Would this be a tolerable hack?  Define a special type in some header
>>for char's as function arguments
>>
>>/* Throwback to K&R */
>>#ifdef __STDC__
>>#define ACHAR char
>>#else
>>#define ACHAR int
>>#endif
>>    
>>
>
>I strongly support the suggestion put forward by Hans-Berhard a few
>days ago, namely that support for 'K&R' should be dropped.  I'm not
>aware of any other serious software package that insists on supporting
>pre-1989 C compilers.  The effect is simply to complicate and
>obfuscate the gnuplot code.
>

That's true.  But I'm guessing one of the philosophies of Gnuplot is to 
accommodate as wide an audience as reasonably possible and to not 
continually squeeze out groups of users.  (If Gnuplot were trying to 
make a profit, different philosophy...)  I'll leave it up to those more 
familiar with software to decide if there is that wide of a K&R group 
left.  But, if there is support for a VAX, I would assume that 
supporting K&R C isn't that unreasonable.

Seriously, I've no strong opinion.  In fact, K&R have web pages.  Could 
drop them a short note and get their opinion.

>I'm aware that I don't have much standing in this debate because I
>have not contributed much to gnuplot.  On the other hand, I'd be more
>inclined to contribute were it not for the weird archaisms in the
>gnuplot code base.
>
>How many people are there in the world who refuse to use an ISO/ANSI C
>compiler, but who want to be able to compile the latest and greatest
>gnuplot?
>

Well, apparently Petr tried, hence the note in the source code.

Dan

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

[Lars H. <lhe...@us...>]

Daniel J Sebald writes:
[...]

 Daniel, please trim your replies. There is absolutely no point in quoting
 the whole previous message in your reply, please show some consideration.
 
> Anyway, is gnuplot.texi a generated file?  (I see something called 
> doc2texi.el)  If so, should it be in the cvsignore list so that it isn't 
> checked out when getting the latest CVS version?
 
 Yes, it's a generated file. I'd like to leave it in cvs because some
 people  may not have some form of emacs installed, and because .texi
 is a generic format that many other forms of documentation can be derived
 from.

Allin Cottrell writes:
[...] 
> How many people are there in the world who refuse to use an ISO/ANSI C
> compiler, but who want to be able to compile the latest and greatest
> gnuplot?

 It's not a question of refusal. Some systems out there have K&R compilers
 only, if they come with a compiler at all, and cannot be upgraded for
 some reason.

 That said, we should move to ISO/ANSI C, and let ansi2knr sort it out.
 As Lucas and myself recently found it, tis in turn will require a few
 changes in the code.