[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VMS: Exit and exported symbol fixes.

From: John E. Malmberg
Subject: Re: VMS: Exit and exported symbol fixes.
Date: Tue, 07 Oct 2014 23:55:46 -0500
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2

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

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:

   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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]