Date: Sun, 20 May 2001 18:30:59 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
cc: djgpp-workers AT delorie DOT com
Subject: Re: snprintf?
In-Reply-To: <3B07A1CE.9A453342@phekda.freeserve.co.uk>
Message-ID: <Pine.SUN.3.91.1010520182619.23429H-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Sun, 20 May 2001, Richard Dawe wrote:

> >   - test the case of n = 1 in the test program;
> 
> This is already handled in the patch snprintf-20001119.diff, which I
> included in a mail called "snprintf() diff, take 4?", sent on 2000-11-19:

Sorry I missed that.

> >   - test the case of errors in format conversions (anything that
> >     causes _doprnt return -1).
> 
> I've looked at the _doprnt() code and I am unsure how to force a format
> conversion error. Any suggestions?

Just force _doprint to return -1, it doesn't matter how.  Cheat by 
replacing _doprint with some fake function, if you have too.  
The objective is to see how does snprintf cope with that situation.

> I just added a couple of tests for padding & precision specifiers and
> that's turned up a couple of problems that I haven't investigated yet. 

You can find a large sample of formats and expected results in 
djtst203.zip, in the Cygnus test suite.