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.