Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Simple Casting Question

Reply
Thread Tools

Simple Casting Question

 
 
Harald van Dijk
Guest
Posts: n/a
 
      05-19-2008
On Tue, 20 May 2008 08:57:10 +1200, Ian Collins wrote:
> 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.)
>>

> 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.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      05-19-2008
Ian Collins <(E-Mail Removed)> writes:
> Keith Thompson wrote:
>> CBFalconer <(E-Mail Removed)> writes:
>>> http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>>>> pete <(E-Mail Removed)> wrote:
>>>>
>>> ... snip ...
>>>>> The proper advice, is to #include <stdlib.h> prior to using
>>>>> malloc. That also suppresses whatever warning would result from
>>>>> the non-inclusion, but helps make for correct code.
>>>> It is also possible to include just the prototype of malloc
>>>> void *malloc(size_t); and not <stdlib.h>.
>>> I believe this is defined to lead to undefined behaviour (which may
>>> work as you want it). In this case it will usually work, but no
>>> guarantees.

>>
>> 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.)
>>

> 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.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Peter Nilsson
Guest
Posts: n/a
 
      05-20-2008
Keith Thompson wrote:
> CBFalconer <(E-Mail Removed)> writes:
> > (E-Mail Removed) wrote:
> > > pete <(E-Mail Removed)> wrote:
> > >

> > ... snip ...
> > > >
> > > > The proper advice, is to #include <stdlib.h> prior to
> > > > using malloc. That also suppresses whatever warning
> > > > would result from the non-inclusion, but helps make
> > > > for correct code.
> > >
> > > It is also possible to include just the prototype of malloc
> > > void *malloc(size_t); and not <stdlib.h>.

> >
> > I believe this is defined to lead to undefined behaviour
> > (which may work as you want it). In this case it will usually
> > work, but no guarantees.


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...

--
Peter
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-20-2008
Peter Nilsson <(E-Mail Removed)> writes:
> 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.)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      05-20-2008
Keith Thompson <(E-Mail Removed)> wrote:

> Ian Collins <(E-Mail Removed)> writes:
> > Keith Thompson wrote:
> >> CBFalconer <(E-Mail Removed)> writes:
> >>> (E-Mail Removed) wrote:
> >>>> pete <(E-Mail Removed)> wrote:
> >>>>


> >>>> It is also possible to include just the prototype of malloc
> >>>> void *malloc(size_t); and not <stdlib.h>.

^^^^^^

> >>> I believe this is defined to lead to undefined behaviour (which may
> >>> work as you want it). In this case it will usually work, but no
> >>> guarantees.
> >>
> >> 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.)
> >>

> > 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.


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
 
Reply With Quote
 
vippstar@gmail.com
Guest
Posts: n/a
 
      05-20-2008
On May 20, 11:10 am, (E-Mail Removed) (Richard Bos) wrote:
> Keith Thompson <(E-Mail Removed)> wrote:
> > Ian Collins <(E-Mail Removed)> writes:
> > > Keith Thompson wrote:
> > >> CBFalconer <(E-Mail Removed)> writes:
> > >>> (E-Mail Removed) wrote:
> > >>>> pete <(E-Mail Removed)> wrote:

>
> > >>>> It is also possible to include just the prototype of malloc
> > >>>> void *malloc(size_t); and not <stdlib.h>.

>
> ^^^^^^
>
> > >>> I believe this is defined to lead to undefined behaviour (which may
> > >>> work as you want it). In this case it will usually work, but no
> > >>> guarantees.

>
> > >> 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.)

>
> > > 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.

>
> 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>.
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      05-20-2008
(E-Mail Removed) wrote:

> On May 20, 11:10 am, (E-Mail Removed) (Richard Bos) wrote:
> > Keith Thompson <(E-Mail Removed)> wrote:
> > > Ian Collins <(E-Mail Removed)> writes:
> > > > Keith Thompson wrote:
> > > >> CBFalconer <(E-Mail Removed)> writes:
> > > >>> (E-Mail Removed) wrote:
> > > >>>> pete <(E-Mail Removed)> wrote:

> >
> > > >>>> It is also possible to include just the prototype of malloc
> > > >>>> void *malloc(size_t); and not <stdlib.h>.

> > ^^^^^^
> >
> > > >>> I believe this is defined to lead to undefined behaviour (which may
> > > >>> work as you want it). In this case it will usually work, but no
> > > >>> guarantees.

> >
> > > >> 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.)

> >
> > > > 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.

> >
> > 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>.


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Up casting and down casting Sosuke C++ 2 12-20-2009 03:24 PM
Problem with depracated casting method (down casting) Wally Barnes C++ 3 11-20-2008 05:33 AM
simple question on type casting~ black(flashing vampire) C++ 2 01-07-2006 09:29 AM
Another question about inheritance (up-casting and down-casting) kevin Java 11 01-08-2005 07:11 PM
Re: Simple Simple question!!! ashelley@inlandkwpp.com ASP .Net 0 06-25-2004 04:18 PM



Advertisments