Re: OpenVMS todo list:

[Bruno Haible]

Hello John,

> * Config.h
>    OpenVMS needs __UNIX_PUTC macro defined for putc_unlocked
>    and friends to be visible.

The right place to do this (for a macro that affects multiple
gnulib modules) is the 'extensions' module.

> * lib/passfd.c
> 
>    This needs "_X_OPEN_SOURCE_EXTENDED" for the XPG4 V2 features
>    in the code to compile on OpenVMS.  Specifically the "msg_control"
>    and "msg_controllen" members of struct msghdr.
> 
>    This would need to be defined before any system header files are
>    included.

This too is best done in the 'extensions' module.

>    For the OpenVMS header files, enabling _X_OPEN_SOURCE_EXTENDED
>    causes macros and symbols not defined by the applicable
>    standard to be hidden from the compiler.  There currently
>    is no way to make them visible and have XPG4 V2 features enabled.

?? I don't understand the last sentence. What features get disabled
when you define _X_OPEN_SOURCE_EXTENDED?

>    Or I need to have my build procedure create a file named
>    lib/gnv$passfd.c_first that contains that macro definition.
> 
>    The cc emulation program in OpenVMS GNV will automatically treat
>    such files as a "first_include".

This is a non-standard way of operation that would cause maintenance
problems; I would therefore prefer if we can avoid it.

> * The OpenVMS iconv.h header file has a bug where it does not
>    include sys/types.h.

Gnulib has an idiom to cope for this situation. Do
  $ grep -rl 'not self-contained' doc/posix-headers/

> * The OpenVMS math.h header file has a bug where it is missing
>    NAN and INFINITY, these are found in the fp.h header file.

To be handled in the 'math' module.

> * In gl_sublist.c, the OpenVMS compiler is generating a
>    "MISSINGRETURN" warning because it does not realize that there
>    is no return from an abort() call.
>    This should fix that:
> 
>    #ifdef __DECC
>    # pragma message disable missingreturn
>    #endif
> 
>    So would adding a useless return statement, but that may cause some
>    compilers to complain about unreachable code.
> 
>    I do see GCC specific pragmas in the source code.

Adding a return statement after abort() is not something I could accept,
because - as you say - other compilers may warn then.

A __DECC specific pragma is acceptable, but I don't like it nevertheless:
Most people use GCC or clang when they want to check the code quality;
that's the reason for the GCC specific pragmas. If you have a warning
that occurs once or 5 times, it's something you can easily ignore.
Things would be different for a line of code that produces, say, 500
lines of warnings; these warnings are too much clutter and we should
use a compiler specific pragma to get rid of it.

> * OpenVMS sys/resource does not define RUSAGE_SELF or
>    RUSAGE_CHILDREN.  Comments say ru_stime member of rusage
>    is present, but not implemented.

Yes, for 'struct rusage' the common approach is to define the fields
and set them to 0, on platforms where no reasonable value can be computed.

> * Because the replacement C99 routines are not prefixed
>    with "RPL_" or another prefix, the OpenVMS C Compiler is
>    generating a warning when encountering them:
> 
> %CC-W-NOTINCRTL, Identifier "strtoumax" is reserved by the C99 standard 
> and will  be mapped to "DECC$STRTOUMAX" although it is not available in 
> the CRTL available to the compiler.
> 
>    These appear to be routines that the compiler would inline when the
>    optimization level allows it.
> 
>    It looks like something in the configure tests determine if the
>    prefix is generated for a replacement routine or not.  OpenVMS
>    generally always will need the prefix on a replacement routine.

In this case, you need to arrange for REPLACE_STRTOUMAX to be 1.
But please limit these changes to OpenVMS, because it makes debugging
with gdb simpler when the 'rpl_' prefix is omitted when possible.

> * The configure test for the real directory for OpenVMS system
>    supplied header file fails because they are not in a real directory.
>    They are in a library file.  If OpenVMS does not find a header
>    file in supplied paths header files or in the source, it junks
>    the directory portion the the header file path, and just looks
>    up the filename in the text library.
> 
>    I export some symbols to cause Configure on VMS to skip the test.
> 
>    export gl_cv_next_errno_h="<vms_fake_path/errno.h>"

You need to find a way to make the
  #include "/usr/include/foo.h"
or
  #include_next "foo.h"
idiom to work, one way or the other. Gnulib relies heavily on it.

Bruno