[openbeos] Re: question about 64-bit processors
- From: André Braga <meianoite@xxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 17 Sep 2004 11:16:35 -0300
On Fri, 17 Sep 2004 13:41:26 +0200 CEST, Axel Dörfler
<axeld@xxxxxxxxxxxxxxxx> wrote:
> Ingo's suggestion could look like this:
>
> class BSomeClass {
> ...
> some class data
> ...
> #if sizeof(addr_t) == 4
> int32 _reserved[22];
> #else
> int32 _reserved[5];
> #endif
> };
Hmm. I assume the math involved in calculating the numbers "22" and
"5" is dependent on pointer size on the target machine (and, Marcus,
unless my brains are wasted, this corresponds to the primitive
datatype size that fits on this machine's general purpose registers as
they're only variables of this size whose contents are treated as
memory addresses; the int128 thing doesn't even exist, I was merely
tring to express this fact somehow), so the reserved portion is larger
or slimmer depending on the case, managing to keep the struct/class
size constant.
Unless I missed something again, this is still non-portable and wastes
space, so it's really no better than both the cases I suggested (one
that clipped the width of the pointer size, one which didn't but had
some blank padding between pointers as a side effect), not to mention
that I find the code I posted easier on the eyes. Are there any
caveats which can't be worked around, like mapping the layout of data
members in a C++ class to a C struct by the compiler?
And, if those internal details are exposed to (malicious) programmers,
can't they be used to exploit buffer overflows?...
Maybe a pair of public/private headers can be used? As long as struct
sizes are kept the same and its use is consistent with the rest of the
system,
int
char[4]
int
char[4]
won't look be any different (in regards to allocated memory) to
long
long
on a 64-bit machine. Is this correct?
--
"A year spent in artificial intelligence is enough to make one believe in God"
Alan J. Perlis
Other related posts:
