From: Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
Message-Id: <199906141818.OAA09122@mccoy2.ECE.McGill.CA>
Subject: Re: {v,}snprintf.c ???
To: djgpp-workers AT delorie DOT com
Date: Mon, 14 Jun 1999 14:18:02 -0400 (EDT)
In-Reply-To: <37643242.C52AE48F@cartsys.com> from "Nate Eldredge" at Jun 13, 99 03:35:46 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Bonjour M. Nate Eldredge
> 
> 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.)

No suprise, GLibC has a fairly fast dev rate.

> 
> 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.

Fair enough, but the FILE struct member field, _cnt, is an int.
there seem to be some places where the stdio code do (fp->_cnt < 0)


-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!