gnuplot-beta

Re: Bugs in enhanced mode

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

[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 ;-)

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

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

Re: Bugs in enhanced mode

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

On Wed, 26 May 2004, Ethan Merritt wrote:

> On Wednesday 26 May 2004 08:54 am, 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.
> >
> > 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.
> 
> But what does that mean in terms of handling the current problem?

It means that we revert Petr's patch iff we decide to go ANSI C now, or
extend it if we want to stick with K&R compatibility.

> I assume that there will be a version 4.0 patch level 1 that corresponds
> to the state of the CVS tree at the time of the split, and any known
> problems in it should be at the least documented.

Tagging/releasing a 4.0.1 would not necessarily have to do anything to do
with the split-off of a development branch.  Right now, I don't see a
pressing need for a 4.0.1.  The post-release bug fixes are still quite
small.

> My inclination would be to leave the 4.0 code the way it was before
> Petr's change, and simply add a "known bugs" note that the HP compiler
> mis-handles the enhanced-text code.  

That statement would be a misrepresentation of fact.  The problem really
is in our code, not in their compiler.  Lars tried to build 4.0 on SunOS
4's K&R compiler, and observed similar problems.

> There may be other K&R compilers that also complain, but we haven't
> heard bug reports from them yet.

As I said: SunOS has complained, if only in private.

> We would still need something like the TBOOLEAN hack for K&R 
> compilers suggested in bug report #953887.

Right.  And that could probably be built into the TBOOLEAN macro block (at
the end of syscfg.h) which I changed shortly before the release,
triggering all this.  We could typedef _Bool to int if we're on K&R C.  
And we would have to change over to ANSI prototypes for all functions with
TBOOLEAN arguments to pacify the pickier ANSI C compilers, while at it.  
Let ansi2knr handle the needs of K&R compilers.

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

Re: Bugs in enhanced mode

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 26 May 2004 10:03 am, Hans-Bernhard Broeker wrote:
> On Wed, 26 May 2004, Ethan Merritt wrote:
> > But what does that mean in terms of handling the current problem?
>
> It means that we revert Petr's patch iff we decide to go ANSI C now, or
> extend it if we want to stick with K&R compatibility.

How about if we define a new type in gp_types.h

#undef CHAROUT
#ifdef KR		/* I don't know what the proper test is for K&R */
#typedef int CHAROUT
#else
#typedef char CHAROUT
#endif

and then change all the enhanced text function with a char argument
to have a CHAROUT argument instead.  That reduces the chance of
breaking compilation on platforms for which the existing code works,
and still allows us to accommodate K&R's dislike of char arguments.
e.g.
	static void do_enh_writec __PROTO((CHAROUT c));

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Bugs in enhanced mode

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

On Wed, 26 May 2004, Ethan Merritt wrote:

> On Wednesday 26 May 2004 10:03 am, Hans-Bernhard Broeker wrote:
> > On Wed, 26 May 2004, Ethan Merritt wrote:
> > > But what does that mean in terms of handling the current problem?
> >
> > It means that we revert Petr's patch iff we decide to go ANSI C now, or
> > extend it if we want to stick with K&R compatibility.
> 
> How about if we define a new type in gp_types.h
> 
> #undef CHAROUT
> #ifdef KR		/* I don't know what the proper test is for K&R */
> #typedef int CHAROUT
> #else
> #typedef char CHAROUT
> #endif

Nah, that's terminally ugly. ;-)

If the change to 'int' for K&R can work (needs a bit of testing), then
the same 'int' will work for ANSI C, too.  So making this distinction
would serve no useful purpose.

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

Re: Bugs in enhanced mode

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 26 May 2004 08:54 am, 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.
>
> 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.

But what does that mean in terms of handling the current problem?
I assume that there will be a version 4.0 patch level 1 that corresponds
to the state of the CVS tree at the time of the split, and any known
problems in it should be at the least documented.

My inclination would be to leave the 4.0 code the way it was before
Petr's change, and simply add a "known bugs" note that the HP compiler
mis-handles the enhanced-text code.  There may be other K&R compilers
that also complain, but we haven't heard bug reports from them yet.

We would still need something like the TBOOLEAN hack for K&R 
compilers suggested in bug report #953887.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

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