[Zlib-devel] Checking for availability of snprintf

[Cosmin Truta]

Greg Roelofs wrote:

> Of course, Messrs. Truta and Beebe are no doubt both fully aware that
> configure doesn't run in a DOS box, so such code would still be still
> required in zconf.h or wherever...

Right, configure is a Unix thing, so we cannot rely exclusively on it.
configure does run on some "surrogate Unices" such as DJGPP and Cygwin,
and more recently, MinGW, but that's not enough.


Nelson H. F. Beebe wrote:

>  - Macro: AC_FUNC_VPRINTF
>      If `vprintf' is found, define `HAVE_VPRINTF'.  Otherwise, if
>      `_doprnt' is found, define `HAVE_DOPRNT'.  (If `vprintf' is
>      available, you may assume that `vfprintf' and `vsprintf' are also
>      available.)
>
> For snprintf(), just use
>
>         AC_CHECK_FUNCS(snprintf)
>
> This will define (or not) the macro HAVE_SNPRINTF.

If vprintf exists, I can assume that vfprintf and vsprintf exist, but I
cannot safely assume that vsnprintf exists. It appeared only after
ANSI C.

And why in the world should I care for _doprnt now, almost 14 years
after ANSI C? I am particularly annoyed when Unixers laugh at MSDOS
dumbness, and then they check for <stdlib.h>, memcmp (or bcmp?), vprintf
(or _doprnt?), and whatnot. And, no, I am not advocating MSDOS.

Here are the rules I follow:

- If __STDC__ is defined, I can trust that any ANSI feature (<stdlib.h>,
memcmp(), EXIT_SUCCESS, ...) exists, and I shouldn't need to check for
them at build/installation time, or at any time.

- If STDC99 (i.e. __STDC_VERSION >= 199901L), then I can trust that any
ISO-C99 feature exists (from <stdbool.h> to snprintf), and again,
I shouldn't need configure to tell me that, even if I am on Unix.

- __STDC__ may not be defined, or at least not defined by default, and
still all ANSI C may be properly supported. This is true from the good
old Turbo C to the latest Visual C.

- POSIX features may not exist on non-Unix environments, so they
need to be checked for, and/or they need to be emulated. For example,
under Win32, there is a working fcntl(), a broken stat(), a
non-conformant mkdir(). fork() must be emulated by a heavy-duty layer
such as Cygwin. Etcetera...
I still don't find it normal not to have a well-established POSIX
feature under a certain Unix flavor, but I can live with this easier,
compared to not having all ANSI features.


It is my impression that if software were more demanding, the situation
were much better with the installed compilers and libraries, and
I wouldn't need to clutter my code, or read or fix cluttered code that
accomodates the lack of proper ANSI C support -- and even less to
look for a bash port for the OS I am working in, so that I can run
configure.

I am glad, at least, that zlib doesn't suffer from this
"over-portability" disease.


Sorry for getting off-topic, but this discussion made me remember bad
times when I had to choose between running an early beta of Cygwin or
writing a config.h by hand, only to have <stdlib.h> and friends
included properly.


Best regards,
Cosmin