Re: A taxonomy of types

"cr88192" <cr88192@xxxxxxxxxxx> wrote in message
news:gmea2f$5np$1@xxxxxxxxxxxxxxxxxxxx
(Correction: C doesn't have arrays. C has the offset operator. C has
array
declarations, which are designed to work with the offset operator...)


theoretically, and in terms of the functioning...

however, to actually compile the code correctly (AKA: following correct
array semantics, ...)

How can there be "correct array semantics" when no arrays exist in C? Did
you mean "following correct offset operator semantics"... ?

one actually needs to have explicit array types, which
are considered distinct from the pointer-based types.

IMO, both parts of that would be in error. Explicit array types don't exist
in C. What does exist is based exclusively on pointer type. That pointer
is hidden from the user an implementation specific according to the spec.
That is for computing platforms that have problems using a generic pointer
to effective an implement array type. For most systems, it's just a
pointer.

this is too simplistic...

consider a user types: 'foo->x'.

foo->x is equivalent to (*foo).x

dereference foo, get x using x's offset from start of struct pointed to by
foo

I'd think it'd be something like this where 'foo' and 'x' are 32-bit offsets
in assembly and 'foo' and 'x' is an 32-bit values in C, using eax as a temp:

mov eax, foo ; pointer or address foo to eax
mov eax, [eax] ; *foo (dereference) to eax
lea eax,[eax+x] ; *foo plus offset of x into struct to eax
mov eax, [eax] ; x to eax

or 'foo->bar(3, 4);'

foo->bar(3,4) is equivalent to (*foo).bar(3,4)

Same thing except you need to call a function...

if the representation can't deal with more than base-types, the above
expressions can't be compiled...

I don't understand your claim. Why? Why can't they be compiled? I mean, I
just provided one possible implementation of the first situation in assembly
right off the top of my head... As I see it, they just need to be broken
down into equivalent smaller sequences that reduce to pointers or addresses
and offsets.

s/t: signed/unsigned 16-bit short;
i/j: signed/unsigned 32-bit int;
l/m: signed/unsigned 64-bit long;
n/o: signed/unsigned 128-bit int;

Hmm, I guess it's time for me to go back to the C spec., since I
thought
for
sure that "int" had to be a "char", "short", "long", or "long long",
not
a
distinct type by itself as you've done... (Am I wrong?)


int and long may have the same size (at least on x86, or in MSVC on
x64,
but
not in Linux on x86-64, PPC64, ...),

Well, technically, I think you comply with the wording of ISO C99... I
don't have a copy of ANSI C available here to check. But, I think that
doesn't comply with K&R C:

In K&R C in A.4.2 Basic Types:

"Besides the char types, up to three sizes of integer, declared short
int,
int, and long int, are available. Plain int objects have the natural
size
suggested by the host machine architecture; the other sizes are provided
to
meet special needs. Longer integers provide at least as much storage as
shorter ones, but the implementation may make plain integers equivalent
to
either short integers, or long integers."

The critical point being an "int" is either "short" or "long", not
between
the two...

Also, K&R C in 2.2 Data Types and Sizes :

"int an integer, typically reflecting the natural size of integers on
the
host machine"
...
"The intent is that short and long should provide different lengths of
integers where practical; int will normally be the natural size for a
particular machine. short is often 16 bits long, and int either 16 or 32
bits. Each compiler is free to choose appropriate sizes for its own
hardware, subject only to the the restriction that shorts and ints are
at
least 16 bits, longs are at least 32 bits, and short is no longer than
int,
which is no longer than long."


yes.

With what are you agreeing? All of it? Then, you understand the last
sentence quoted of 4.2 gives you a choice between implementing int as a
short or long... If not, see my reply to Verlinde a post above...

not exactly...

"the same size as" does not mean "the same as"...


I don't see that wording...


Rod Pemberton


.

Relevant Pages

  • Re: Warning on assigning a function-returning-a-pointer-to-arrays
    ... This declares pfunc as a function taking no arguments and returning ... int x, y; ... Presumably pfuncwill return a pointer to a single int, ... or the first of a sequence of "array 5 of int"s. ...
    (comp.lang.c)
  • Re: Newbie
    ... to talk about the int value 3 and the int value 4, ... It also lets you talk about pointer ... C has a special rule for array objects. ... to printf() is: ...
    (comp.lang.c)
  • Re: Assignment: Print 2D array
    ... Then create two functions for printing the 2D array. ... int column = 0; ... int offset = 0; ... Flash Gordon, living in interesting times. ...
    (comp.lang.c)
  • Re: union {unsigned char u[10]; ...}
    ... But character type is not a union. ... u.a is of type int. ... has to do so to make pointer equality work consistently). ... were a single-element array. ...
    (comp.lang.c)
  • Re: How to pass a pointer to an unknown-size array?
    ... > I can pass a "pointer to a double" to a function that accepts ... > int func{ ... > Now I want to pass a pointer to an array of doubles, ...
    (comp.lang.c)
Loading