Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Defined and undefined C pointer manipulation |
| Date | 2014-04-26 12:04 -0700 |
| Organization | None to speak of |
| Message-ID | <lnppk3rjxh.fsf@nuthaus.mib.org> (permalink) |
| References | <ljgqns$t1i$1@dont-email.me> |
"James Harris" <james.harris.1@gmail.com> writes:
> I understand that a C pointer can have some basic arithmetic operations
> applied to it such as having an integer added or subtracted to step a whole
> number of the referred-to data type, or two pointers to the same data type
> being subtracted. However....
>
> To write a couple of memory management routines to implement malloc and free
> it would be handy to take one bit from a pointer to use as an indicator of
> whether a piece of memory is in use or is unused. Because each piece of
> memory will be aligned any valid pointer will have its lower bit(s) clear so
> it makes sense to take the lowest bit of a pointer and use it to indicate
> whether a region is used or unused. That would lead to expressions like
> these:
>
> ptr |= 1;
> ptr &= ~1;
> if (ptr & 1) ...
To use bitwise operations on pointers, you'd have to convert
to uintptr_t and back again. (That's assuming uintptr_t exists,
which it won't if no integer type is big enough to hold a converted
pointer value without loss of information. That's a reasonably
safe assumption, and if it's violated on some exotic system your
code will fail to compile.)
> My question is whether C's behaviour is defined or undefined for such
> pointer manipulations. Would the pointers need to be cast to char pointers
> for this to work? Any other issues I should be aware of?
The behavior is undefined, and I've worked on systems where it would
fail.
On Cray vector machines (T90, SV1), a machine address is a 64-bit
quantity containing the address of a 64-bit word in memory. The C
compiler has CHAR_BIT==8 (required because Unicos is a Unix-like
system). It implements byte pointers by storing a byte offset in the
(otherwise unused) high-order 3 bits of a 64-bit pointer value; this
offset is manipulated in software by code generated by the compiler.
(One result of this is that although Cray vector systems have blazingly
fast floating-point performance, string manipulation can be relatively
painfully slow.)
This means that, for a pointer of type char*, the low-order bit tells
you whether the word containing the pointed-to byte is at an odd or even
word address.
You're not likely to encounter any current system, but who knows what
architectures will be in common use, say, 10 years from now?
> I'm pretty sure that any implementation of C that I am likely to use will
> allow the kinds of pointer masking that I have in mind but are there better,
> more C-like ways to go about this? Are there implementations on which it
> might not work? And would it be acceptable to manipulate the pointers as
> pointers to char even though malloc and free are defined to work with
> pointers to void?
The C standard require char*, unsigned char*, signed char*, and void*
to have the same representation.
The *portable* way to do this would be to store the "used" bit
separately from the pointer. For example, if you know the base
address of the region of memory managed by malloc and free, you
can have a bit array (implemented with the usual shifts and masks)
containing one bit for each address within that region.
In C implementations, the code that implements malloc and free
*doesn't have to be portable*, and it commonly isn't. It's typically
optimized for different targets. It just as to behave as specified.
If you want something "portable" in the sense that it's not too
difficult to modify the code for porting to another system (as
opposed to recompiling it with no change), you might consider
writing a set of macros to handle the "used" bit, and to convert
back and forth between an annotated pointer and a unannotated
pointer. You can use a set of #ifdefs to switch between different
implementations of those macros for different systems.
Or you can just *assume* that an aligned pointer will always have
its low-order bit set to 0, at the cost of not supporting systems
where that assumption doesn't hold.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Defined and undefined C pointer manipulation "James Harris" <james.harris.1@gmail.com> - 2014-04-26 18:35 +0100
Re: Defined and undefined C pointer manipulation Keith Thompson <kst-u@mib.org> - 2014-04-26 12:04 -0700
Re: Defined and undefined C pointer manipulation "James Harris" <james.harris.1@gmail.com> - 2014-04-27 19:11 +0100
Re: Defined and undefined C pointer manipulation Barry Schwarz <schwarzb@dqel.com> - 2014-04-27 11:46 -0700
Re: Defined and undefined C pointer manipulation Keith Thompson <kst-u@mib.org> - 2014-04-27 12:46 -0700
Re: Defined and undefined C pointer manipulation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 02:53 +0100
Re: Defined and undefined C pointer manipulation Keith Thompson <kst-u@mib.org> - 2014-04-27 12:57 -0700
Re: Defined and undefined C pointer manipulation "James Harris" <james.harris.1@gmail.com> - 2014-04-27 21:56 +0100
Re: Defined and undefined C pointer manipulation Keith Thompson <kst-u@mib.org> - 2014-04-27 14:25 -0700
Re: Defined and undefined C pointer manipulation glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-27 22:51 +0000
Re: Defined and undefined C pointer manipulation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-27 06:21 -0700
Re: Defined and undefined C pointer manipulation "BartC" <bc@freeuk.com> - 2014-04-27 16:51 +0100
Re: Defined and undefined C pointer manipulation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-27 10:36 -0700
Re: Defined and undefined C pointer manipulation Ian Collins <ian-news@hotmail.com> - 2014-04-28 11:40 +1200
Re: Defined and undefined C pointer manipulation "James Harris" <james.harris.1@gmail.com> - 2014-04-27 19:23 +0100
Re: Defined and undefined C pointer manipulation Richard Damon <Richard@Damon-Family.org> - 2014-04-27 14:56 -0400
Re: Defined and undefined C pointer manipulation "James Harris" <james.harris.1@gmail.com> - 2014-04-27 20:52 +0100
Re: Defined and undefined C pointer manipulation Keith Thompson <kst-u@mib.org> - 2014-04-27 13:16 -0700
Re: Defined and undefined C pointer manipulation "BartC" <bc@freeuk.com> - 2014-04-27 20:55 +0100
Re: Defined and undefined C pointer manipulation "James Harris" <james.harris.1@gmail.com> - 2014-04-27 21:20 +0100
Re: Defined and undefined C pointer manipulation glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-27 22:39 +0000
Re: Defined and undefined C pointer manipulation glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-27 22:43 +0000
Re: Defined and undefined C pointer manipulation "BartC" <bc@freeuk.com> - 2014-04-28 00:13 +0100
Re: Defined and undefined C pointer manipulation Keith Thompson <kst-u@mib.org> - 2014-04-27 13:01 -0700
Re: Defined and undefined C pointer manipulation James Kuyper <jameskuyper@verizon.net> - 2014-04-27 22:07 -0400
Re: Defined and undefined C pointer manipulation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 00:47 -0700
Re: Defined and undefined C pointer manipulation Ian Collins <ian-news@hotmail.com> - 2014-04-28 20:01 +1200
Re: Defined and undefined C pointer manipulation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 02:11 -0700
Re: Defined and undefined C pointer manipulation Ian Collins <ian-news@hotmail.com> - 2014-04-28 22:38 +1200
Re: Defined and undefined C pointer manipulation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 04:50 -0700
Re: Defined and undefined C pointer manipulation "BartC" <bc@freeuk.com> - 2014-04-28 09:22 +0100
Re: Defined and undefined C pointer manipulation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 05:31 -0700
csiph-web