Re: Implementation errors in strtol()

On 2005-01-22 20:17, Andrey Chernov <ache_at_nagual.pp.ru> wrote:
> On Sat, Jan 22, 2005 at 12:30:15PM +0100, Joerg Wunsch wrote:
> > Nope.  Just think about it: code which doesn't take this feature into
> > account needs to check for conversion errors by means of verifying
> > endptr.  It simply wouldn't care about errno at all, except for
> > possibly checking for overflows -- which only needs to be verified
> > after it is already clear from checking endptr that the conversion was
> > OK.  Thus, errno could not possibly be EINVAL anymore in that case.
>
> I know portable way of doing that. You describe one case from two. The
> another case you miss is more indirect: portable application which set
> "errno = 0" before calling strtol() to detect overflows (it is only
> method) even after checking that endptr moved can't check just
>
> if (errno) { ... }
>
> but must check
>
> if (errno == ERANGE) { ... }
>
> instead.

Hi Andrey,

Why would checking for explicit errno values be necessary?  IIRC, after
a few emails I had exchanged with Dima Dorfman a few months ago,
checking for endptr *and* errno != 0 was ok.

Something like this was what we had come up with:

	char *optarg, *endp;
	long val;

	errno = 0;
	val = strtol(optarg, &endp, 0);
	if (*ep != '\0' && *optarg != '\0')
		err(1, "Partially converted string: %s", optarg);
	if (errno != 0)
		err(1, "Other error");

> That is, what I mean, saying that portable application should consider
> _both_ cases.

Just to clarify this a bit, when you say "both cases" you mean "both
ERANGE and EINVAL", or "both endp/nptr _and_ errno being zero (because
it was explicitly set to zero before calling strtol())"?

- Giorgos