avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] FW: [avr-gcc-list] stdio problem fixed


From: Sander Pool
Subject: [avr-libc-dev] FW: [avr-gcc-list] stdio problem fixed
Date: Tue, 18 Mar 2003 20:14:13 -0800


Exiting on error is fine. I would recommend making all the stdio functions
behave the same way (exit on error). I just re-read the manual and it does
state that __put should have this behavior. Adding a comment to the source
code may help hasty readers :-)

Thanks,

        Sander



-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf Of Joerg Wunsch
Sent: Tuesday, March 18, 2003 1:39 AM
To: address@hidden
Subject: Re: [avr-gcc-list] stdio problem fixed


"Sander Pool" <address@hidden> wrote:

> So in any case, when you return a non-null value printf still works
> but puts does not, it only prints the first character.

Hmm.

> Still, is this expected behavior?

[Perhaps the following should rather be discussed at the avr-libc-dev
mailing list.]

Probably not.  I'm not sure, what should i do about an error return of
the put() function?  Currently, vfprintf() still continues, but
doesn't increase the »characters sent« counter (that will form the
return value).  [f]puts() obviously aborts upon seeing an error.

I'm willing to make both functions behave the same.  I don't see a
clear way mandated by the standard whether any output attempt needs to
be aborted after an error or not.  So i could either make [f]puts()
continue on error (but have to remember the error flag since it needs
to be returned), or make vfprintf() stop on error.

I tend towards the latter, it sounds more logical to me to stop on
error.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]