-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> We should probably defer this to Finnbarr, but, there are only 2 C
> language standards, ISO 89 and ISO 99. XPG3 is a Unix specification
> which has been subsumed by Unix 98.

...both of which describe, at least in part, a standard of how to
interface with the operating system, using the C programming language.
I suppose it's a semantic argument, but I like to argue.  ;-)
The POSIX standards also define how to interface with the operating
system (not necessarily Unix), using the C language, and is more or
less a superset of ISO C89, with a few exceptions.  They are
standards, created by a known standards body, that specify the syntax
and the behavior of C, and therefore I conclude they are C standards.

> This and other specs defer to the outstanding C standards. Since I
> generally work in porting code, I try to keep my code portable.
> vsnprintf is a reasonably good function, and safer than vsprintf.

Well, vsnprintf() is defined by ISO C99, so it's been part of the
official ISO C standard for 3 years now.  And I did manage to find the
C99 specification on line here:

  http://www.ucalgary.ca/~bgwong/n869.pdf

Note that it does not specify any aspect of how the C preprocessor
does or does not work, with two small exceptions.  The method I
suggested for creating macros using variable arguments is therefore
not specified by the standard, but only by virtue of there not being
any such specification whatever.  But Frank did ask how to write
macros using variable arguments, and I answered the question... if
only for a particular set of tools (which, as it happens, are fairly
ubiquitous, and freely and generally very readily available to
everyone with an interest in reading this mailing list).  I'm very
curious if this feature exists in any of the proprietary vendors'
tools.

> However, the issue in the code is to add something like a date and a
> standard message header for a log file. The first sprintf,
> effectively concatenates the date and the format specification, and
> vfprintf uses that result as the new format spec.

Certainly.  However, when I think log files, I invariably think of
syslog.  It's one curse of being a system administrator... =8^)  I 
also often try to write generalized functions, when it seems like it
might be desireable.  Imagine a logging module, which can log either
to syslog, or to a specified log file.  While your function works
well with a stand-alone log file, it does not work so well for this
more generalized case.  You must now pass your variable arguments to
the call to syslog().  Not so easy, without vsnprintf()...

This evidently did not apply to Frank's problem, but I did not have
a clear sense of that based on his original post.

Also, I would point out that there are numerous cases where using
Standard C mechanisms are actually harmful.  One very notable example
is the ANSI C mechanism for handling signals, using the signal()
function.  On older implementations, as well as some newer
SVr4-based implementations, the signal() function is unreliable,
allowing signals to be missed, or to have the default action result
when a signal handler is being installed.  It suffers from several
other limitations as well, which I won't go into here.  See Stevens,
_APITUE_, chapter 10 (esp. 10.3 and 10.4) for details.  These
limitations make the signal() function insufficient for all but the
simplest of cases, and allowing for some extremely hard to track down
bugs in complex programs.

POSIX defines several functions for the reliable handling of signals,
which are implemented by all modern Unix systems AFAIK, and obviously
by all POSIX-compliant operating systems.  SVr4-based systems, at
least for some time, provided these functions but still provided the
old, unreliable semantics for the signal() function.  This may no
longer be the case -- I don't know.  Even if it isn't, the signal()
function still suffers from several limitations, and C99 still only
specifies that for signal handling.  BSD has the signal() function, but
it is based upon the POSIX signal functions, and does not exhibit the
unreliable semantics of the System V signal() function.  It does,
however, still suffer from several of the other limitations Stevens
mentions.

There are other examples where Standard C does an inadequate job of
defining the behavior of an element of C, where POSIX steps in and
rectifies the problem.  I don't care to delve into them all.  If
you're curious, read Stevens, or try some of the POSIX programming
books.

In summary, I offer all this in support of the notion that, while
having standards is a good thing, blindly following them is not.
There will always be cases where the standards do the wrong thing, and
there will always be cases where you will save yourself significant
work and headaches by ignoring them.  The trick is to know the
environment(s) you're making use of well enough to know when to do
that.  =8^)

- -- 
Derek Martin               ddm@pizzashack.org    
- ---------------------------------------------
I prefer mail encrypted with PGP/GPG!
GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
Learn more about it at http://www.gnupg.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9DYBedjdlQoHP510RAkJDAJ99yt3yNqEUU6CVhc2NxMBRRCP30QCgll7E
xCSRmOj2CWl3RKPHf4OREhI=
=p9xi
-----END PGP SIGNATURE-----