[PATCH] [tldap] check for successful string conversion
swen at linux.ibm.com
Thu Jan 10 13:50:20 UTC 2019
On Thu, 2019-01-10 at 13:52 +0100, Volker Lendecke via samba-technical
> On Thu, Jan 10, 2019 at 01:04:13PM +0100, swen wrote:
> > I read it that "both" will be done in case of an error but
> > regardless
> > of how often I read the documentation I do not see the possibility
> > where errno is set but there is no error.
> The spec lists two conditions about errors:
> 1.: ret==0 and errno==EINVAL
> 2.: ret==ULLONG_MAX and errno==ERANGE
> Those are precise error conditions with deliberately worded "and"s.
> Any other assumption about errors is not covered by the spec. Your
> patch just checks errno, but this is not covered by what the spec
> says. "errno!=0" is not one of the conditions listed in the spec,
> thus I NACK your patch as it stands.
> You might reasonably argue that strtoull is a broken API, because the
> first case is optional, and thus EINVAL can not be relied upon. You
> are completely right there. But then you should come up with a better
> one, and I would propose to look at OpenBSD's strtonum or possibly
> sscanf with SCNu64, which might have better defined error handling.
according to the POSIX.1-2008 and all man pages I've read so far,
there is absolutely no way how errno could be non-zero without having
an error or errno being zero but still having an error.
The combined condition you're referring to is just not part of a
###### POSIX.1-2008 ######
These functions shall fail if:
The value of base is not supported.
The value to be returned is not representable.
These functions may fail if:
No conversion could be performed.
In addition the man page states
Since strtoul() can legitimately return 0 or ULONG_MAX (ULLONG_MAX for
strtoull()) on both success and failure, the calling program should set
errno to 0 before the call, and then determine if an error
occurred by checking whether errno has a nonzero value after the
So please reconsider you vote.
In addition to the issue discussed above, there's one case which is not
looked at yet. If the input-string represents a negative number, it is
silently accepted by the conversion functions.
This leads to a most likely unwanted result.
Since the conversion function is used quiet often in SAMBA I'd like to
go with an update in the lib/replace area as suggested.
Any comments ?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: This is a digitally signed message part
More information about the samba-technical