Re: sizeof(ptr) = ?

On Tue, 23 Oct 2007 16:06:57 +0200, Richard wrote:
I am going back, again, to the pointers being different sizes.

Say,
sizeof(char *) == 6
sizeof(int *) == 4


If we agree that all memory from Malloc is to a single "type of memory".
It returns a pointer to "thingies". Lets say this "pointer" must fit in
a void * (which it must).

A void * has the same representation as a char *.
sizeof (void *) = 6


thingies *p = malloc(2048);// (for example)
at what point can p become bigger or smaller than p2 here:
char *p2=malloc(2048);

Would you agree it can not become smaller since that would imply losing
some address information required for the subsequent call to free()?

No. *Malloc returns a pointer suitably aligned for any data type*, and,
a pointer of any type can be cast to void and back to _its_ _original_
_type_.

This is guaranteed by the standard (untested):
int fatthing;
void *p = &fatthing;
(int *) p == &fatthing;

This is _not_ guaranteed by the standard:
char thinthing;
int *p = &thinthing;
(char *) p == &thinthing;

and on a handful of systems without byte addresses (ie, whose
addresses specify a multi-byte entity) the latter is not true.
Char pointers (and void pointers) which require additional data
to specify an offset can be used in a conforming implementation
iff the default offset is 0.


If it became bigger than the char * above, I guess the cast to put it
(implicit or explicit) into a void * for a call to free then takes care
of converting it again to something that free understands?

Yes.

But if free
then understands it - what information from its "bigger implementation"
has been lost and how does that get "replaced" when we convert the void
* back to a pointer to thingies?

A byte offset gets lost:

char *thingy = malloc(17);
thingy = thingy + 1; /* unsuitable for free */
thingy = (int *) thingy; /* fixed! but not a smart thing to do */
free(thingy)l; /* works */

Maybe I have a head tumor on this thing, but I'm constantly puzzled by
how frequently people tell us that pointers to blocks of memory returned
by malloc can be different sizes.

Because nobody told you that. Pointers to _objects_ of different _types_
can be different sizes *and still allow a conforming implementation* if
the casting sequences (void *)(type *)(void *) (required by malloc) and
(type *)(void *)(type *) (required explicitly) both yield a pointer with
the original value. Other than that, and void pointers smell like char
pointers, I am not aware of anything else *in the standard* which
mandates pointer size; if you'll tell us what requirement you believe
was not met on implementations where sizeof(void *) != sizeof (int *),
it would make further discussions more productive.


Modern systems mostly use byte addresses, memory can be addressed as
a simple array of bytes. Systems that use *word (for sizeof(word)>1)
addresses must address bytes as, effectively, a doubly dimensioned
array, memory[word][byte]. On some such systems, word and byte pointers
were handled differently, with the byte offset occupying additional
space in char and void pointers, rather than make all pointers the
same size and throw away the extra space (or waste time processing
the always-zero) on word pointers.

*I'm using "word" for the addressable object, which has been short,
int, and long in word-addressable architectures that I'm aware of.

Martin
--
Martin Golding | Never anthropomorphise computers.
DoD #236 KotLQ KotSM | They HATE that.
.

Relevant Pages

  • Re: question realted to void *
    ... The standard has a very specific definition for "compatible types"; ... void* and char* are not compatible. ... qualified and both shall be pointers to compatible types. ... Since void and char are not compatible, ...
    (comp.lang.c)
  • Re: Adding to void *
    ... the "correct" behavior is to cast to char or similar, ... void f ... The one thing you failed to say is that for C the strict solution of not being able to do arithmetic on pointers to void was chosen which is why the second example above is not legal. ...
    (comp.lang.c)
  • Re: Passing void pointer to p_thread that is a Char
    ... > Read up on memory addresses, pointers, and such. ... >> p_thread creates demands a void variable. ... > The function expects a void*, but you want to give it a char. ... > char var; ...
    (comp.lang.c)
  • Re: Question about void pointers
    ... it's a matter of whether you prefer void * or char *. ... a pointer to character than char *? ... I was talking about pointers to int, double, long long, ...
    (comp.lang.c)
  • [PATCH 7/7] pagemap: add page-types tool
    ... a handy tool for querying page flags. ... +void show_page(unsigned long offset, uint64_t flags) ... +unsigned long long parse_number(const char *str) ...
    (Linux-Kernel)