Cannonical way to determine if a pointer points to a buffer starting on an odd byte.
Author Message
Cannonical way to determine if a pointer points to a buffer starting on an odd byte.

I have a requirement to figure out if a pointer that is passed to me
points to a location that is on an odd byte boundary.  Is there a
cannonical way to do this while adhering to the standard?  I realize
that most pointer arithmetic is not allowed, and copying the pointer to
a regular variable may break if in the future the pointer type becomes
bigger than the variable.  I guess what I really need to know is if the
least significant bit in the address is a 1 or 0.
--

Wed, 29 Jan 2003 03:00:00 GMT
Cannonical way to determine if a pointer points to a buffer starting on an odd byte.

Quote:
>I have a requirement to figure out if a pointer that is passed to me
>points to a location that is on an odd byte boundary.  Is there a
>cannonical way to do this while adhering to the standard?  I realize
>that most pointer arithmetic is not allowed, and copying the pointer to
>a regular variable may break if in the future the pointer type becomes
>bigger than the variable.  I guess what I really need to know is if the
>least significant bit in the address is a 1 or 0.

To get to the least significant bit of the address you have to convert
the pointer to an integral type.  But the result of such a conversion
is implementation-defined.  So, there is no canonical way of doing it.

Dan
--
Dan Pop
CERN, IT Division

Mail:  CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
--

Fri, 31 Jan 2003 03:00:00 GMT
Cannonical way to determine if a pointer points to a buffer starting on an odd byte.

Quote:

> copying the pointer to a regular variable may break if in the future
> the pointer type becomes bigger than the variable.

The C99 types intptr_t and uintptr_t are always long enough.
However, the bit patterns of pointers converted to integers are
system-specific so just taking the lsb of the result isn't
guaranteed to give you what you want.
--

Fri, 31 Jan 2003 03:00:00 GMT
Cannonical way to determine if a pointer points to a buffer starting on an odd byte.

Quote:

> I have a requirement to figure out if a pointer that is passed to me
> points to a location that is on an odd byte boundary.  Is there a
> cannonical way to do this while adhering to the standard?  I realize
> that most pointer arithmetic is not allowed, and copying the pointer to
> a regular variable may break if in the future the pointer type becomes
> bigger than the variable.  I guess what I really need to know is if the
> least significant bit in the address is a 1 or 0.

The C standard says nothing about byte alignment of variables, or
about byte boundaries.  So, any solution to your problem will rely
on compiler dependent behaviour.  It also makes no guarantee
of the results of converting pointers to integral values and
back.

That means a canonical solution does not exist.

Out of curiosity, why do you need to do this?
--

Fri, 31 Jan 2003 03:00:00 GMT
Cannonical way to determine if a pointer points to a buffer starting on an odd byte.

Quote:

> I have a requirement to figure out if a pointer that is passed to me
> points to a location that is on an odd byte boundary.

A somewhat suspicious requirement, that is. No portable C program
should ever need it. Nor can you do that, in portable C. In short:
you're probably trying to solve the wrong end of the problem.

Quote:
> I guess what I really need to know is if the least significant bit
> in the address is a 1 or 0.

That's something you cannot know, by the rules of ANSI C. It's not
even guaranteed that pointers *are* addresses, or that they have such
a thing as a least significant bit. This may seem strange, but OTOH,
it allowed for C implementations on some *really* odd types of
hardware, in the past. Pointers are 'magic cookies', essentially.
There's no way to look 'inside' a pointer without trespassing into
implementation-defined area.
--

Even if all the snow were burnt, ashes would remain.
--

Fri, 31 Jan 2003 03:00:00 GMT
Cannonical way to determine if a pointer points to a buffer starting on an odd byte.

Quote:

> > copying the pointer to a regular variable may break if in the future
> > the pointer type becomes bigger than the variable.

> The C99 types intptr_t and uintptr_t are always long enough.
> However, the bit patterns of pointers converted to integers are
> system-specific so just taking the lsb of the result isn't
> guaranteed to give you what you want.
> --

Thank you for this; I would have loved to use it, but it seems that the
compiler that I am currently using is not C99: batbarf.

Sam
--

Sat, 01 Feb 2003 10:36:38 GMT
Cannonical way to determine if a pointer points to a buffer starting on an odd byte.

Quote:

>The C standard says nothing about byte alignment of variables, or

Not so.  ISO/IEC 9899:1999 contains the word "alignment" (with
this meaning) 9 times, not counting its appearances in footnotes,
annexes, and the index.

The previous version of the standard also mentioned alignment
requirements several times.

Since alignments are implementation-defined or unspecified, the
next sentence:

Quote:
>So, any solution to your problem will rely
>on compiler dependent behaviour.

is true anyway.

-- Gary Culp
--

Sat, 01 Feb 2003 03:00:00 GMT
Cannonical way to determine if a pointer points to a buffer starting on an odd byte.

Quote:
> The C99 types intptr_t and uintptr_t are always long enough.

Only if they exist; the standard specifically says they're optional.
There may not be any integer type big enough to hold a pointer without
loss of information.

--

San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.
--

Sun, 02 Feb 2003 03:00:00 GMT
Cannonical way to determine if a pointer points to a buffer starting on an odd byte.

Quote:

> I have a requirement to figure out if a pointer that is passed to me
> points to a location that is on an odd byte boundary.  Is there a
> cannonical way to do this while adhering to the standard?

No.  The requirement seems inherently non-portable; the solution will
be as well.

On many systems, you can cast the pointer to some integer type
(choosing one that's big enough is left as an exercise) and checking
the low-order bit.  Isolate the code in the system-specific part of
your application and clearly document the assumptions you're making.

You might need different versions of this code for different systems.
On the Cray T90, for example, the following should work:

if ((unsigned int)ptr & 0x2000000000000000) {
printf("It's odd\n");
}
else {
printf("It's even\n");
}

--

San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.
--

Sun, 02 Feb 2003 03:00:00 GMT
Cannonical way to determine if a pointer points to a buffer starting on an odd byte.

Quote:

> > I have a requirement to figure out if a pointer that is passed to me
> > points to a location that is on an odd byte boundary.

> A somewhat suspicious requirement, that is. No portable C program
> should ever need it. Nor can you do that, in portable C. In short:
> you're probably trying to solve the wrong end of the problem.

I think that you're being too rough on Sam here.  Sam says he
has a requirement.  It may not be of his own making.  And
just because something isn't portable across all architectures,
it does not mean that it can't conform to the ANSI standard
(which, in turn, makes it more likely that it will work on
other compilers on the original target architecture).

I have, in the past, had the job of writing all sorts of code in C
that was optimized to the environment.  There was a memcpy() that
used the largest block memory transfers that it could (which had
alignment restrictions) and then used byte copies for the ends that
didn't fit within the block transfer, graphics firmware primatives
where pattern copy performance was crucial, and so on.

I was required to write this all in ANSI C.  Some of the things I did were
not portable to other machines.  So what.  I documented those non-portable
parts of the code.

Daniel Glasser

--

Tue, 04 Feb 2003 03:00:00 GMT

 Page 1 of 1 [ 10 post ]

Relevant Pages