Re: [patch] Fix for heap overflow in wscanf (BZ 16618)

["Carlos O'Donell" <carlos at redhat dot com>]

On 02/03/2015 01:41 PM, Rich Felker wrote:
>> I would consider all of these things bugs and particularly in the use
>> case of the user-provide free() a conformance issue for modifying errno
>> without there being an error.
> 
> ISO C and POSIX explicitly permit any function to modify errno on
> success as long as they don't set it to zero. free always succeeds, so
> it's always valid for free to clobber errno. This is not a conformance
> issue. If you assume free does not modify errno, that's a non-portable
> assumption from the application side and a flawed assumption from the
> glibc side assuming you allow replacement of malloc/free.

I had not interpreted the wording as you paraphrase it, but I can see
how it could be interpreted like that.

My expectation had simply been that functions that don't define any
conditions under which errno is defined, would by this fact not have
any need to modify errno.

Thus without a need to modify errno I conflated that to mean "should
not modify errno," but the truth is they can actually do the opposite
and have free reign to change the value at will (except 0).

So we have:
* free() doesn't say it sets errno, therefore errno is undefined until
  it is changed by the next function call or application code
* errno after success is unspecified because the description of free()
  does not say anything about errno on success
* errno can't be examined because free() never describes when it might
  be valid to do so
* errno is not set to 0 after a successful call to free()

So free() is, under the standard, free to write any value to errno 
except 0, and it is the application that may not examine errno.

Thanks, I'd read the POSIX wording differently.

Cheers,
Carlos.