This is the mail archive of the
mailing list for the GCC project.
Re: C++ PATCH: 14035
Kai Henningsen wrote:
email@example.com (Mark Mitchell) wrote on 20.10.04 in <4176AB4F.firstname.lastname@example.org>:
There's no point in warning by default about a technical violation of
the standard for code that works on virtually all systems. And I only
say "virtually" because I'm not sure what obscure systems exist of which
I am unaware; I do not know of any systems on which these casts would
Presumably systems unsupported by gcc.
For example, there's an x86 (x<3) memory model where code and data are
distinct 64kB segments, and pointers are 16 bit offsets. You might be able
to have a data pointer that points to a function if those segments
overlap, but you won't get it unless your cast knows what constant to add
or subtract - and the pointer might not be in the overlap region.
Or in short, any system where you can have nonoverlapping code and data
Even those would be ok for the most common purpose that this cast is used
for. That is converting a func-ptr to a data-ptr so you can store it
in a generic void* variable. Before use, the pointer is converted
back to a func-ptr, and all is ok, provided no bits have been lost.
If you want to use the data pointer to look at the code of the function,
you're deep into system implementation territory and better know exactly
what you're doing.
What won't work are those models where the data pointers are 16bit and the
function pointers are 32bit (segment:offset pair in 286 land). Similarly
those arches where function pointers are more than merely a pointer to
code (and are therefore larger than a data pointer). I think the systems
gcc support that have such raw function pointers use an indirection
mechanism to make the 'cooked' function pointers seen by a program be the
same size as a data pointer (I could be wrong though).
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
email@example.com :: http://www.planetfall.pwp.blueyonder.co.uk