gnuplot-beta

Fun with VMS, TBOOLEAN, macro definitions and DECC

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

Disclaimer:
I had never built, nor run, gnuplot under VMS until today.
I was just curious, and this is what I found.

%%%%%%%%% 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.
at line number 188 in file $DISK1:[MERRITT.GNUPLOT.SRC]AXIS.C;1

    TBOOLEAN upwards;           /* extend upwards or downwards? */
.............^
%CC-W-PROMOTMATCHW, In the definition of the function "round_outward",
the promoted type of upwards is incompatible with the type of the corresponding
parameter in a prior declaration.
at line number 747 in file $DISK1:[MERRITT.GNUPLOT.SRC]AXIS.C;1

... and so forth in many other places.

%%%%%%%%%%% Bad macro syntax in x11.trm

And this one in x11.trm, which must not have been tested in ages:

#define GO(x) \
{ \
   char buffer[512]; int status; struct iosb iosb;\
   [lots of complicated stuff]
   if((status & SS$_NORMAL) != SS$_NORMAL) exit(status); \
 }

#define PRINT0(fmt)          GO( (buffer, fmt) )
#define PRINT1(fmt,p1)       GO( (buffer, fmt,p1) )


if (something)
	PRINT0(...);
else if (something)
	PRINT1(...);

This syntax doesn't work because of the trailing semicolons.
I propose to replace it with the standard work-around:
#define GO(x) \
do {...} while (0)

%%%%%%%%%%%%% failure to use local routines if necessary

%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM,         ADD_HISTORY 
%LINK-I-UDFSYM,         STRDUP 
%LINK-W-USEUNDEF, undefined symbol STRDUP referenced
        in psect $LINK$ offset %X00000C50
        in module SET file $DISK1:[MERRITT.GNUPLOT.SRC]SET.OBJ;1
%LINK-W-USEUNDEF, undefined symbol ADD_HISTORY referenced
        in psect $LINK$ offset %X00001490
        in module SHOW file $DISK1:[MERRITT.GNUPLOT.SRC]SHOW.OBJ;1
%LINK-W-USEUNDEF, undefined symbol STRDUP referenced
        in psect $LINK$ offset %X000006D0
        in module UNSET file $DISK1:[MERRITT.GNUPLOT.SRC]UNSET.OBJ;1

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

I don't know what the problem is with add_history() in show.c;
the same function call seems to have been resolved correctly at
other call sites.

%%%%%%%%%%%%%%  various type checking

The type of time_t seems to have been picked up incorrectly.
This results in many warning messages, but it may well be due
to my extremely minimal VMS configuration.

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

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

[<ha...@on...>]

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.  I want to make
make sure my build fixes are incorporated into the script rather 
than only as edits to my working config.h, so the configuration 
script is not quite ready for testing.

What VMS and CRTL version do you have and do you generate DESCRIP.MMS 
or BUILD.COM?

> 
> %%%%%%%%% 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.
> 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? 
My understanding is that C99 types it as unsigned int, which DECC
appears to expect.

> %%%%%%%%%%% Bad macro syntax in x11.trm
> 
> And this one in x11.trm, which must not have been tested in ages:
> 
> #define GO(x) \
> { \
>    char buffer[512]; int status; struct iosb iosb;\
>    [lots of complicated stuff]
>    if((status & SS$_NORMAL) != SS$_NORMAL) exit(status); \
>  }
> 
> #define PRINT0(fmt)          GO( (buffer, fmt) )
> #define PRINT1(fmt,p1)       GO( (buffer, fmt,p1) )
> 
> 
> if (something)
> 	PRINT0(...);
> else if (something)
> 	PRINT1(...);
> 
> This syntax doesn't work because of the trailing semicolons.
> I propose to replace it with the standard work-around:
> #define GO(x) \
> do {...} while (0)
> 

A simpler fix is 
  if (something) {
    PRINT0(...); 
  } else if (something) {
    PRINT1(...);
  }

> %%%%%%%%%%%%% failure to use local routines if necessary
> 
> %LINK-W-NUDFSYMS, 2 undefined symbols:
> %LINK-I-UDFSYM,         ADD_HISTORY 
> %LINK-I-UDFSYM,         STRDUP 
> %LINK-W-USEUNDEF, undefined symbol STRDUP referenced
>         in psect $LINK$ offset %X00000C50
>         in module SET file $DISK1:[MERRITT.GNUPLOT.SRC]SET.OBJ;1
> %LINK-W-USEUNDEF, undefined symbol ADD_HISTORY referenced
>         in psect $LINK$ offset %X00001490
>         in module SHOW file $DISK1:[MERRITT.GNUPLOT.SRC]SHOW.OBJ;1
> %LINK-W-USEUNDEF, undefined symbol STRDUP referenced
>         in psect $LINK$ offset %X000006D0
>         in module UNSET file $DISK1:[MERRITT.GNUPLOT.SRC]UNSET.OBJ;1
> 
> 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.

