Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #43675

Re: Defined and undefined C pointer manipulation

Show all headers | View raw

"James Harris" <james.harris.1@gmail.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnppk3rjxh.fsf@nuthaus.mib.org...
>> "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.)
>
> One compiler I use doesn't have uintptr_t or intptr_t. Sadly its limits.h 
> also has no constant that conceivably relates to the width of an address so 
> I cannot see an easy way to set up a suitable integer. I could possibly do 
> something like (untested)

If your implementation (compiler plus runtime library) doesn't define
uintptr_t and inptr_t, it's *probably* because it doesn't implement C99,
the standard that introduce those types and the <stdint.h> header that
defines them.

What compiler are you using?  Some compilers don't attempt to conform to
C99 unless you use an option that tells them to do so.

uintptr_t, intptr_t, and the macros that define their limits are defined
in <stdint.h>, not in <limits.h>.

>   #ifndef uintptr_t
>   #define uintptr_t size_t
>   #endif

That's reasonably likely to be correct, but it's not guaranteed.  size_t
has to be big enough to hold the size of any single object.  void*, and
therefore uintptr_t, has to be big enough to specify *any byte* of any
object.  For a typical system with a monolithic addressing space,
they're likely to be the same size.  For a system with a segmented
memory scheme, where there can be multiple segments but no single object
can occupy more than one segment, size_t might not be big enough to hold
a void* value without loss of information.

> It might be good to have some code that will check when the program starts 
> that the conditions are satisfied such as
>
>   if (sizeof(char *) != sizeof(uintptr_t)) ...
>
> A reasonable compromise? Would void * be any better there than char *?

void* is probably clearer that char*, but void* and char* are required
to have the same size and representation.

But uintptr_t could be *bigger* than void*.  You can convert a void* to
uintptr_t and back again without loss of information, but there's no
guarantee in the other direction.  (Still, they're the same size on
every system I've heard of.)

[...]

> Even in that environment couldn't a C program align addresses to two machine 
> words (128-bit in this case) by clearing the lowest bit of a pointer 
> (perhaps after rounding)? Then that bit could be used as a flag. I suppose 
> one would need to start with the null pointer or something else that was 
> guaranteed not to have any of the top three bits set but as long as that was 
> maintained as an invariant couldn't the use of the lowest bit be treated as 
> a flag?

I don't believe there's any advantage to using an alignment stricter
than 1 64-bit word.  I'd hesitate to impose such a requirement.

You could put the flag in the 4th bit from the top, which I believe is
always 0 for a valid pointer.  (The addressing space is much less than
2**60 words.)  Use a macro to define which bit you're using for the
flag.  You'd have to configure it manually, but that's not unreasonable
for this kind of low-level bit-twiddling.

>> You're not likely to encounter any current system, but who knows what
>> architectures will be in common use, say, 10 years from now?
>
> Yes. This is for a specific use but I would rather write code that depends 
> on C guarantees, if possible.

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

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