Store information in pointers

[James Kuyper]

Francis Moreau wrote:
....

That's true. But 'uintptr_t' type is optional and I'm still wondering
the point to make it _optional_ since it makes it almost useless.

Making it optional allows the existence of conforming implementations of
C99 on platforms where is not feasible to efficiently implement an
integer type large enough to store all distinct pointer values uniquely.
If it were made mandatory, this would not magically make it possible to
write code using uintptr_t on those platforms, it simply would mean that
compilers for those platforms wouldn't bother trying to fully conform to
the C99 standard.

That's essentially the same thing that can be said about any of the
other optional types, such as uint32_t. Making it mandatory wouldn't
make it possible to write code which uses uint32_t on a 36-bit platform,
it would simply mean that there would be no fully conforming
implementation of C99 for such platforms.

Implementation leave out optional types are only left out because they
can't be implemented, not because the implementors are too lazy to add
the appropriate typedef. <stdint.h> is one of the easiest headers to
implement in the standard library.

 

[Michael Foukarakis]

On a related note, AMD64 requires virtual addresses expressed in
canonical form, explicitly to prevent this type of "optimization".

http://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details

The OP is not using the MS bits. RTFP.

 

[Ben Bacarisse]

Well if the structure's data is accessed and fits into one cache line,
then all information about the structure can be accessed with at most
one cache miss. But if the extra bit is not stored in the structure
you need to do an extra memory access to retrieve the information thus
one more chance to get a cache miss.

Even worse if the structure data and the extra bit share the same
cache line (this can happen depending on the cache configuration).

Maybe. I've given up trying to intuit how caches behave. You might get
an improvement from having, say, 64 extra bits all packed together into
one word -- it might depend on the access pattern. Equally, you might
loose out due to the extra space. I doubt the wisdom of worrying about
that now.

That's true. But 'uintptr_t' type is optional and I'm still wondering
the point to make it _optional_ since it makes it almost useless.

I think it helps you! It's optional but just a typedef. What
implementation will fail to define it if such a type is natural for the
architecture in question? I.e. your use of it signals the kind of
assumption you are making and a failure to compile will then flag an
issue that needs to be investigated. If it turns out that there is no
natural type for it, then it has helped show up where you need more
trickery. If there is a natural type to use, one line (and a few #ifs)
fixes the whole program.

 

[Francis Moreau]

I think it helps you!  It's optional but just a typedef.  What
implementation will fail to define it if such a type is natural for the
architecture in question?  I.e. your use of it signals the kind of
assumption you are making and a failure to compile will then flag an
issue that needs to be investigated.  If it turns out that there is no
natural type for it, then it has helped show up where you need more
trickery.  If there is a natural type to use, one line (and a few #ifs)
fixes the whole program.

Agreed.

BTW, are there any portable ways to test if 'uintptr' type is defined
by the current implementation ?

For example:

#ifdef _uintptr_defined
/* do some nice not portable code */
#else
/* don't use any pointer trickery */
#endif

 

[Ben Bacarisse]

BTW, are there any portable ways to test if 'uintptr' type is defined
by the current implementation ?

If it is defined then the macro UINTPTR_MAX must be defined and you can
test for that.

<snip>

 

[Francis Moreau]

If it is defined then the macro UINTPTR_MAX must be defined and you can
test for that.

good idea.

Thanks

 

[Francis Moreau]

[...]

BTW, are there any portable ways to test if 'uintptr' type is defined
by the current implementation ?

For example:

#ifdef _uintptr_defined
        /* do some nice not portable code */
#else
        /* don't use any pointer trickery */
#endif

Yes.

#ifdef UINTPTR_MAX

Thanks !

 

[bart.c]

On 4/28/2010 7:53 AM, Francis Moreau wrote:

Yes, it's likely to work. On the other hand, I hope there's
a special place in Hell reserved for a person I once knew who did
this with function pointers, "knowing" that machine instructions
always had four-byte alignment. I was the lucky fellow who had
to get his code running on a VAX, whose instructions came in all
manner of lengths and had no alignment at all ...

That doesn't mean you can't use the same method. You just have to make sure
the *first* instruction in a function is at the right alignment. Although
that might not be so easy to control from within the language.

 

[Eric Sosman]

That doesn't mean you can't use the same method. You just have to make
sure the *first* instruction in a function is at the right alignment.
Although that might not be so easy to control from within the language.

"Might not be so easy." Right you are, laddie, right you are.

(Actually, the VAX' function pointers didn't even point at an
instruction at all, but at an "entry mask" that told the CALLx
instruction which registers to save. The instructions per se began
just after the mask -- but since neither the instructions nor the
mask required any special alignment, the low-order bits of a function
pointer viewed as an integer were essentially random. And so was
the behavior of my ex-colleague's code ...)

 

[bart.c]

"Might not be so easy." Right you are, laddie, right you are.

(Actually, the VAX' function pointers didn't even point at an
instruction at all, but at an "entry mask" that told the CALLx
instruction which registers to save. The instructions per se began
just after the mask -- but since neither the instructions nor the
mask required any special alignment, the low-order bits of a function
pointer viewed as an integer were essentially random.

There might have been a compiler switch (or modification) to place the masks
at aligned positions. That's assuming C source code exists to recompile
those functions.

Otherwise it's trickier (especially if an external or foreign function
passes a function pointer to the application that doesn't follow the rules).