> I don't know what the problem is with add_history() in show.c;
> the same function call seems to have been resolved correctly at
> other call sites.
> 

I fixed that by making the add_history() call in show.c conditional on 
   #ifdef READLINE
as it is in command.c
   
> %%%%%%%%%%%%%%  various type checking
> 
> The type of time_t seems to have been picked up incorrectly.
> This results in many warning messages, but it may well be due
> to my extremely minimal VMS configuration.
> 

Try putting 
#define HAVE_TIME_T_IN_TIME_H 1
in config.h.

Haven't assembled my source code changes into a patch file yet :-(

-- Lucas Hart                 <ha...@on...>

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

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

On Monday 03 May 2004 10:22 pm, Lucas Hart wrote:
>
> What VMS and CRTL version do you have and do you generate DESCRIP.MMS
> or BUILD.COM?

OpenVMS 6.1-1h2
DEC C V5.0-003
I can't remember where to find a separate CRTL version.
I told it @CONFIGURE.VMS DECC COM 

> > This syntax doesn't work because of the trailing semicolons.
> > I propose to replace it with the standard work-around:
> > #define GO(x) \
> > do {...} while (0)
>
> A simpler fix is
>   if (something) {
>     PRINT0(...);
>   } else if (something) {
>     PRINT1(...);
>   }

The drawback there is that you have to know that PRINTn() is a macro
rather than a function in order to write correct C code.  The form I
gave is preferable because once the macro is defined correctly then
you don't have to worry about it elsewhere in the code.
Also, changing the macro affects only the VMS build,
whereas changing code elsewhere potentially affects all platforms.

I made this change in cvs.

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

Now fixed in cvs.

> I fixed that by making the add_history() call in show.c conditional on
>    #ifdef READLINE
> as it is in command.c

Right. I have fixed that one in cvs also.

> Try putting
> #define HAVE_TIME_T_IN_TIME_H 1
> in config.h.
>
> Haven't assembled my source code changes into a patch file yet :-(

I'm not going to touch the VMS configuration files per se;  my VMS machine
is old and hardly maintained, and I'm not about to spend any time on 
figuring out why it has configuration problems.  I am more interested in it
as just another quirky platform that reveals fixable coding errors.  A couple
of the TBOOLEAN error messages reveal actual code errors, for instance
(arithmetic tests against 0 or 1 rather than logical tests).  I am collecting
these for a general code cleanup pass later on.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

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.

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

[<ha...@on...>]

On Tue, May 04, 2004 at 01:18:17PM +0200, Hans-Bernhard Broeker wrote:
> On Mon, 3 May 2004, Lucas Hart wrote:
> > On Mon, May 03, 2004 at 05:48:58PM -0700, Ethan Merritt wrote:
> 
> > > %%%%%%%%% 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?
> 

(I no longer have access to a DEC Unix/Tru64 system - wouldn't be 
surprised to get the same warning messages with the DEC/Compaq C 
compiler there as well.)

The TBOOLEAN PROMOTMATCHW warnings are just warnings about a 
difference between the default promoted type for a parameter 
in the old-style function definition (int in this case) and 
its type in the new style function prototype (here TBOOLEAN)
which overrides the former. Innocuous, so I now disable the 
warning, e.g.   CC/WARN=DISABLE=(PROMOTMATCHW)

> 
> > My understanding is that C99 types _Bool 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.
> 

Depends on the version (equating Compaq C and DECC); v6.4, in 2001,
added support for C99 including an 8-bit _Bool data type and a 
/STANDARD=C99 flag.

However, I misinterpreted the reason for a lack of PROMOTMATCHW
when TBOOLEAN was declared as unsigned int;  unrelated to _Bool
but rather to the default promotion of the respective function 
parameters to int.

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

Agreed - the macro can be fixed; my point was intended to be that 
a simple kludge is sufficient for the one instance that the long-
established macro fails in the current source, without any functional
changes which might require more extensive testing.

-- Lucas Hart                         <ha...@on...>