[thomashabets2]

Fair enough.

For strtoul and friends, maybe? 7.24.1 is pretty dense, but the key parts are "the expected form of the subject sequence is a sequence of letters and digits representing an integer with the radix specified by base, optionally preceded by a plus or minus sign […] If the correct value is outside the range of representable values […] ULONG_MAX […] is returned".

So the "expected form" allows a minus sign, but then it's clearly "outside the range of representable values" for strtoul to try parsing a negative value. So maybe it should return ULONG_MAX on those.

So arguably a minus sign present could already be treated as an error, and still be standard compliant. Unless I'm misreading.

[rbanffy]

Passing a negative value to a function that is specifically for converting strings into unsigned numbers is pretty much an error. In the case of functions that return an unsigned number, at least, negative return values can represent errors.

It’s more fun when the result can be signed though. Maybe strcmp with the representation of the LONG_MAX, and if it doesn’t match, call strtol and watch for a LONG_MAX indicating an error.

C is a bit messy. Would be nicer to return a struct with a possible error and the desired value, Golang style.

[thomashabets2]

If that's an error then so is passing in a non number.

So catch 22. You can only check for valid numbers if the number is valid?

[rbanffy]

If you pass a negative number as a string to a function that converts strings representing positive numbers into positive long integers, then yes, it should return an error status instead of the wrong result.

[thomashabets2]

Ah, I misunderstood what you meant by "is an error". Agree.

[imtringued]

That's the C way, yes.

[thomashabets2]

No. This is more like if strcmp compared null terminates strings, but can only compare strings that are in fact equal.