Re: Pointer initialization.

From: Stephen L. (sdlnospamar_at_cast-com.net)
Date: 05/24/04 

Date: Mon, 24 May 2004 10:01:45 -0400

Jack Klein wrote:
>

   [snip]

>
> Representation includes both the amount of memory occupied (i.e.,
> size) and the interpretation of the bit pattern.
>
> It is about time you stopped spouting nonsense and started paying
> attention. You seem to have some experience with one or a few
> compilers on one or a few particular platforms and thing you are
> familiar with everything the C language encompasses.
>
> 2. Automatically pack and un-pack characters from machine words which
> hold multiple characters (rather like packed arrays in Pascal).

I think you're (honestly) referring to machines which
don't have byte addressing in their architecture, so
getting at a character that's on an odd address involves
reading the whole word (for argument's sake, 16 bits)
and manipulating it to the "correct" position in the
machine's registers. But the necessity of this operation
can be determined by looking at the LSB(s) of the address.
The pointer itself doesn't need extra "helper/magic" bits.

Some mainframes are like this.

> All other types occupy one or more full machine words. There are
> perfectly conforming C implementations for these architectures as
> well. In this case, pointers to char and therefore pointers to void
> have more information than other pointer types. They not only must
> contain the address of a machine word, as all other pointer types do,
> but also some extra bits specifying which 8 bits out of the 32 or 64
> are being referenced.

Let's see...

I hope you agree with the standard that `void *' and
`char *' have the same representation and alignment.

On my Sparc, If I build a 64-bit application, it's possible
that any pointer to char _might_ be "wider" than 64-bits,
based on your argument above.

How much wider? Well, the standard seems to imply it must
be an integral of CHAR_BIT, so the next size (since CHAR_BIT
is 8 on my Sparc) is 72 bits. (But pointers on Sparc must
be aligned to an 8 byte boundary (in 64-bit mode), so it
follows that an array of `char *'s will have a maximum
of 3 bytes of padding between each pointer.)

So my Sparc must read a total of _at least_ 72 bits,
64 for the "actual" pointer to my char, and some other
unspecified amount (at least 3 bits, but may 4 if the
magic is signed) to tell where the `char', that is
pointed to, _actually_ is in memory. Again, this is
what you're saying. Let me illustrate ---

        char *foo = malloc(1);

...could _never_ work because I've only allocated a single
byte for the character's position. You've stated that
the character _really_ could be in one of 8 positions
(because I'm running in 64-bit mode), so my `malloc()' is
actually wrong. I've been caught by the infamous
"off by seven" bug which plagues modern software professionals.

So, I must `malloc()' the correct number of bytes
to contain a single char -

        char *foo = malloc(8);

It gets better... Consider ->

        char str[] = "ab";
        char *p1 = &str[ 0 ];
        char *p2 = &str[ 1 ];

Not only do `p1' and `p2' differ by the value of
their address (which I have absolutely no problem with),
but the "magic" bits, telling which 8 bits out of the
64 to use to _find_ the char, may be different too.

This because the Sparc, when reading 64 bits at once,
must read them on a 64 bit boundry. Either of `p1'/`p2'
satisfy the requirement, but not both.

Or are you suggesting that it will read 8 consecutive
bytes beginning at the address, decode the magic bits,
then figure out what byte is the _real_ char?

If I increment `p1' so that its value matches that of
`p2', does its value remain unchanged, but the magic
bit(s) change to reflect the new _relative_ postition of
the character in the "machine word"? 

---
Stephen

Relevant Pages

  • Re: Problem with va_ macros and arrays of arrays
    ... > the arrays passed to a ... > specific char, somewhat similar to what the standard function ... that with an array of struct, or possibly a pointer to a dynamic array ... > As I'm still a beginner in C without a copy of the standard I ...
    (comp.lang.c)
  • Re: Insufficient guarantees for null pointers?
    ... will the compiler know what the bounds are after converting that char * ... to an int *, if it could point to either of two arrays which happen to ... compares equal to the original pointer. ...
    (comp.std.c)
  • Re: Size of char on a 64 bit machine
    ... >byte is used to store the character and the rest 7 bytes are wasted, ... due to the special properties of the type unsigned char: ... Because the machine uses word addressing, char pointers need to store more ... additional operations when the pointer is dereferenced, ...
    (comp.lang.c)
  • Re: How to mid string on a binary string?
    ... > return a pointer from that postion to the end of the binary stirng. ... I don't know how I can do a char ... just what you mean by "binary string". ... including the first null character". ...
    (comp.lang.c)
  • Re: memory leak?
    ... here is to know that GetData gives a pointer the actual data. ... instead of 'char' (I don't know if the C++ ... One of the problems with using 'char' is that it is confusing if the application is ... to represent character data, and that is confusing, because mostly characters are now ...
    (microsoft.public.vc.mfc)