Re: VMS: Exit and exported symbol fixes.

[John E. Malmberg]

On 10/7/2014 11:20 PM, Paul Smith wrote:
> John: thanks for these fixes!
>
> On Mon, 2014-10-06 at 23:50 -0500, John E. Malmberg wrote:
> > +#ifndef C_FACILITY_NO
> > +#define C_FACILITY_NO 0x350000
> > +#endif
> > +#ifndef VMS_POSIX_EXIT_MASK
> > +#define VMS_POSIX_EXIT_MASK (C_FACILITY_NO | 0xA000)
> > +#endif
>
> We try to indent preprocessor macros inside conditionals; this isn't
> 100% followed but it's preferred.
>
> > +              if ((c->cstatus & VMS_POSIX_EXIT_MASK) == VMS_POSIX_EXIT_MASK)
> > +                {
> > +                  status = (c->cstatus >> 3 & 255) << 8;
> > +                }
>
> The GNU coding standard used by GNU make says that braces should not be
> used for single-statement blocks (I know this is controversial in some
> quarters, but that's how all the rest of the GNU make code is written).
> There are many places like this.

$dayjob coding standard is always include braces, but I can follow your 
rules.

> > +      {
> > +          char * value;
> > +          value = getenv("GNV$MAKE_USE_MCR");
>
> The coding standards require "*" to be cuddled with the variable name.
> Also, I think value should be "const char *value;" here.
>
> And, the standard requires a space between the function name and open
> paren, so "value = getenv (...".  There are a number of instances of
> missing space.

I missed that one, I noticed that the extra space is there for the rest 
of Make.

> > +/* Build a Posix Exit with VMS severity */
> > +void vms_exit(int status) {
>
> Return types should come on the previous line, and function opening
> braces should be on the next line in the first column of the next line,
> plus whitespace between the name and open paren, like this:
>
>    void
>    vms_exit (int status)
>    {

I see the braces indented 2 spaces for most of the code.

> Same for structs.
>
> > +++ b/vms_export_symbol.c
>
> This file seems to use a very different coding style; is it shared with
> another program such that you don't want to use the GNU standard style?

It will probably eventually be in a VMS analog to GNULIB.  The coding 
style is one that $dayjob recommends.

> > +++ b/vms_progname.c

That one is shared with other open source projects as it emulates the 
GNU progname.c.

> Ditto here.
>
> Plus, we need to add all these new files to the Makefile.am in the
> EXTRA_DIST variable otherwise they'll be left out of the distribution
> tarballs etc.

I always forget about the Makefile.am since we can not currently run 
autoconf on VMS.

I can try to resubmit tomorrow evening.

Regards,
-John