Sender: nate AT cartsys DOT com
Message-ID: <37643242.C52AE48F@cartsys.com>
Date: Sun, 13 Jun 1999 15:35:46 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.10 i586)
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
CC: Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
Subject: Re: {v,}snprintf.c ???
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990613111143 DOT 17906I-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> 
> On Wed, 9 Jun 1999, Alain Magloire wrote:
> 
> > int
> > snprintf(char *str, size_t n, const char *fmt, ...)
> > {
> >   FILE _strbuf;
> >   int len;
> >
> >   if ((int)n < 1)
> >     return EOF;
> 
> The C9X draft is rather vague on this point, but it surely doesn't say
> that N should be strictly positive.  In fact, I can understand its
> language as meaning that calling {v,}snprintf with a zero N is a way
> to know how many characters should I allocate for the string that I
> pass to it when I *really* need some output.
> 
> What do other implementations do when N is zero?

glibc does as you expected: it returns the number of characters without
touching the buffer.  (You can even pass NULL.)

I think the cast to signed int is bogus too.  Passing -1 as n appears to
make it write unlimited (or rather 0xffffffff) characters.  IMHO,
there's no reason to think about the sign of a size_t.  Granted, we
don't support 2GB arrays now, but I think the principle of "caveat user"
applies.
-- 

Nate Eldredge
nate AT cartsys DOT com