From: Micah Cowan > > (I didn't "improve" the vsnprintf() prototype, because it needs > > "va_list", which not universally available. A realistic snprintf() > > seems to be harmless around here, however.) > > "Not universally available"? It's part of the C standard, since 1989. > And it surely must exist on your platform, since if that #if clause is > firing, then so is the one in snprintf.c, whose snprintf implementation > uses vsnprintf (and therefore va_list), and apparently doesn't fail to > compile.
Poor phrasing on my part. "src/sysdep.h" didn't already pull in a declaration of "va_list", so merely dropping in the realistic prototype for vsnprintf() caused more problems than it solved, and I didn't want to start tossing in #include directives to pull in <stdarg.h> or <varargs.h> or <I_don't_know_what_else.h>, which might not be portable. (But _you_ can.) > I'll fix both (the va_list will require <stdarg.h> as well). Using a > non-prototype function declaration to refer to a function that uses > variable parameters is expressly forbidden by the C standard (though I > suppose that would only apply to snprintf). Sounds good to me. > > 4. That VAX C compiler is also dismayed by the "(const char *)" > > type-cast in the dummy gettext() macro in "lib/gettext.h" and > > "src/gettext.h". For example: > > [...] > > Actually, it looks like this is the type cast doing its job: according > to comments in gettext.h, the cast is to prevent callers from trying to > use gettext's return value inappropriately. host_errstr() should have > been returning a const char*, which would make this message go away. > I've fixed host_errstr()'s return type. I was afraid to try that, but it sounds plausible. Generally, if the (older, lamer) VAX compiler complains while the (newer, spiffier) Alpha and IA64 compilers don't, I just figure that it's a compiler problem, and start looking for a work-around. > Is vms/getopt.h just copied from lib/getopt.in.h? I assumed it was, and > made this change. The new builders have been copying "lib/getopt.in.h" to "getopt.h" (in a product directory, not "vms/"), and getting it from there. I could keep doing that. Or, if it's easy and not odious, and you'd like to supply it as "vms/getopt.h", then I could rip out a few lines. Not having to deal with what happens to a multi-dot file name on an ODS2 disk would be ok with me, and I believe that that's the only one. > > So far, the builders seem to be working with MMS on VAX (V7.3) and > > Alpha (V7.3-2), with ODS2 and ODS5 disks. I need to try things on IA64, > > and with MMK instead of MMS, and with no SSL, HP SSL, and OpenSSL, and > > then on some older OS/compiler versions, but there seems to be some > > hope. (For 1.12.1 or something, anyway.) > > Cool. :) I'll say. I'm just starting to try to make the psychological adjustment to not having to host a separate VMS-suitable distribution kit myself. I hope that I can cope. There should still be a market for pre-fab VMS executable kits, so I don't have to go cold-turkey, but it'll be a jolt. SMS.
