Date: Thu, 4 Apr 2013 21:52:55 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: scanf requirements not met? Hi all, In consideration of adding the 'm' modifier for scanf and looking at how it's supposed to handle malloc failure, I believe the current implementation may be getting some things wrong. Seeing that it defined malloc failure as a "conversion error": If there is insufficient memory to allocate a buffer, the function shall set errno to [ENOMEM] and a conversion error shall result. I noticed that this was not either of the "failures" defined for scanf: input or matching. The text "conversion error" does not occur elsewhere, but the ERRORS section does specify: If any error occurs, EOF shall be returned, and errno shall be set to indicate the error. The current behavior in musl is to treat EILSEQ and IO errors from the underlying stdio layer as input failures, but in light of the above, this seems wrong/non-conforming. It looks to me like, even if a number of conversions have already taken place successfully, scanf is required to return EOF anyway if an error is encountered later. This also makes the following text make more sense: If the function returns EOF, any memory successfully allocated for parameters using assignment-allocation character 'm' by this call shall be freed before the function returns. I previously thought the only way the function could return EOF was when no successful conversions had taken place, in which case there would be nothing to free. But if EOF can happen even after successful conversions, then it makes sense. (And it's also a pain to implement.) Does this all sound right? I'll probably wait until after the release to go working on it, and add 'm' at the same time, since scanf is ugly and fragile and not something I want to break pending a release. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.