This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ PATCH: 14035


Kai Henningsen wrote:
mark@codesourcery.com (Mark Mitchell) wrote on 20.10.04 in <4176AB4F.8040208@codesourcery.com>:

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

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

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

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]