Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: How does gcc (any compiler) actually convert a function call, say atoi(), into assembly/machine code? Date: Sat, 14 Jan 2017 13:52:16 -0800 Organization: None to speak of Lines: 59 Message-ID: References: <5878932a.1570296@news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="ba0db46df61d502ee0e6afe10bb5a782"; logging-data="13715"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19qI+y1MVa9jeJx6w96vGRm" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:jpBQgs3ZDHSfx5o3VwPIP9uqePw= sha1:Il003/YtTAhConMj65LBzh1QsMo= Xref: csiph.com comp.lang.c:101807 Tim Rentsch writes: > raltbos@xs4all.nl (Richard Bos) writes: >> Tim Rentsch wrote: >>> Keith Thompson 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". > > For example, the same way such cases are indicated in the various > strto*l() functions, ie, by returning either INT_MIN or INT_MAX > and setting errno. OK, good point. Given its description, atoi() is clearly not *intended* to work that way, but an implementation could do it as a (not terribly useful) extension. I probably should have thought of that approach, but I didn't. > By the way, I believe the only situations where this applies are > those that have a valid integer input string but whose value > cannot be represented in the function's output type. Any input > that is "not validly parsed", eg, "ZZZZZZ", is defined to have 0 > as the function's return value. That's a plausible interpretation, but I think the standard is vague on that point. It says "Except for the behavior on error". One could argue that an "error" is any condition in which it strtol() doesn't set errno. One could also reasonably argue, I think, that strtol("ZZZZZZ") is an "error", indicated to the caller by storing the value of nptr in the object pointed to by endptr (if it's non-null). I don't think the standard has a definition of the word "error". [...] > We are talking at cross-purposes. I'm not saying anything about > if or when atoi() might or should be used in a program. My > comments have nothing to do with writing portable code. What I > am saying is only about what the specifications of atoi() allow > an implementation to do when an error condition occurs. IMO it > is important not to confuse these two topics. They aren't the > same, and should not be treated as such. Agreed. -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"