This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

vfnprintf and negative integers


I'm suffering from a previously recognised bug, namely negative integers
coming out as big positive values.

There's been some email discussion on this already, and it was suggested
that this is a compiler bug (see below).

So far I've tried,
   * a gcc 2.95.2 + binutils 2.10.1 combination, 
   * another version that comes with the "Embedded Software Development with
ECOS" book, 
   * and the latest prebuilt ECOS V2.0 version (gcc 3.2.1, etc.). 

All to no avail. All 3 combinations still manifest the bug (with and without
optomisation). 

I don't mind rebuilding the toolset but I'd like to know that it's going to
fix the problem.

So does anyone know of a gcc/binutils combination that actually work?

Or am I doing something wrong?

Or are people just applying the suggested frig to the SARG macro indicated
in the email archive.

Target processor: PowerPC MPC5XX
Host: Linux

Many thanks in advance.

Ian Gilmour

(and apologies for the disclaimer at the end of this email - I have no
control over it!).

-------------------------------------------------------------------------

Re: bug in sprintf
From: Andrew Lunn <andrew dot lunn at ascom dot ch> 
To: Daniel Lidsten <Daniel dot Lidsten at combitechsystems dot com> 
Cc: ecos-discuss at sources dot redhat dot com, Knud Wöhler <woehler at ossi
dot fho-emden dot de> 
Date: Mon, 2 Jun 2003 11:40:56 +0200 
Subject: Re: [ECOS] bug in sprintf 
References:
<004B1D7A5257174C9044A1B7BD0E60EDA65D4E@ratatosk.combitechsystems.com> 



On Mon, Jun 02, 2003 at 11:00:26AM +0200, Daniel Lidsten wrote:
> Hi,
> 
> I can see the same problem with printf and fprintf i.e. i cant print
negative interger values. 

printf, fprintf, *print* all end up calling the same function,
vfnprintf. If that has a problem, everything else will have a problem.

> Is the below change a recomended fix (remove the line?)

It looks like a compiler bug, so the proper fix is to fix the
compiler, probably the optimizer. If it gets it wrong here, where else
is it getting it wrong?

[...] 
> > I think because size_t is unsigned it should not be handled in SARG().

I disagree. http://www.opengroup.org/onlinepubs/007904975/ 
The section about sprintf says:

z   Specifies that a following d , i , o , u , x , or X conversion
    specifier applies to a size_t or the corresponding signed integer
    type argument; or that a following n conversion specifier applies
    to a pointer to a signed integer type corresponding to a size_t
    argument.

Thus %zd is valid and SARG() has to deal with it.

     Andrew

----------------------------------------------------------------------------
CONFIDENTIALITY AND DISCLAIMER NOTICE

This message and any attachment is confidential and is protected by
copyright. If you are not the intended recipient, please email the sender or
telephone +44 (0)1442 213440 and delete this message and any attachment from
your system. Dissemination and or copying of this email is prohibited if you
are not the intended recipient.

We believe, but do not warrant, that this email and any attachments are
virus free. You should take full responsibility for virus checking.

No responsibility is accepted by FUJIFILM Electronic Imaging Limited for
personal emails or emails unconnected with FUJIFILM Electronic Imaging
Limited's business.
----------------------------------------------------------------------------

--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]