Re: Fun with VMS, TBOOLEAN, macro definitions and DECC

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

On Mon, 3 May 2004, Lucas Hart wrote:

> On Mon, May 03, 2004 at 05:48:58PM -0700, Ethan Merritt wrote:
> > Disclaimer:
> > I had never built, nor run, gnuplot under VMS until today.
> > I was just curious, and this is what I found.
> 
> I'm working on updating CONFIGURE.VMS to gnuplot v4.0.0 and have
> encountered the same behaviour that you report.  

Sigh... Guys, what do you think I put out 4 weeks' worth of
release-candidate tarballs for?  Didn't it occur to anyone that _then_
would have been the right time to run this kind of test, and report any
problems, rather than now, after the release?

> > %%%%%%%%% Unhappy TBOOLEANs
> > 
> > $ cc /DEFINE=(NO_GIH,HAVE_CONFIG_H,DECCRTL)/INCLUDE=[-]/PREFIX=ALL axis.c
> > 
> >     TBOOLEAN checkrange;
> > .............^
> > %CC-W-PROMOTMATCHW, In the definition of the function "axis_unlog_interval",
> > the promoted type of checkrange is incompatible with the type of the corresponding
> > parameter in a prior declaration.

I never used VMS to build any programs, but I take it this is a warning,
not an error message, right?  Do we have reason to believe it actually
breaks anything?

> > at line number 188 in file $DISK1:[MERRITT.GNUPLOT.SRC]AXIS.C;1
> > 
> 
> Do you have stdbool.h?  If so, define HAVE_STDBOOL in config.h
> 
> Question: why is _Bool defined as unsigned char in syscfg.h? 

Because that's what GNU autoconf suggests it to be defined as in absence
of both <stdbool.h> and a predefined _Bool type, and because that's what
makes the most sense.  And because some other platforms objected
when we defined it as (unsigned) int, before.

> My understanding is that C99 types it as unsigned int, which DECC
> appears to expect.

C99 types it as a new atomic data type.  It's an integer data type, but
there's no particular reason whatsoever to assume it should be as large as
an entire int.  That would be quite wasteful, after all.

I'm quite sure DECC expects neither unsigned int nor char here --- C99 is
a non-existant concept in its view of the world.

[Function-like macro missing do { } while(0) bracket]
> A simpler fix is 
>   if (something) {
>     PRINT0(...); 
>   } else if (something) {
>     PRINT1(...);
>   }

That's not exactly a fix, but rather a kludgy workaround for a broken
macro.  Since the macro is our own, we don't need that --- we can fix the
real problem.

> > Sure enough - both show.c and unset.c try to call strdup() directly
> > rather than going through gp_strdup().  That fails if the system does
> > not provide strdup().
> > 
> 
> Yes - presumably an oversight.

In the case of show and unset: yes.  And it's exactly the kind of
oversight the pre-release cycle with its candidate tarballs was supposed
to expose, so they could be fixed before the release.

But there's one more use of strdup, this time in gplt_x11.  Since
gnuplot_x11 isn't linked against util.c, where gp_strup() is defined,
gplt_x11.c can't use gp_strdup().  So that has to be fixed separately,
by removing the use of strdup() from gplt_x11.c altogether.

(The calls to strdup() in src/win/wgraph.c are OK --- all Windows
compilers must have strdup anyway).

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