Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code?
Date: Fri, 13 Jan 2017 10:00:18 -0800
Organization: None to speak of
Lines: 45
Message-ID: <lnd1fqn8lp.fsf@kst-u.example.com>
References: <o3i6n3$sfv$2@dont-email.me> <d5dc2c9e-0b43-4520-b24a-fe142d502452@googlegroups.com> <lnk2aqbaow.fsf@kst-u.example.com> <kfn8tqzy2z9.fsf@x-alumni2.alumni.caltech.edu> <eea5e824-baab-4f76-b0b3-ad8c4740492c@googlegroups.com> <lnzijf1n27.fsf@kst-u.example.com> <kfnd1g5u5vb.fsf@x-alumni2.alumni.caltech.edu> <lnlgutwx5v.fsf@kst-u.example.com> <kfnshonqvv6.fsf@x-alumni2.alumni.caltech.edu> <5878932a.1570296@news.xs4all.nl> <87y3yfp839.fsf@bsb.me.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="5af804fde095f0102ceb1f5e23093854"; logging-data="28735"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/qqaoknCZH3OyJnq/oSyyR"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:eDhMFejckJUp0zeRuBKZ35zMaeU= sha1:99Ylw3uSdk/JixHC1FPooxbOgMs=
Xref: csiph.com comp.lang.c:101631

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> raltbos@xs4all.nl (Richard Bos) writes:
>> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>>> Keith Thompson <kst-u@mib.org> writes:
>>> > atoi() returns an int result.  There's no good way for it to distinguish
>>> > between a valid result and an error.
>>> 
>>> How atoi() is specified now gives it complete freedom for
>>> what to do on an error.  Surely one of those possibilities
>>> is a good way of distinguishing an error and a valid result.
>>
>> Well...
>>
>> - How, when all values it can return are already potentially valid
>>   return values? There is no room for an error value. It returns an
>>   int, and all ints could be validly parsed. There is no int left to
>>   indicate "not validly parsed".
>
> Distinguishing between an error and a valid result does not have to be
> done through the result itself.  It could be a simple as
>
>   extern const char *_atoi_endptr;
>
>   int atoi(const char *nptr)
>   {
>       long r = strtol(nptr, &_atoi_endptr, 10);
>       if (r < INT_MIN || r > INT_MAX)
>            _atoi_endptr = nptr;
>       return r;
>   }
>
> On error, returning an adjusted value might be more useful, but that's
> not really central to the point.
>
> <snip>

My intent was that solutions like that are included by the word "decent"
in the phrase "decent error handling".  This particular method is no
better than setting errno -- in fact, setting errno is thread-safe.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"