In article <djNuf.70590$(E-Mail Removed) >

Robert Harris <(E-Mail Removed)> wrote:

>... If mese is an array, then mese and &mese are the same thing.
In much the same way that 3 and 3.141592653589793 are "the same

thing", i.e., they compare equal when converted to some particular

common type (int, in this case).

The problem is that "&mese" has the wrong type. It is hard to

compare two values of different types (are 3 and 3.14 equal?); the

first step in such a comparison is to choose some additional type

-- perhaps one of the original two, or perhaps a third -- and

convert all the values to the same type, after which they can

finally be compared.

In the case of 3 and 3.14, if the type chosen for comparison is

"int", they are equal. If the type chosen for comparison is

"double", they are not equal. So 3 and 3.14 are equal, and yet

are also not equal.

I use the above example to make it clear that it is not sufficient

to find *a* type under conversion to which comparison shows the

original values as equal: while (int)3 == (int)3.14, I think most

people would say that 3 and 3.14 are *not* equal, and indeed,

(double)3 != (double)3.14.

You would have a much stronger case if you could prove that, for

some large set of C types \elem T, (T)mese == (T)&mese; but I think

this is impossible to prove in "Standard C Virtual Machine", due

to lack of information. (It actually happens to be true on many

real machines, if only because so many real machines have only one

hardware "pointer" type, or at least, only one that is used by C

compilers. The test is more interesting -- not a "degenerate case"

as a mathematician might put it -- when performed on machines with

actual different hardware pointer types, such as a Data General

MV/10000, or a 1960s PR1ME, or some such.)

In any case, Standard C permits an 80x86 C compiler to pass mese

(or &mese[0]) in a register, but put &mese on the stack (or vice

versa), simply because the types differ. If an 80x86 C compiler

did this, calls using the wrong type would in fact fail, even on

the ordinary 80x86. (In this particular case, &mese[0] has type

(char *), but &mese has type (char (*)[5]).)

--

In-Real-Life: Chris Torek, Wind River Systems

Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603

email: forget about it

http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.