sizeof() confusion

[Steve Summit]

In article <2692 at cirrusl.UUCP> dhesi%cirrusl at oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
>>>        printf("sizeof 'c'     = %d\n", sizeof 'c');
>
>>Were you suprised that "'c'" was 4?
>>You shouldn't be.  That expression evaluates to an int, not a char.
>
>If characters are promoted to ints in expressions, then why isn't
>|sizeof c| equivalent to |sizeof (int) c|?

As Doug has pointed out, the Standard contains exhaustive
specifications of exactly when the "usual arithmetic conversions"
(i.e. promoting char to int) are carried out.

Though it's an ill-defined term (appearing nowhere in the Standard)
I find it useful to think of the notion of "dereference time."
(Please, let's not restart Usenet Standard Discussion #12671 on
the word "dereference.")  "Dereference time" is when you might
need the value of something, i.e. when you're doing arithmetic on
it (or, for pointers, using the unary * operator), but _not_ when
it's on the left-hand-side of the assignment operator, or the
operand of unary &, or the operand of sizeof.  "Dereference time"
is when you have to "look inside" an identifier, to pull out its
value.

(It is instructive to consider how differently the identifiers a
and b are handled in a simple assignment expression like "a = b".
b's value is fetched, and in fact this could be done fairly early
in the course of evaluation, but "a" must remain as a location%% --
an "lvalue" -- so we'll know where to store the value of the
right-hand-side when we're through evaluating it.  Fetching a's
value early in evaluation, or in fact at any point, would be a
completely counterproductive thing to do.)

It is at "dereference time" that the usual arithmetic conversions
are applied.  "Dereference time" is also when arrays decay into
pointers.

                                            Steve Summit
                                            scs at adam.mit.edu

(Now I'll get seventeen responses poking holes in this
"dereference time" notion and noting situations in which it's
incorrect or misleading.  I _said_ it was an ill-defined term,
and I'm only suggesting using it conceptually.  I suppose I
should think of a few exceptions first and mention them, to
forestall followups.)

%% The term "lvalue" takes its name from "left hand side," not
"location," and referring to "a," or any lvalue, as a "location"
can be misleading.  The currently Official definition of lvalue
is "an expression that designates an object" (ANSI section
3.2.2.1).  Note that "dereferencing" turns an lvalue into an
rvalue.