Post by Branimir MaksimovicOn Wed, 24 Mar 2010 14:06:28 +0000
Post by Ahem A Rivet's ShotOn Wed, 24 Mar 2010 14:45:24 +0100
Post by Branimir MaksimovicOn Wed, 24 Mar 2010 12:41:04 +0000
Post by Ahem A Rivet's ShotOnly if they're big enough - nothing prevents a C
implementation having no integer type bigger than 32 bits while
pointers are (say) 48 bits.
Problem is that integers are used to index into arrays.
Well strictly speaking you need size_t in order to guarantee
being able to index into any array.
Remember size_t is typedef. Can;t be float, can;t be pointer,
it has to be one of available ints.
It has to be an unsigned integer type.
Post by Branimir MaksimovicActually I don;t think size_t is any good for indexing into array.
Sure it is.
For a declared object of any type, ``sizeof object'' yields the size
in bytes of the object, with a result of type size_t. For an object
allocated by a call to malloc() the size argument to malloc is of
type size_t, so it can't create an object bigger than SIZE_MAX bytes.
(SIZE_MAX, as the name implies, is the largest possible value of
type size_t.)
Which means that, with the possible exception of some bizarre cases,
no object can be bigger than SIZE_MAX bytes. Since the elements
of an array must be at least 1 byte in size, it follows that the
maximum index for an array object cannot exceed SIZE_MAX.
size_t is the only integer type (other that uintmax_t) that has this
guarantee.
(The bizarre cases are things like calloc() with two arguments whose
product exceeds SIZE_MAX and large (possibly variable-length) arrays.
On most implementations, such objects can't created; calloc()
will return NULL and huge array object declarations will exceed
implementation limits. We've had some discussions here recently
about whether an implementation is, or should be, permitted to
support objects bigger than SIZE_MAX bytes.)
[...]
Post by Branimir MaksimovicPost by Ahem A Rivet's ShotNope size_t must be big enough for that, but there's no
requirement that any int type be as big as size_t.
And what size_t would be? Integer? float? pointer?
What you can pass to malloc?
You're right, size_t is a typedef for some existing unsigned integer
type. (Note: "integer type" not "int type"; "int" is one specific
integer type.) But there's no guarantee that any int type is as
big as a pointer. A pointer can point to any object in memory;
size_t only needs to be big enough to span a single object.
Post by Branimir MaksimovicPost by Ahem A Rivet's ShotPost by Branimir MaksimovicSince pointer arithmetic in C is identical with
array indexing, plain ints are actually C pointers
with relative addressing ,
No ints are not C pointers they have *very* different
arithmetic rules.
I don;t think so. as *(a+i) is identical to a[i] or i[a]
and a automatically converts to pointer to first element.
Did you know that array subscript is associative?
Commutative, not associative, as you acknowledged in a followup.
Because both pointer+integer and integer+pointer arithmetic are
supported (as well as pointer-integer and pointer-pointer). The
language *could* have required the pointer to appear on the LHS of the
"+", banning integer+pointer. The (unnecessary IMHO) symmetry goes
back to the early days of C, when the distinction between integers and
pointers wasn't as strong as it is now.
Post by Branimir MaksimovicOnly difference is that a+i increments by scale bytes, scale being
type that pointer points to.
Pointer addition is a different operation than integer addition.
Post by Branimir MaksimovicBut C memory model assumes absolute addressing.
Not really, though I suppose it depends on what exactly you mean by
"absolute addressing".
Post by Branimir MaksimovicYou can't do b=a+i;c=a+b;
But you can decrement, since if you substract two absolute addresses
you can;t get out of segment bounds.
That is why it would be useful to have relative /absolute semantics.
Just because to avoid casting ints to pointers in order to
have convenient syntax for array indexing.
I'm not sure what you're saying here, but in some of your other
articles in this thread I think you're conflating two different
things.
C requires all pointers of a given type to have the same size and
representation. char* and int* might be different, but any two
pointers to char are stored the same way. On some systems, it might
be convenient to be able to have different "flavors" of pointers to
the same type, where the different flavors might, for example, be able to
point to different regions of memory. On a 64-bit system, you might
want to have 64-bit pointers that can point anywhere, and 32-bit
pointers that can only point into the bottom 4GB of memory.
C doesn't support this. Pointers are distinguished only by the type
they point to. If I obtain a pointer to an int object, I can copy
that pointer value into any other pointer-to-int object and
dereference the copy without knowing or caring how the original
pointer was generated.
This kind of thing can be supported by an implementation-specific
extension, such as the "near" and "far" pointer types in some x86
compilers. But any code that uses such an extension is non-portable.
On the other hand, C does *not* assume a monolithic addressing space.
A C pointer might internally consist of a segment identifier plus
an offset into that segment. Pointer arithmetic might affect only
the offset.
Post by Branimir MaksimovicPost by Ahem A Rivet's ShotPost by Branimir Maksimovicwhile you p[revious explanation
shows that ordinary C pointers are actually absolute addressing
pointers with convenient syntax.
Actually implementation can identify any pointer with
int as they are identical to indexes into arrays,
but void* and char* has to be absolute addresses.
Pointers do not have to be any kind of address.
That depends on what you mean by "address". The C standard uses the
word to mean, essentially, a pointer value. But an address / pointer
value needn't be a machine address, either physical or virtual (though
on most implementations it is).
Post by Branimir Maksimovichttp://en.wikipedia.org/wiki/Pointer_%28computing%29
Wikipedia doesn't define what "pointer" means in C; the C standard
does.
Recommended reading: sections 4 (Pointers) and 6 (Arrays and Pointers)
of the comp.lang.c FAQ, <http://www.c-faq.com/>.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"