[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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [avr-libc-dev] FW: [avr-gcc-list] stdio problem fixed,
Sander Pool <=