From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21466 invoked by alias); 26 May 2003 05:18:29 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 13271 invoked from network); 26 May 2003 05:14:59 -0000 Received: from unknown (HELO brouhaha.com) (209.66.107.17) by sources.redhat.com with SMTP; 26 May 2003 05:14:59 -0000 Received: (qmail 29807 invoked by uid 1032); 26 May 2003 05:14:58 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 May 2003 05:14:58 -0000 Date: Mon, 26 May 2003 05:18:00 -0000 From: Scott Dattalo X-X-Sender: sdattalo@ruckus.brouhaha.com cc: sid@sources.redhat.com Subject: Re: Using vsnprintf or vasprintf in sid In-Reply-To: <87y90utizh.fsf@sashimi.wasabisystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-q2/txt/msg00034.txt.bz2 On 26 May 2003, Ben Elliston wrote: > Hi Dave! > > Dave Brolley writes: > > > I have a need for printf-like printing into a buffer, however I have > > no control over the input and so I don't know the size of the buffer > > which will be required. It looks like vsnprintf (_ISOC99_SOURCE) or > > vasprintf (_GNU_SOURCE) are what I need. Is it ok to use these > > function in sid and, if so, how do I get configure to add the > > necessary -Dxxxx to the sid compilations and (if necessary) specify > > the library to look in? > > I'm not aware of any policy (the problem with SID is that it lacks the > strict policies and exciting politics of other free software > projects!) that would prevent you from using either of these functions > in SID, provided that you use Autoconf tests as you suggest. I think > it's important to have a fall-back implementation, though, in the case > that neither is available. > > Take a look at using AC_CHECK_FUNC to do the test and set a #define in > config.h to indicate the function(s) presence. If you can, try and > isolate the test to the configure script used in the part of the > source tree you're working in rather than running the test in the > top-level configure script. IIRC, when I used vnsprintf in SDCC the Solaris users were affected. Here's the code in question: #ifdef USE_VSNPRINTF // Alas, vsnprintf is not ANSI standard, and does not exist // on Solaris (and probably other non-Gnu flavored Unixes). /*-----------------------------------------------------------------*/ /* SAFE_snprintf - like snprintf except the string pointer is */ /* after the string has been printed to. This is */ /* useful for printing to string as though if it */ /* were a stream. */ /*-----------------------------------------------------------------*/ void SAFE_snprintf(char **str, size_t *size, const char *format, ...) { va_list val; int len; if(!str || !*str) return; va_start(val, format); vsnprintf(*str, *size, format, val); va_end (val); len = strlen(*str); if(len > *size) { fprintf(stderr,"WARNING, it looks like %s has overflowed\n",__FUNCTION__); fprintf(stderr,"len = %d is > str size %d\n",len,*size); } *str += len; *size -= len; } #else // USE_VSNPRINTF // This version is *not* safe, despite the name. void SAFE_snprintf(char **str, size_t *size, const char *format, ...) { va_list val; int len; static char buffer[1024]; /* grossly conservative, but still not inherently safe */ if(!str || !*str) return; va_start(val, format); vsprintf(buffer, format, val); va_end (val); len = strlen(buffer); if(len > *size) { fprintf(stderr,"WARNING, it looks like %s has overflowed\n",__FUNCTION__); fprintf(stderr,"len = %d is > str size %d\n",len,*size); } strcpy(*str, buffer); *str += len; *size -= len; } #endif // USE_VSNPRINTF So the fix is a hack that really isn't fool-proof. Scott