From: Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
Message-Id: <199906141834.OAA09150@mccoy2.ECE.McGill.CA>
Subject: Re: {v,}snprintf.c ???
To: djgpp-workers AT delorie DOT com
Date: Mon, 14 Jun 1999 14:34:57 -0400 (EDT)
In-Reply-To: <Pine.SUN.3.91.990613111214.17906J-100000@is> from "Eli Zaretskii" at Jun 13, 99 11:12:34 am
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. Eli Zaretskii
> 
> 
> On Thu, 10 Jun 1999, Alain Magloire wrote:
> 
> > Ok, I don't know if this is the right approach, I simply redefine
> > the PUTC(ch) macro in  doprnt.c :
> 
> I'd prefer to change __putc (on <libc/file.h>) so that it simply
> returns without doing anything when fp->_cnt is non-positive.  After
> all, __putc has no business calling _flsbuf for fake streams with
> _IOSTRG flag set, so we might as well say it explicitly, instead of
> relying on INT_MAX to never be exhausted, which just might become
> untrue one day.

I think _IOSTRG is also use for scanf() too, I'll check if _flsbuf()
is use intheis case, .. should not .

> 
> DJ, do you have preferences as to where to make this change?
> 
> > #define PUTC(ch) \
> > do { \
> > 	if (fp->_flags & _IOSTRG && fp->_flags & _IOWRT && !fp->_cnt) \
> > 		return counter; \
> 
> This seems to be inconsistent with the function definition: the
> counter needs to be bumped up even if the string buffer is already
> exhausted.  Otherwise, we won't be able to return the space that
> should have been allocated in order to produce the complete output.

In the context, that you've explain (C9X) where the size maybe 0, yes.


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