Re: what's wrong with atof() and casting?



On Wed, 29 Jun 2005 15:11:18 +0900, "Roman Mashak" <mrv@xxxxxxxx>
wrote in comp.lang.c:

> Hello, Jack!
> You wrote on Wed, 29 Jun 2005 00:51:45 -0500:
>
> ??>> Could anyone help me understand what's wrong with the code?
> ??>>
> ??>> Thank you for your time,
> ??>> Steve
>
> JK> Your program invokes undefined behavior. You do not have a prototype
> JK> in scope for atof(). You need to include <stdlib.h>.
> Why is compilation and linking of code successful even without including
> stdlib.h? At least linking error should arise, no ?

Prior to the 1999 update to the C language standard, it was allowed to
call a function without any sort of declaration or prototype in scope.

This would be defined behavior and work properly if and only if
certain conditions were met:

1. The return type of the function was int (true for atoi(), but NOT
true for atof()).

2. The function took a fixed number and type of arguments (that is,
not like printf() that takes variable arguments.

3. The arguments were all the types produced by default promotion
(that is, not char or short or float).

4. In your call of the function, the arguments you passed were the
correct number and type (after default promotion).

So when you call atoi(argv[1]), the compiler generates a call to a
function returning an int and accepting one char * parameter. This is
the correct type for atoi(), so the call works.

Then you call atof(argv[1]), the compiler generates a call to a
function returning an int and accepting one char * parameter. Since
atof() DOES NOT return an int, this is wrong and undefined behavior.

Note that a compiler is not required to do anything at all when you
generate undefined behavior. Since there is a function with that
name, it links. Some C compilers use an object file format where they
can detect a mis-match in return types when linking, others do not.
There is no requirement in the C standard that they do.

Note that under the 1999 and later versions of the C standard, this
"implicit declaration of function returning int" has been removed from
the language. A compiler conforming to the later standard versions
would be required to issue a diagnostic for this, but that still does
not prevent it from trying to produce a program.

Finally, every compiler I have ever used has an option to generate
some sort of message when you call a function without a prototype,
even prior to C99 where this was not actually a constraint violation.
You should consult your compiler's documentation to see how to enable
such warnings.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
.



Relevant Pages

  • Re: pointer to const int
    ... int main ... ..and in fact the former causes undefined behavior. ... it's not an explicit requirement stated normatively in the standard ... terminating new-line character is implementation-defined. ...
    (comp.lang.c)
  • Re: pointers?
    ... int foo ... If the compiler takes the effort to actually recognize that this is ... addresses do not work like in a flat address space. ... "contiguous region" in the standard document. ...
    (comp.lang.forth)
  • Re: Unknown function
    ... int main ... message) "the compiler actually dos not "know" the signature of malloc()", I understand it in the way that malloc is not known to the compiler at that specific point of program. ... What the standard mandates that the compiler must do and what the compiler can do in addition to what the standard mandates. ...
    (comp.lang.c)
  • Re: constant string doubt
    ... The standard library functions are part of the program. ... The actions constitute undefined behavior. ... Constraint violations require a diagnostic, ... int main{ ...
    (comp.lang.c)
  • Using restricted pointers with newly allocated arrays/structures
    ... return (int) x; ... The use of "restrict" here is intended to inform the compiler that x ... However, according to 6.7.3.1p4 of the standard, the code seems to ... based on restricted pointer x, is used to access the object x(and ...
    (comp.std.c)