From jwe at bevo.che.wisc.edu  Sun May 15 19:14:34 2005
From: jwe at bevo.che.wisc.edu (John W. Eaton)
Date: Sun May 15 19:17:22 2005
Subject: [Rd] add Rvsnprintf to API ??
In-Reply-To: <Pine.LNX.4.61.0505140720080.25685@gannet.stats>
References: <200505131003.j4DA3BSZ020947@hypatia.math.ethz.ch>
	<20050513194455.GA23627@stat.umn.edu>
	<Pine.LNX.4.61.0505140720080.25685@gannet.stats>
Message-ID: <17031.33658.966713.692081@devzero.bogus.domain>

On 14-May-2005, Prof Brian Ripley wrote:

| R guarantees to have *vsnprintf* available.  Putting things in the API is 
| a one-way decision and ties our hands for ever.  Rvsnprintf is not even 
| exported from errors.c: it is static and just a convenience wrapper.
| 
| About all a user package needs to do is
| 
| AC_CHECK_DECLS([vsnprintf])
| 
| and in your code snippet
| 
| #if defined(HAVE_DECL_VSNPRINTF) && !HAVE_DECL_VSNPRINTF
| extern int vsnprintf (char *str, size_t count, const char *fmt, va_list arg);
| #endif
| 
| However, AFAIK all known R platforms do have vsnprintf these days: the 
| MinGW compiler used on Windows gained it within the last year.

Is checking for vsnprintf availability sufficient, or should one also
check for versions that behave differently?  As I recall, different
versions of vsnprintf return different values when a buffer overflow
occurs.  Standard versions return the number of characters that would
have been in the string (not including the terminating nul) if the
buffer had been big enough, but older versions (apparently including
glibc prior to 2.1) simply return -1 if the buffer is too small.  Is
it worth trying to handle these differences?  Or at least detect the
broken vsnprintf and fail to build?

jwe


[Rd] add Rvsnprintf to API ??
John W. Eaton