Re: Difference between variables and functions

From: Brian Raiter (blr_at_drizzle.com)
Date: 08/30/05 

Date: Mon, 29 Aug 2005 23:33:53 +0000 (UTC)

>> What if it wasn't a name conflict caused by a misunderstanding of
>> how the language worked, but rather a typo? In that case, second
>> guessing what the programmer meant and calling the function would
>> be exactly the _wrong_ thing to do.
>
> But he's calling a variable, so IMHO C should compile an indirect
> function call there.

Are you serious? A function's return value is part of its type. Should
the C compiler also take an educated guess as to the return type when
it magically casts this integer into a function pointer? And note that
we're ignoring the issue of the parameters for now, since C still
allows function parameters to go unspecified (though this is pretty
much deprecated).

If we assumed that the above issues were solved satisfactorily, then I
grant that it would be *possible* for an ANSI-compliant compiler to do
(since any attempt to use an integral value as a pointer is
automatically undefined behavior by the standard).

However, the odds are overwhelmingly that such a construction is a
typo, not intentional behavior, so I think it would be foolish for a
good compiler to accept such code silently. Far better to require the
user to explicitly put in a cast to a) indicate the type of the
parameters and return value, and b) show the compiler that this really
is what the programmer intended to do:

   read = ((ssize_t (*)(int, void*, size_t))read)(fd, buf, 1);

I believe gcc will accept the above line. (Though of course I wouldn't
recommend running it.)

>> It's illegal, it should compile, and it didn't. That's the way it's
>> supposed to work.
>
> But what's the concrete error?

Well, the short answer ANSI C standard does not permit you to use
integral values cast into pointer values. Any attempt to do so results
in undefined behavior, so the compiler is free to do whatever it wants
with your program. Many compilers choose to issue an error unless an
explicit cast is made. Not only does this make sense, but it also
frees the compiler from trying to deduce the correct pointer type from
the surrounding context.

b

Relevant Pages

  • Re: problem with memcpy and pointers/arrays confusion - again
    ... this second method is known as an explicit conversion, or cast. ... The cast, in effect, tells the compiler: ... the malloc function. ... function taking a size_t as a parameter and returning a void pointer (i.e. ...
    (comp.lang.c)
  • Re: Can I Trust Pointer Arithmetic In Re-Allocated Memory?
    ... If your compiler ... it works with a cast. ... Pointer arithmetic, as you probably know, is scaled by ... not sure about concerning realloc(). ...
    (comp.lang.c)
  • Re: Problem with malloc
    ... In C you need not cast void pointers. ... void pointer to any other pointer type. ... >> If your compiler pukes at that then you need a new ...
    (comp.lang.c)
  • Re: Another ANSI C question about volatile
    ... > The cast is on the address of x. ... > lvalue of type 'pointer to volatile int'. ... > volatile, ... > that a compiler, needing to reread xp each time, would then ...
    (comp.lang.c)
  • Re: How to convert Infix notation to postfix notation
    ... and make all strings const save where the intent ... function whose contract is to change the string. ... the compiler "just" prevents the string ... try to do using the pointer you get. ...
    (comp.lang.c)