Simple Casting Question

[Harald van Dijk]

Is it legal for an implementation to include implementation specific
magic (calling conventions for example) in its standard library function
declarations?

This is allowed if without including the function's header, you can still
call the function by declaring it manually with a compatible function
declaration, with or without a prototype, and if after including the
function's header the function can be assigned to a compatible function
pointer and called like that. This allows alternate calling conventions,
if the calling convention specifies that the function saves more
registers than usual, for example. It does not allow alternate calling
conventions if arguments are passed via a different mechanism.

 

[Keith Thompson]

Is it legal for an implementation to include implementation specific
magic (calling conventions for example) in its standard library function
declarations?

Only if the magic doesn't violate C99 7.1.4p2:

Provided that a library function can be declared without reference
to any type defined in a header, it is also permissible to declare
the function and use it without including its associated header.

 

[Peter Nilsson]

Chalk another one up to the anti-malloc casters FUD file. ;-)

No, if you provide a correct prototype for a standard function,
it will work correctly. (If you get the prototype wrong, of
course, the behavior is undefined.)

Having said that, I can't think of any good reason to write
the prototype yourself rather than getting it from the standard
header.

On a freestanding environment, the function may be available,
but the header needn't be. Of course, I can't think of a good
reason why that would be the case...

 

[Keith Thompson]

Keith Thompson wrote: [...]

No, if you provide a correct prototype for a standard function,
it will work correctly. (If you get the prototype wrong, of
course, the behavior is undefined.)

Having said that, I can't think of any good reason to write
the prototype yourself rather than getting it from the standard
header.

On a freestanding environment, the function may be available,
but the header needn't be. Of course, I can't think of a good
reason why that would be the case...

I've seen implementations where, for some functions, the declaration
in the header was inconsistent with the actual implementation. You
could work around this by declaring the function yourself. (I don't
remember the details; might have been gcc under SunOS 4.1.3.)

 

[Richard Bos]

^^^^^^

Only if the magic doesn't violate C99 7.1.4p2:

Provided that a library function can be declared without reference

^^^^^^^^^^^^^^^^^

to any type defined in a header, it is also permissible to declare

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

the function and use it without including its associated header.

Of course, this does mean that declaring malloc() yourself (which is
what this discussion started with) is not valid: it needs size_t.
(Equally of course, I'd expect it to work anyway, if you've also somehow
provided a declaration of size_t. Even more of course, I would not
recommend doing so.)

Richard

 

[vippstar]

^^^^^^^^^^^^^^^^^> to any type defined in a header, it is also permissible to declare

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Of course, this does mean that declaring malloc() yourself (which is
what this discussion started with) is not valid: it needs size_t.
(Equally of course, I'd expect it to work anyway, if you've also somehow
provided a declaration of size_t. Even more of course, I would not
recommend doing so.)

size_t is defined in many headers, not just <stdlib.h>
For example, <stddef.h>, <stdio.h>.

 

[Richard Bos]

size_t is defined in many headers, not just <stdlib.h>
For example, <stddef.h>, <stdio.h>.

True, but immaterial. 7.1.4p2 doesn't state that the function must not
need any type defined in _that_ header, but in _a_ header. Whichever
header you take, size_t is defined in _a_ header, and the declaration of
malloc() needs it. This may or may not be an oversight.

Richard