Re: Address of an array = address of its 1st element: undecidable question ?

[Richard Heathfield]

candide said:

Hi,
I try to find out what exactly means "an array and its address are the
same"

They aren't. An array is an array. An address is a pointer value. These are
not the same thing. If you mean that &array and &array[0] are the same,
they aren't. They have different types.

or "have the same value".

If you try to take the value of an array, what you actually get is the
value of a pointer to the first member of the array. That doesn't mean
that an array is the same as a pointer. If you mean that &array and
&array[0] have the same value, they don't. They have different types.

Everybody seems to agree that they doesn't share the same type, of
course.

And therefore they cannot have the same value.

<snip>

So what ? Is the question undecidable ?

No. The question was decided long ago.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Peter Nilsson]

Richard Heathfield <[e-mail]:

candide said:

I try to find out what exactly means "an array and
its address are the same"

They aren't. An array is an array. An address is a
pointer value. These are not the same thing. If you
mean that &array and &array[0] are the same,
they aren't. They have different types.

or "have the same value".

If you try to take the value of an array, what you
actually get is the value of a pointer to the first
member of the array. That doesn't mean that an array
is the same as a pointer. If you mean that &array
and &array[0] have the same value, they don't. They
have different types.

What about (void *) &array == (void *) &array[0]?

Everybody seems to agree that they doesn't share
the same type, of course.

And therefore they cannot have the same value.

So 1 is _not_ the same value as 1u?

Can you then tell me what the standard means when
it says...

"The range of nonnegative values of a signed
integer type is a subrange of the corresponding
unsigned integer type, and the representation
of the same value in each type is the same."
^^^^^^^^^^

Either 'same value' is independant of type, or
above line makes no sense. Which is it?

--
Peter

[pete]

Peter Nilsson wrote:

So 1 is _not_ the same value as 1u?

Only one of those, is greater than -1.

(1u < -1)

--
pete

[CBFalconer]

Peter Nilsson wrote:

Richard Heathfield <[e-mail]:

.... snip ...

>

>If you try to take the value of an array, what you
actually get is the value of a pointer to the first
member of the array. That doesn't mean that an array
is the same as a pointer. If you mean that &array
and &array[0] have the same value, they don't. They
have different types.

What about (void *) &array == (void *) &array[0]?

You should get "syntax error" or equivalent.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

** Posted from http://www.teranews.com **

[Richard Heathfield]

CBFalconer said:

Peter Nilsson wrote:

>Richard Heathfield <[e-mail]:

... snip ...

>>

>>If you try to take the value of an array, what you
actually get is the value of a pointer to the first
member of the array. That doesn't mean that an array
is the same as a pointer. If you mean that &array
and &array[0] have the same value, they don't. They
have different types.

What about (void *) &array == (void *) &array[0]?

You should get "syntax error" or equivalent.

Why?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Peter Nilsson said:

Richard Heathfield <[e-mail]:

>candide said:

I try to find out what exactly means "an array and
its address are the same"

They aren't. An array is an array. An address is a
pointer value. These are not the same thing. If you
mean that &array and &array[0] are the same,
they aren't. They have different types.

or "have the same value".

If you try to take the value of an array, what you
actually get is the value of a pointer to the first
member of the array. That doesn't mean that an array
is the same as a pointer. If you mean that &array
and &array[0] have the same value, they don't. They
have different types.

What about (void *) &array == (void *) &array[0]?

The expressions (void *) &array and (void *) &array[0] have the same type -
i.e. void *. Therefore, they /can/ have the same value (and may well
have).

Everybody seems to agree that they doesn't share
the same type, of course.

And therefore they cannot have the same value.

So 1 is _not_ the same value as 1u?

Correct - it isn't. 1 has type int, whereas 1u has type unsigned int. They
may well (and in fact do) share a great many characteristics, but they are
*not* the same. I'd have explained why, if pete had not already done so.

Can you then tell me what the standard means when
it says...

"The range of nonnegative values of a signed
integer type is a subrange of the corresponding
unsigned integer type, and the representation
of the same value in each type is the same."
^^^^^^^^^^

It means that the Standard isn't as picky about its use of the word "value"
as it should be. :-)

Either 'same value' is independant of type, or
above line makes no sense. Which is it?

In my opinion (since you ask!), the quoted line makes no sense. I'd have
been happier if it had said something like "the same numerical value" or
some such weasel phrase. Two values can have the same numerical value
despite being intrinsically different. Consider, for example, the
differences and similarities between -40degF (or, if you prefer, the very
different value -40degC) and -$40. If C had a Fahrenheit (or Celsius) type
and a dollar type, an assignment of one to the other (presumably with a
cast!) might well result in the numerical value -40 being preserved, and
they might even be represented in the same way internally. That doesn't
mean that degrees are dollars or that dollars are degrees.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[pete]

Richard Heathfield wrote:

Peter Nilsson said:

>Richard Heathfield <[e-mail]:

>>candide said:
I try to find out what exactly means "an array and
its address are the same"
They aren't. An array is an array. An address is a
pointer value. These are not the same thing. If you
mean that &array and &array[0] are the same,
they aren't. They have different types.

or "have the same value".
If you try to take the value of an array, what you
actually get is the value of a pointer to the first
member of the array. That doesn't mean that an array
is the same as a pointer. If you mean that &array
and &array[0] have the same value, they don't. They
have different types.

What about (void *) &array == (void *) &array[0]?

The expressions (void *) &array and (void *) &array[0] have the same type -
i.e. void *. Therefore, they /can/ have the same value (and may well
have).

((char *)&array) and ((char *)&array[0]) have the same value.

--
pete

[Bartc]

"pete" <pf*****@mindspring.comwrote in message
news:Tq******************************@earthlink.co m...

Peter Nilsson wrote:

>So 1 is _not_ the same value as 1u?

Only one of those, is greater than -1.

(1u < -1)

This is ridiculous and dangerous behaviour on the part of C;

(a<b) /* True */

++a; ++b;

(a<b) /* Now false! And without any wrap or overflow */

Obviously some amateurish work in the early days of C which later had to be
condoned by the standard.

The correct handling would have been to have cast both into a type
encompassing both values before comparing, or to give a warning.

(OK, my own compiler efforts do exactly the same, but my compiler isn't used
for supercomputers or mission critical software)
--
Bartc

[Eric Sosman]

Bartc wrote:

"pete" <pf*****@mindspring.comwrote in message
news:Tq******************************@earthlink.co m...

>Peter Nilsson wrote:

>>So 1 is _not_ the same value as 1u?

Only one of those, is greater than -1.

(1u < -1)

This is ridiculous and dangerous behaviour on the part of C;

(a<b) /* True */

++a; ++b;

(a<b) /* Now false! And without any wrap or overflow */

Perhaps I'm overlooking something obvious, but I don't
see how this could occur[*]. Would you mind offering a complete
example?
[*] Taking "overflow" to include the case of a finite
floating-point number incrementing to positive infinity.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Eric Sosman]

Eric Sosman wrote:

Bartc wrote:

>"pete" <pf*****@mindspring.comwrote in message
news:Tq******************************@earthlink.c om...

>>Peter Nilsson wrote:

So 1 is _not_ the same value as 1u?
Only one of those, is greater than -1.

(1u < -1)

This is ridiculous and dangerous behaviour on the part of C;

(a<b) /* True */

++a; ++b;

(a<b) /* Now false! And without any wrap or overflow */

Perhaps I'm overlooking something obvious, [...]

Aha! Never mind; I overlooked something obvious. Still,
your characterization of pointer arithmetic as "amateurish
work in the early days of C" is silly.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>Peter Nilsson wrote:

>>Richard Heathfield <[e-mail]:

... snip ...

>>>
If you try to take the value of an array, what you
actually get is the value of a pointer to the first
member of the array. That doesn't mean that an array
is the same as a pointer. If you mean that &array
and &array[0] have the same value, they don't. They
have different types.

What about (void *) &array == (void *) &array[0]?

You should get "syntax error" or equivalent.

Why?

Woops - I read that as '=', not as '=='. Good catch.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[vippstar]

On May 23, 12:59 pm, "Bartc" <[e-mail]:

"pete" <[e-mail] in message

news:Tq******************************@earthlink.co m...

Peter Nilsson wrote:

So 1 is _not_ the same value as 1u?

Only one of those, is greater than -1.

(1u < -1)

This is ridiculous and dangerous behaviour on the part of C;

No, it is not. It would be ridiculous and dangerous if anything else
happened.
What you're essentially saying here is that 1u UINT_MAX should be
true, or rather, that it's ridiculous it's true.
Add to that, that (unsigned)1 is also different than 1 or 1u.
It doesn't make sense until you learn about integer promotions in
expressions.

[Eric Sosman]

vi******@gmail.com wrote:

On May 23, 12:59 pm, "Bartc" <[e-mail]:

>"pete" <[e-mail] in message

news:Tq******************************@earthlink.c om...

>>Peter Nilsson wrote:
So 1 is _not_ the same value as 1u?
Only one of those, is greater than -1.
(1u < -1)

This is ridiculous and dangerous behaviour on the part of C;

No, it is not. It would be ridiculous and dangerous if anything else
happened.
What you're essentially saying here is that 1u UINT_MAX should be
true, or rather, that it's ridiculous it's true.
Add to that, that (unsigned)1 is also different than 1 or 1u.
It doesn't make sense until you learn about integer promotions in
expressions.

Having embarrassed myself once already on this topic,
it is with some trepidation that I suggest that's not what
he was saying. Here's the situation I think he had in mind:

char array[2][42];
char *p = &array[0][1];
char (*q)[42] = &array[0];
assert ( (void*)q < (void*)p );
++p; /* point to next char */
++q; /* point to next char[42] */
assert ( (void*)q (void*)p );

--
Er*********@sun.com

[Bartc]

"Eric Sosman" <Er*********@sun.comwrote in message
news:1211555836.742807@news1nwk...

vi******@gmail.com wrote:

>On May 23, 12:59 pm, "Bartc" <[e-mail]:

>>"pete" <[e-mail] in message

news:Tq******************************@earthlink. com...

Peter Nilsson wrote:
So 1 is _not_ the same value as 1u?
Only one of those, is greater than -1.
(1u < -1)
This is ridiculous and dangerous behaviour on the part of C;

No, it is not. It would be ridiculous and dangerous if anything else
happened.
What you're essentially saying here is that 1u UINT_MAX should be
true, or rather, that it's ridiculous it's true.
Add to that, that (unsigned)1 is also different than 1 or 1u.
It doesn't make sense until you learn about integer promotions in
expressions.

Having embarrassed myself once already on this topic,
it is with some trepidation that I suggest that's not what
he was saying. Here's the situation I think he had in mind:

I was merely talking about the (1u<-1) above:

#include <stdio.h>

int main(void)
{
unsigned int a=1;
signed int b=-1;

if (a<b) printf("A<B\n"); else printf("A>=B\n");

++a;
++b;

if (a<b) printf("A<B\n"); else printf("A>=B\n");

}

The increment changes 1 to 2, and -1 to 0, nothing dramatic.

The problem seems to me that comparing unsigned to signed (by I think
treating both as unsigned) seems a little dangerous.

--
bartc

[Keith Thompson]

Eric Sosman <es*****@ieee-dot-org.invalidwrites:

Eric Sosman wrote:

>Bartc wrote:

>>"pete" <pf*****@mindspring.comwrote in message
news:Tq******************************@earthlink. com...
Peter Nilsson wrote:

So 1 is _not_ the same value as 1u?
Only one of those, is greater than -1.

(1u < -1)

This is ridiculous and dangerous behaviour on the part of C;

(a<b) /* True */

++a; ++b;

(a<b) /* Now false! And without any wrap or overflow */

Perhaps I'm overlooking something obvious, [...]

Aha! Never mind; I overlooked something obvious. Still,
your characterization of pointer arithmetic as "amateurish
work in the early days of C" is silly.

Bartc was talking about comparisons between unsigned and signed
integers, not pointer arithmetic.

(Eric, I can't think of an example of the above problem involving
pointer arithmetic. Do you have one in mind?)

Here's an example of what Bartc was talking about:

#include <stdio.h>
int main(void)
{
unsigned a = 1;
int b = -1;
printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
++a; ++b;
printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
return 0;
}

The output is:

1U < -1
2U 0

And the reason is that when the "<" operator has signed and unsigned
operands of the same rank, the signed operand is converted to the
unsigned type before the operator is applied (see "Usual arithmetic
conversions", C99 6.3.1.8), so the value -1 is converted to UINT_MAX.

Note that gcc, for example, warns about the
comparisons in my sample program:
c.c:6: warning: comparison between signed and unsigned
c.c:8: warning: comparison between signed and unsigned

The alternative would have been to convert the unsigned operand to the
signed type -- but such a conversion can yield an
implementation-defined result (or raise an implementation-defined
signal). Conversion from signed to unsigned is well defined.

Upthread, Bartc wrote:
| The correct handling would have been to have cast both into a type
| encompassing both values before comparing, or to give a warning.

(You mean convert, not cast.)

There won't necessarily be such a type. Note that the type would have
to encompass the full ranges of the types of both operands, not just
the values of the operands (which aren't known to the compiler).

As I recall, there was considerable controversy in the pre-ANSI era
between "value-preserving" and "signedness-preserving" conversions.
Some compilers, did it one way, some did it the other way. Both
approaches have problems, and the committee had to choose one or the
other. Probably the fact that unsigned-to-signed conversion is
implementation-defined was a large part of what motivated their
decision.

Another possibility might have been to disallow such comparisons, so
that if you want to compare a signed value to an unsigned value you
have to convert one of them explicitly. That might actually have been
less confusing.

Or they could have required the operators to be further "overloaded"
at the language level so that these:
u < i
i < u
i < i
u < u
actually invoke four different operations rather than just two. The
same would have had to be done for most other operators, and the
result would have been a substantial burden on compiler writers (how
would you actually implement a long long vs. unsigned long long
comparison?) for some fairly unusual cases.

The best workaround is to avoid such comparisons in your own code. If
you find yourself comparing a signed quantity to an unsigned quantity,
it's likely (but by no means certain) that they both simply should
have been of the same type in the first place.

--
Keith Thompson (The_Other_Keith) ks***@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"

[Eric Sosman]

Keith Thompson wrote:

Eric Sosman <es*****@ieee-dot-org.invalidwrites:

>Eric Sosman wrote:

>>Bartc wrote:
"pete" <pf*****@mindspring.comwrote in message
news:Tq******************************@earthlink .com...
Peter Nilsson wrote:
>
>So 1 is _not_ the same value as 1u?
Only one of those, is greater than -1.
>
(1u < -1)
This is ridiculous and dangerous behaviour on the part of C;

(a<b) /* True */

++a; ++b;

(a<b) /* Now false! And without any wrap or overflow */
Perhaps I'm overlooking something obvious, [...]

Aha! Never mind; I overlooked something obvious. Still,
your characterization of pointer arithmetic as "amateurish
work in the early days of C" is silly.

Bartc was talking about comparisons between unsigned and signed
integers, not pointer arithmetic.

(Eric, I can't think of an example of the above problem involving
pointer arithmetic. Do you have one in mind?)

Here's an example of what Bartc was talking about:

#include <stdio.h>
int main(void)
{
unsigned a = 1;
int b = -1;
printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
++a; ++b;
printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
return 0;
}

I'd have thought that "without any wrap" would have
ruled this one out, since the conversion of -1 to unsigned
involves what I'd call a "wrap."

For the pointer example, see my reply to vippstar in
this thread. (And I see Bartc's replied to that reply
confirming your understanding. I still don't understand
why he doesn't think there's a "wrap" in (unsigned)-1,
though.)

--
Er*********@sun.com

[Eric Sosman]

Bartc wrote:

[...]
I was merely talking about the (1u<-1) above:

#include <stdio.h>

int main(void)
{
unsigned int a=1;
signed int b=-1;

if (a<b) printf("A<B\n"); else printf("A>=B\n");

++a;
++b;

if (a<b) printf("A<B\n"); else printf("A>=B\n");

}

The increment changes 1 to 2, and -1 to 0, nothing dramatic.

But you said (in snippage that occurred a few messages
ago) that the example was "without any wrap or overflow."
Surely there's a "wrap" in the conversion of -1 to UINT_MAX?

The problem seems to me that comparing unsigned to signed (by I think
treating both as unsigned) seems a little dangerous.

Yes, it can be dangerous, and some compilers warn about it.
But what would you have instead? Make the attempted comparison
a compile-time error? The tactic of "widen *both* operands"
isn't always available, as for example when comparing intmax_t
to uintmax_t (by definition, the widest integers in the West).

--
Er*********@sun.com

[Bartc]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

Eric Sosman <es*****@ieee-dot-org.invalidwrites:

>Eric Sosman wrote:

>>Bartc wrote:
"pete" <pf*****@mindspring.comwrote in message
news:Tq******************************@earthlink .com...
Peter Nilsson wrote:
>
>So 1 is _not_ the same value as 1u?
Only one of those, is greater than -1.
>
(1u < -1)

This is ridiculous and dangerous behaviour on the part of C;

(a<b) /* True */

++a; ++b;

(a<b) /* Now false! And without any wrap or overflow */
Perhaps I'm overlooking something obvious, [...]

Here's an example of what Bartc was talking about:

#include <stdio.h>
int main(void)
{
unsigned a = 1;
int b = -1;
printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
++a; ++b;
printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
return 0;
}

The output is:

1U < -1
2U 0

And the reason is that when the "<" operator has signed and unsigned
operands of the same rank, the signed operand is converted to the
unsigned type before the operator is applied (see "Usual arithmetic
conversions", C99 6.3.1.8), so the value -1 is converted to UINT_MAX.

Note that gcc, for example, warns about the
comparisons in my sample program:
c.c:6: warning: comparison between signed and unsigned
c.c:8: warning: comparison between signed and unsigned

I did try (obviously not too hard) to get a warning from gcc; it needs
something more than -Wall I think.

>
The alternative would have been to convert the unsigned operand to the
signed type -- but such a conversion can yield an
implementation-defined result (or raise an implementation-defined
signal). Conversion from signed to unsigned is well defined.

Upthread, Bartc wrote:
| The correct handling would have been to have cast both into a type
| encompassing both values before comparing, or to give a warning.

(You mean convert, not cast.)

What's the difference? I thought conversions between any numeric types were
all casts.

--
Bartc

[Bartc]

"Eric Sosman" <Er*********@sun.comwrote in message
news:1211562368.634431@news1nwk...

Bartc wrote:

>[...]
I was merely talking about the (1u<-1) above:

#include <stdio.h>

int main(void)
{
unsigned int a=1;
signed int b=-1;

if (a<b) printf("A<B\n"); else printf("A>=B\n");

++a;
++b;

if (a<b) printf("A<B\n"); else printf("A>=B\n");

}

The increment changes 1 to 2, and -1 to 0, nothing dramatic.

But you said (in snippage that occurred a few messages
ago) that the example was "without any wrap or overflow."
Surely there's a "wrap" in the conversion of -1 to UINT_MAX?

That was here:

"(a<b) /* True */
++a; ++b;
(a<b) /* Now false! And without any wrap or overflow */"

I meant with no wrap/overflow occuring in the increment operations, because
they are still working well within their limits at that point.

>Yes, it can be dangerous, and some compilers warn about it.
But what would you have instead? Make the attempted comparison
a compile-time error?

I said that having A<B but (A+1)>=(B+1), without "+" exceeding any numeric
limits, was ridiculous. I think it still is. But not much can be done about
it now, except to be aware of it or to avoid the problem by not mixing
signed/unsigned.

--
bartc

[Keith Thompson]

Eric Sosman <Er*********@sun.comwrites:

Bartc wrote:

>[...]
I was merely talking about the (1u<-1) above:
#include <stdio.h>
int main(void)
{
unsigned int a=1;
signed int b=-1;
if (a<b) printf("A<B\n"); else printf("A>=B\n");
++a;
++b;
if (a<b) printf("A<B\n"); else printf("A>=B\n");
}
The increment changes 1 to 2, and -1 to 0, nothing dramatic.

But you said (in snippage that occurred a few messages
ago) that the example was "without any wrap or overflow."
Surely there's a "wrap" in the conversion of -1 to UINT_MAX?

>The problem seems to me that comparing unsigned to signed (by I
think treating both as unsigned) seems a little dangerous.

Yes, it can be dangerous, and some compilers warn about it.
But what would you have instead? Make the attempted comparison
a compile-time error? The tactic of "widen *both* operands"
isn't always available, as for example when comparing intmax_t
to uintmax_t (by definition, the widest integers in the West).

I can't speak for Bartc, but yes, in my opinion making such a
comparison a constraint violation would have avoided confusion. In
the rare cases where you want to compare an unsigned value to a signed
value, it's not clear how the comparison should be done, except on a
case-by-case basis. Given a requirement to define it *somehow*, I
have no problem with the decision made by the standard committee, but
forcing programmers to make the conversion explicit could have avoided
a great deal of confusion. (It probably would also have broken a
great deal of pre-ANSI code, but at least it wouldn't have done so
quietly.)

--
Keith Thompson (The_Other_Keith) ks***@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"

[Keith Thompson]

Eric Sosman <Er*********@sun.comwrites:

Keith Thompson wrote:

[...]

>Bartc was talking about comparisons between unsigned and signed
integers, not pointer arithmetic.
(Eric, I can't think of an example of the above problem involving
pointer arithmetic. Do you have one in mind?)
Here's an example of what Bartc was talking about:
#include <stdio.h>
int main(void)
{
unsigned a = 1;
int b = -1;
printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
++a; ++b;
printf("%uU %c %d\n", a, a < b ? '<' : '>', b);
return 0;
}

I'd have thought that "without any wrap" would have
ruled this one out, since the conversion of -1 to unsigned
involves what I'd call a "wrap."

For the pointer example, see my reply to vippstar in
this thread. (And I see Bartc's replied to that reply
confirming your understanding. I still don't understand
why he doesn't think there's a "wrap" in (unsigned)-1,
though.)

I think his point is that there's no wrap in incrementing a and b, and
yet these non-wrapping increments changed the "<" relationship between
them. It is a bit counterintuitive, even though there are good
underlying reasons for the behavior.

--
Keith Thompson (The_Other_Keith) ks***@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"

[Keith Thompson]

"Bartc" <[e-mail]:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

[...]

>(You mean convert, not cast.)

What's the difference? I thought conversions between any numeric types were
all casts.

Nope.

A conversion is an operation that translates a value of one type to
another type.

A cast is an operator that explicitly specifies a conversion.

Some conversions are specified by cast operators; some are implicit.
There's no such thing as an "implicit cast".

--
Keith Thompson (The_Other_Keith) ks***@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"

[Chris Torek]

>>candide said:

>>I try to find out what exactly means "an array and
its address are the same"

The meaning is fuzzy, because -- even after correcting this to "the
value of an array" (or "the result of the `decay' of an array" or
however you want to express the idea of computing &array[0]) --
the types differ.

In article <e9**********************************@y18g2000pre. googlegroups.com>
Peter Nilsson <ai***@acay.com.auwrote:

>What about (void *) &array == (void *) &array[0]?

What about it? Consider:

#include <stdio.h>

int main(void) {
int equal;

equal = (int)3.1 == (int)3.2;
printf("%d %s %d\n", (int)3.1, equal ? "==" : "!=", (int)3.2);
return 0;
}

When compiled and run, this prints "3 == 3". And of course, three
*is* equal to three. That means 3.1 must be equal to 3.2, right? :-)

The fundamental problem here is that we are comparing values of
different types, and to do that, we have to start by picking some
"common" type, convert both values to that common type, and then
compare the result. Each conversion *could* -- in this case, does
-- change the value in some subtle or not-so-subtle way. (On a
Lisp machine, changes may be fairly subtle, as they can involve
changing the type-tag bits without changing the rest of the
value-representation bits.)

When we compare the modified values, we can tell whether the modified
values are equal. Alas, we cannot tell whether this is because
the modification changed the values in the process. The only way
to find out is to observe the modification, which Standard C tells
us not to do. (We can do it anyway, by stepping outside the bounds
of Standard C, but then all we can say for certain is that *this*
implementation does whatever we just observed. Another implementation,
or even this one after it is modified someday in the future, need
not do the same thing.)

Sometimes, knowing what "this implementation" does is sufficient.
Quite often, knowing what "this implementation, that implementation,
and those 27 other implementations" do is sufficient. But none of
them tell us what *every* implementation, past or future, will
*have* to do. The "every implementation, past or future" is the
domain of the Standard (though even then, the Standard may do a
lousy job of that, since a future Standard could change things).

>Can you then tell me what the standard means when
it says...

"The range of nonnegative values of a signed
integer type is a subrange of the corresponding
unsigned integer type, and the representation
of the same value in each type is the same."
^^^^^^^^^^

Either 'same value' is independant of type, or
above line makes no sense. Which is it?

You will have to ask the people who wrote the text of the Standard,
but I think this is a matter of slightly-sloppy phrasing.

We *do* know (from the Standard) that <type,valuepairs have
"representations": bit-patterns in what are, or at least look like,
binary, stored in memory, that we can take apart one "unsigned
char" at a time by doing:

T some_variable = some_value;
unsigned char *cp = &some_variable;
char *sep = "";
for (size_t i = 0; i < sizeof some_variable; i++) {
printf("%s%#x", sep, cp[i]);
sep = " ";
}
putchar('\n');

which is likely to print things like:

0xc 0x40 0 0x01

for some value(s) of some type(s). The Standard does not promise
that there is a single unique representation for every value
(floating-point values in particular may see situations where
several different representations all mean the same "value",
especially for zero), but the phrase you have quoted above
tells us that for *integral* types (char, short, int, long,
long long, and their signed and unsigned variants), *nonnegative*
values in a signed type have a single representation, and it is
the same representation as the same value of an unsigned type.

More specifically, then:

#include <limits.h>
#include <stdio.h>

void print_the_representation(unsigned char *cp, size_t size, char *s) {
size_t i;
char *sep = "";

/* assumes CHAR_BIT is 8 (if not, still works but output is ugly) */
for (i = 0; i < size; i++)
printf("%s%2.2x", sep, cp[i]);
printf("%s", s);
}

int main(void) {
short s;
unsigned short us;

for (s = 0; s < SHRT_MAX;) {
s++; /* so that range is [1..SHRT_MAX] inclusive */
print_the_representation((unsigned char *)&s, sizeof s, ", ");

us = s;
print_the_representation((unsigned char *)&us, sizeof us, "\n");
}
return 0;
}

Compile and run this program, and observe that the output is pairs
of comma-separated words, where each word is a hexadecimal expression
of the representations of "short" and "unsigned short" values in
the range [1..SHRT_MAX]. The Standard tells us that each word in
each such pair of words is identical.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: gmail (figure it out) http://web.torek.net/torek/index.html

[Keith Thompson]

Yevgen Muntyan <mu*****@removethis.tamu.eduwrites:

Richard Heathfield wrote:

>Peter Nilsson said:

[...]

>>Can you then tell me what the standard means when
it says...

"The range of nonnegative values of a signed
integer type is a subrange of the corresponding
unsigned integer type, and the representation
of the same value in each type is the same."
^^^^^^^^^^

It means that the Standard isn't as picky about its use of the word "value"
as it should be. :-)

It is picky all right. 1 and 1u have the same value,
the real number 1. 6.3.1 quite agrees with it, and
there is no reason to think otherwise. Quoted text
says so, by the way.

How do you reconcile this with the standard's definition of "value" in
C99 3.17?

value

precise meaning of the contents of an object *when interpreted as
having a specific type*

(emphasis added).

--
Keith Thompson (The_Other_Keith) ks***@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"

[ymuntyan]

On May 23, 1:46 pm, Keith Thompson <[e-mail]:

Yevgen Muntyan <[e-mail]:

Richard Heathfield wrote:

Peter Nilsson said:

[...]

>Can you then tell me what the standard means when
it says...

> "The range of nonnegative values of a signed
integer type is a subrange of the corresponding
unsigned integer type, and the representation
of the same value in each type is the same."
^^^^^^^^^^

It means that the Standard isn't as picky about its use of the word "value"
as it should be. :-)

It is picky all right. 1 and 1u have the same value,
the real number 1. 6.3.1 quite agrees with it, and
there is no reason to think otherwise. Quoted text
says so, by the way.

How do you reconcile this with the standard's definition of "value" in
C99 3.17?

value

precise meaning of the contents of an object *when interpreted as
having a specific type*

(emphasis added).

I don't see a contradiction here. Consider a block of memory allocated
by malloc(), it is an object. It doesn't have a value; but it will
have
a value if you treat it as an object of particular type.

int *foo = calloc (sizeof(int), 1);
int a = /* the value is 0 here */ *foo;

The emphasized text is talking about that - raw bunch of bytes
(that is, an object) does not have a value. And a value is what
you get when you mix a type in. Note that above object may
as well be interpreted as an array of two shorts or an array
of four chars or some structure or whatever, you get different
values in those cases.

Yevgen

[jameskuyper]

Keith Thompson wrote:

Yevgen Muntyan <mu*****@removethis.tamu.eduwrites:

....

It is picky all right. 1 and 1u have the same value,
the real number 1. 6.3.1 quite agrees with it, and
there is no reason to think otherwise. Quoted text
says so, by the way.

How do you reconcile this with the standard's definition of "value" in
C99 3.17?

value

precise meaning of the contents of an object *when interpreted as
having a specific type*

The emphasized phrase merely implies that the relationship between the
contents of an object and the meaning of those contents depends upon
the type. A certain bit pattern, when interpreted as an unsigned char,
has a meaning that is the numerical value three. A very different and
much longer bit pattern, when interpreted as a long double _Complex,
also has the same meaning. Therefore, those two objects have the same
value, since their meaning is the same.

I've heard it claimed that the mathematical value of 3, considered as
an integer, is different from that of 3+0i, considered as a complex
number. I don't see that. As I understand it, in both cases, 3 is just
mathematical shorthand for 1+1+1, where 1 is defined as the identity
element under multiplication; a definition that fits 3 just as well as
3.0+0.0i.

Note: The standard's definition of 'value' is clearly inapplicable to
the value of an expression, because there is no corresponding object.

[ymuntyan]

On May 23, 3:07 pm, [e-mail] wrote:

Keith Thompson wrote:

Yevgen Muntyan <[e-mail]:

...

It is picky all right. 1 and 1u have the same value,
the real number 1. 6.3.1 quite agrees with it, and
there is no reason to think otherwise. Quoted text
says so, by the way.

How do you reconcile this with the standard's definition of "value" in
C99 3.17?

value

precise meaning of the contents of an object *when interpreted as
having a specific type*

[snip]

>
Note: The standard's definition of 'value' is clearly inapplicable to
the value of an expression, because there is no corresponding object.

Doesn't it use language like "as if there was an object"? Like,
when there is an expression "1", it behaves as if that was an
int object with value of 1, and so on. Or isn't it at least the
very idea of "value of an expression"? (I.e. the definition is
clearly inapplicable as is, but is also clearly applicable after
*trivial* adjustment).

[jameskuyper]

[e-mail] wrote:

On May 23, 3:07 pm, [e-mail] wrote:

Keith Thompson wrote:

Yevgen Muntyan <[e-mail]:

...

It is picky all right. 1 and 1u have the same value,
the real number 1. 6.3.1 quite agrees with it, and
there is no reason to think otherwise. Quoted text
says so, by the way.

How do you reconcile this with the standard's definition of "value" in
C99 3.17?

value

precise meaning of the contents of an object *when interpreted as
having a specific type*

[snip]

Note: The standard's definition of 'value' is clearly inapplicable to
the value of an expression, because there is no corresponding object.

Doesn't it use language like "as if there was an object"?

No. It uses precisely the language given above. No more. No less.

Expressions are defined as "a sequence of operators and operands that
specifies computation of a value, or that designates an object or a
function, or that generates side effects, or that performs a
combination thereof." (6.5p1) There's nothing in that definition to
define the value computed "as if there was an object".

Incidentally, that definition has similar deficiencies. It doesn't
cover literal expressions like 3 or 256.3 or 'a', because without an
operator, literals are not operands. It has also been argued that the
use of the plural forms in that definition imply that something which
contains only one operator or only one operand doesn't qualify -
however, I think that's taking it a little too far. Luckily, the
standard also contains a grammar. From that grammer, it's clear that
the term "expression" was meant to correspond to the grammatical
construct of that same name as defined in 6.5.17p1. That construct
covers everything that we think of as a expression; it's clearly the
case that the definition in 6.5p1 was intended to match the
grammatical construct, and that conflicts between the grammar and that
definition should be resolved in favor of the grammar.

There's no corresponding help available for the concept of 'value'.

Like,

when there is an expression "1", it behaves as if that was an
int object with value of 1, and so on. Or isn't it at least the
very idea of "value of an expression"? (I.e. the definition is
clearly inapplicable as is, but is also clearly applicable after
*trivial* adjustment).

I have a pretty good idea of what I think "value" should (and does)
mean in the context of the C standard, though I'm not sure how to
express it in unambiguous standardese. The fact that objects can be
used to represent values plays no part in that concept, and I think it
was a mistake for the C standard to use the concept of an object in
it's definition of a 'value'. It's like defining a nation in terms of
the fact that nations can be represented by flags. If there's no flag,
is there no nation? If there's no object, is there no value? I think
that both questions have the same answer.

[ymuntyan]

On May 23, 4:31 pm, [e-mail] wrote:

[e-mail] wrote:

On May 23, 3:07 pm, [e-mail] wrote:

Keith Thompson wrote:
Yevgen Muntyan <[e-mail]:
...
It is picky all right. 1 and 1u have the same value,
the real number 1. 6.3.1 quite agrees with it, and
there is no reason to think otherwise. Quoted text
says so, by the way.

How do you reconcile this with the standard's definition of "value" in
C99 3.17?

value

precise meaning of the contents of an object *when interpreted as
having a specific type*

[snip]

Note: The standard's definition of 'value' is clearly inapplicable to
the value of an expression, because there is no corresponding object.

Doesn't it use language like "as if there was an object"?

No. It uses precisely the language given above. No more. No less.

Expressions are defined as "a sequence of operators and operands that
specifies computation of a value, or that designates an object or a
function, or that generates side effects, or that performs a
combination thereof." (6.5p1) There's nothing in that definition to
define the value computed "as if there was an object".

Incidentally, that definition has similar deficiencies. It doesn't
cover literal expressions like 3 or 256.3 or 'a', because without an
operator, literals are not operands. It has also been argued that the
use of the plural forms in that definition imply that something which
contains only one operator or only one operand doesn't qualify -
however, I think that's taking it a little too far. Luckily, the
standard also contains a grammar. From that grammer, it's clear that
the term "expression" was meant to correspond to the grammatical
construct of that same name as defined in 6.5.17p1. That construct
covers everything that we think of as a expression; it's clearly the
case that the definition in 6.5p1 was intended to match the
grammatical construct, and that conflicts between the grammar and that
definition should be resolved in favor of the grammar.

There's no corresponding help available for the concept of 'value'.

Like,

when there is an expression "1", it behaves as if that was an
int object with value of 1, and so on. Or isn't it at least the
very idea of "value of an expression"? (I.e. the definition is
clearly inapplicable as is, but is also clearly applicable after
*trivial* adjustment).

I have a pretty good idea of what I think "value" should (and does)
mean in the context of the C standard, though I'm not sure how to
express it in unambiguous standardese. The fact that objects can be
used to represent values plays no part in that concept, and I think it
was a mistake for the C standard to use the concept of an object in
it's definition of a 'value'. It's like defining a nation in terms of
the fact that nations can be represented by flags. If there's no flag,
is there no nation? If there's no object, is there no value? I think
that both questions have the same answer.

What I asked was if it describes what *expressions* mean using
objects,
e.g. that "1 + 1" means the same as if it was
"int tmp_obj = 1; int tmp_obj2 = 1; tmp_obj + tmp_obj2".
No idea why, but I'm used to think of complex expressions that
way, objects are easier to deal with than no-objects or something
like that. I do see now the standard uses combinations of values
and types, no objects involved (in cases like '2 + 2' of course,
when no objects are involved).

Values clearly exist without objects (if you can say "exist"
about a property), expressions have values. No idea if "zero"
exists alone, but it's not something I'd care about :)

Yevgen

[Keith Thompson]

ym******@gmail.com writes:

On May 23, 1:46 pm, Keith Thompson <[e-mail]:

>Yevgen Muntyan <[e-mail]:

Richard Heathfield wrote:
Peter Nilsson said:

[...]

>>Can you then tell me what the standard means when
it says...

>> "The range of nonnegative values of a signed
integer type is a subrange of the corresponding
unsigned integer type, and the representation
of the same value in each type is the same."
^^^^^^^^^^

>It means that the Standard isn't as picky about its use of the
word "value" as it should be. :-)

It is picky all right. 1 and 1u have the same value,
the real number 1. 6.3.1 quite agrees with it, and
there is no reason to think otherwise. Quoted text
says so, by the way.

How do you reconcile this with the standard's definition of "value" in
C99 3.17?

value

precise meaning of the contents of an object *when interpreted as
having a specific type*

(emphasis added).

I don't see a contradiction here. Consider a block of memory
allocated by malloc(), it is an object. It doesn't have a value; but
it will have a value if you treat it as an object of particular
type.

int *foo = calloc (sizeof(int), 1);
int a = /* the value is 0 here */ *foo;

Right.

The emphasized text is talking about that - raw bunch of bytes
(that is, an object) does not have a value. And a value is what
you get when you mix a type in. Note that above object may
as well be interpreted as an array of two shorts or an array
of four chars or some structure or whatever, you get different
values in those cases.

Agreed.

But the question is whether the expressions 1 and 1u have the same
"value". Since the standard defines "value" in terms of "object",
it's not as helpful in answering that question as I'd like it to be.
But a reasonable extension of the standard's definition of "value"
would, I think, preserve the idea that a value's *type* is part of its
identity. This implies that 1 and 1u have different values because
they have different types (even though they have the same, um,
"numerical value").

Consider this:

int zero = 0;
void *null_ptr = 0;

Do zero and 0 have the same value? (I'd say yes.)
Do 0 and null_ptr have the same value? (Hmm.)
Do zero and null_ptr have the same value? (Certainly not.)

Also, consider that the way C determines whether two values are the
same is with the "==" operator. That operator cannot directly compare
1 and 1u; it must convert one of the operands to the other's type
first. (This isn't my strongest argument; for example, structs have
values but they can't be compared with "==".)

In general, I think that if you want to say whether values of
differing types are "the same", you first have to convert them to a
common type.

On the other hand, saying that 1 and 1u have the same value, even if
it's not strictly correct, can be a convenient shorthand.

--
Keith Thompson (The_Other_Keith) ks***@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"

[Keith Thompson]

ym******@gmail.com writes:
[...]

What I asked was if it describes what *expressions* mean using
objects,

It doesn't. (Well, one could argue that the use of the word "value"
in the definition of "expression", combined with the fact that the
definition of "value" depends on having an object, could imply that,
but I'm 99% sure that wasn't the intent.)

For example, given the expression
42
there's no implication that there needs to be an object to hold the
value of the expression.

--
Keith Thompson (The_Other_Keith) ks***@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"

[CBFalconer]

Bartc wrote:

>

.... snip ...

>
I was merely talking about the (1u<-1) above:

#include <stdio.h>

int main(void) {
unsigned int a=1;
signed int b=-1;

if (a < b) printf("A<B\n"); else printf("A>=B\n");

Just look at what is going on in the (a < b) conditional
evaluation. The system loads a, and says "aha, I have an unsigned
value. What am I comparing it to?". It then loads b, and says
"aha, a signed value. I can't compare these. So I have to modify
one, and the only one that is modificable to the other type is the
int. So take its unsigned value".

If b is positive, that last will not alter its value. However if
negative the rules for unsigned conversion force the addition of
U_MAX until the object comes within range, resulting in a value of
U_MAX - 1. At this point the compiler heaves a sigh of relief,
says the operands are of the same type, and it can do an unsigned
compare. Guess what: (U_MAX - 1) is found to be larger than 1.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Bartc wrote:

>>

... snip ...

>>
I was merely talking about the (1u<-1) above:

#include <stdio.h>

int main(void) {
unsigned int a=1;
signed int b=-1;

if (a < b) printf("A<B\n"); else printf("A>=B\n");

Just look at what is going on in the (a < b) conditional
evaluation. The system loads a, and says "aha, I have an unsigned
value. What am I comparing it to?". It then loads b, and says
"aha, a signed value. I can't compare these. So I have to modify
one, and the only one that is modificable to the other type is the
int. So take its unsigned value".

Let me expand on your "the only one that is modificable to the other
type is the int". Either *type* can be converted to the other. For
either conversion, there's a possibility that the numeric value of the
converted operand cannot be represented in the target type.

The standard *could* have specified that the unsigned operand is
converted to signed int, but the committe decided to convert from
signed to unsigned, probably at least in part because the result of
that conversion isn't implementation-defined.

If b is positive, that last will not alter its value. However if
negative the rules for unsigned conversion force the addition of
U_MAX until the object comes within range, resulting in a value of
U_MAX - 1. At this point the compiler heaves a sigh of relief,
says the operands are of the same type, and it can do an unsigned
compare. Guess what: (U_MAX - 1) is found to be larger than 1.

--
Keith Thompson (The_Other_Keith) ks***@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"

[ymuntyan]

On May 23, 6:05*pm, Keith Thompson <[e-mail]:

[e-mail] writes:

On May 23, 1:46 pm, Keith Thompson <[e-mail]:

Yevgen Muntyan <[e-mail]:
Richard Heathfield wrote:
Peter Nilsson said:
[...]
Can you then tell me what the standard means when
it says...

>* "The range of nonnegative values of a signed
* integer type is a subrange of the corresponding
* unsigned integer type, and the representation
* of the same value in each type is the same."
* * * * *^^^^^^^^^^

It means that the Standard isn't as picky about its use of the
word "value" as it should be. :-)

It is picky all right. 1 and 1u have the same value,
the real number 1. 6.3.1 quite agrees with it, and
there is no reason to think otherwise. Quoted text
says so, by the way.

How do you reconcile this with the standard's definition of "value" in
C99 3.17?

* * value

* * precise meaning of the contents of an object *when interpreted as
* * having a specific type*

(emphasis added).

I don't see a contradiction here. Consider a block of memory
allocated by malloc(), it is an object. It doesn't have a value; but
it will have a value if you treat it as an object of particular
type.

int *foo = calloc (sizeof(int), 1);
int a = /* the value is 0 here */ *foo;

Right.

The emphasized text is talking about that - raw bunch of bytes
(that is, an object) does not have a value. And a value is what
you get when you mix a type in. Note that above object may
as well be interpreted as an array of two shorts or an array
of four chars or some structure or whatever, you get different
values in those cases.

Agreed.

But the question is whether the expressions 1 and 1u have the same
"value". *Since the standard defines "value" in terms of "object",

No it doesn't, that's the thing. It defines value *of object*, it
doesn't define the human language term "value". I.e. it defines
what it means for a C object to have value 1, not what value 1
is.

it's not as helpful in answering that question as I'd like it to be.
But a reasonable extension of the standard's definition of "value"
would, I think, preserve the idea that a value's *type* is part of its
identity. *This implies that 1 and 1u have different values because
they have different types (even though they have the same, um,
"numerical value").

Numerical value *is* the value.

>
Consider this:

* * int zero = 0;
* * void *null_ptr = 0;

Do zero and 0 have the same value? * * * * (I'd say yes.)

Yes.

Do 0 and null_ptr have the same value? * * (Hmm.)

No.

Do zero and null_ptr have the same value? *(Certainly not.)

No.

0 is an integer constant, it has value 0. zero is a variable
of type int, with value 0. null_ptr is a pointer variable,
with value "null pointer". (For nuts, zero is an identifier
designating an object of type int with value 0, etc)

>
Also, consider that the way C determines whether two values are the
same is with the "==" operator. *That operator cannot directly compare
1 and 1u; it must convert one of the operands to the other's type
first.

Right, it's how operators work. How does it imply or does not
imply that 1 and 1u have different values? The have the same
values simply because they do, the value "real number 1".

>*(This isn't my strongest argument; for example, structs have
values but they can't be compared with "==".)

In general, I think that if you want to say whether values of
differing types are "the same", you first have to convert them to a
common type.

But this common type is not necessarily a C type. For numbers,
this common type is "some set of complex numbers together with
some set of special values, nans and infinities". One is one,
regardless of what type is the object.

>
On the other hand, saying that 1 and 1u have the same value, even if
it's not strictly correct, can be a convenient shorthand.

And so it is strictly correct. The value is "real number 1".
Or what's the value of 1 and what's the value of 1u?

Yevgen

[Keith Thompson]

ym******@gmail.com writes:

On May 23, 6:05*pm, Keith Thompson <[e-mail]:

[...]

>But the question is whether the expressions 1 and 1u have the same
"value". *Since the standard defines "value" in terms of "object",

No it doesn't, that's the thing. It defines value *of object*, it
doesn't define the human language term "value". I.e. it defines
what it means for a C object to have value 1, not what value 1
is.

I disagree. C99 3.17 is the standard's definition of the word "value":

value
precise meaning of the contents of an object when interpreted as
having a specific type

This isn't a definition of the phrase "value of an object", it's a
definition of the word "value". (And the flaw in that definition is
that it doesn't define the value of an expression.)

>it's not as helpful in answering that question as I'd like it to be.
But a reasonable extension of the standard's definition of "value"
would, I think, preserve the idea that a value's *type* is part of its
identity. *This implies that 1 and 1u have different values because
they have different types (even though they have the same, um,
"numerical value").

Numerical value *is* the value.

My reasoning is that, since the value of an object makes sense only in
terms of that object's type, it's reasonable to assume that the value
of an expression also makes sense only in terms of that expression's
type. 3 and 3.0 are two very different things.

[...]

>In general, I think that if you want to say whether values of
differing types are "the same", you first have to convert them to a
common type.

But this common type is not necessarily a C type. For numbers,
this common type is "some set of complex numbers together with
some set of special values, nans and infinities". One is one,
regardless of what type is the object.

Again, I disagree. 1 and 1.0 are very different things. They're not
the *same* value, they're numerically equivalent values. At least
that's the way I think of it.

>On the other hand, saying that 1 and 1u have the same value, even if
it's not strictly correct, can be a convenient shorthand.

And so it is strictly correct. The value is "real number 1".
Or what's the value of 1 and what's the value of 1u?

The most concise way to express their values in C is 1 and 1u, but of
course that's not very illuminating. I'd say that their values are
(1 of type int) and (1 of type unsigned int).

On the other hand, I think one could have a consistent description of
the language in which the value of an expression doesn't depend on its
type, or, more precisely, that the type is not a component of the
value. In other words, that the value of an arithmetic expression
*is* the numeric value of the expression. But I think you'd still
have to say that two *objects* of distinct types have distinct values,
given the standard's definition of the word "value". I just think
that a model in which a value depends on its type is more consistent
with the wording and intent of the standard. But since the standard
doesn't say what it means for two values to be "the same", that's not
the only possible model.

--
Keith Thompson (The_Other_Keith) ks***@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"

[ymuntyan]

On May 24, 3:05*am, Keith Thompson <[e-mail]:

[e-mail] writes:

On May 23, 6:05*pm, Keith Thompson <[e-mail]:

[...]

But the question is whether the expressions 1 and 1u have the same
"value". *Since the standard defines "value" in terms of "object",

No it doesn't, that's the thing. It defines value *of object*, it
doesn't define the human language term "value". I.e. it defines
what it means for a C object to have value 1, not what value 1
is.

I disagree. C99 3.17 is the standard's definition of the word "value":

* * value
* * precise meaning of the contents of an object when interpreted as
* * having a specific type

This isn't a definition of the phrase "value of an object", it's a
definition of the word "value". *(And the flaw in that definition is
that it doesn't define the value of an expression.)

By this reasoning, the standard also defines the word "access",
is this correct? I think not, the standard defines what access
to an object means. Same thing with value, it does not define
what word "value" means, it defines what "value" means when applied
to a C object. I can't prove it, nor can you disprove it, but my
version makes most of the standard logical, so I'll stick to it.
Example: what does "sum of operands" mean? Math defines sum for
numbers, not for C entities. Is addition undefined in the C standard?

Yevgen

[Keith Thompson]

ym******@gmail.com writes:

On May 24, 3:05*am, Keith Thompson <[e-mail]:

>[e-mail] writes:

On May 23, 6:05*pm, Keith Thompson <[e-mail]:

[...]

>But the question is whether the expressions 1 and 1u have the same
"value". *Since the standard defines "value" in terms of "object",

No it doesn't, that's the thing. It defines value *of object*, it
doesn't define the human language term "value". I.e. it defines
what it means for a C object to have value 1, not what value 1
is.

I disagree. C99 3.17 is the standard's definition of the word "value":

* * value
* * precise meaning of the contents of an object when interpreted as
* * having a specific type

This isn't a definition of the phrase "value of an object", it's a
definition of the word "value". *(And the flaw in that definition is
that it doesn't define the value of an expression.)

By this reasoning, the standard also defines the word "access",
is this correct? I think not, the standard defines what access
to an object means.

Here's the definition (C99 3.1):

access

(execution-time action) to read or modify the value of an object

I don't see a problem with that. I haven't done a complete search,
but I don't think the standard talks about "accessing" expressions as
opposed to objects. If it did, it would need to define what it means
to "access" an expression (as it fails to do for the "value" of an
expression).

Same thing with value, it does not define
what word "value" means, it defines what "value" means when applied
to a C object. I can't prove it, nor can you disprove it, but my
version makes most of the standard logical, so I'll stick to it.
Example: what does "sum of operands" mean? Math defines sum for
numbers, not for C entities. Is addition undefined in the C standard?

The C standard is an odd mix of formality and informality. In places,
technical terms are given specific definitions, but many of those
definitions are incomplete. In other places, plain informal English
is used rather than the more strictly defined technical terms, or
shortcuts are taken to avoid having to double or triple the size of
the text. In *most* such cases, a reasonably friendly reading works
(i.e., interpreting the text under the assumption that it's intended
to express something sensible, rather than an absolutely literal
interpretation). In this particular case, I think it's sufficiently
obvious what "sum of the operands" means, namely the sum of the
numeric values of the two expressions, interpreted as the appropriate
type.

Personally, I'd be happier if the standard were somewhat more formal
than it is; YMMV. At the very least, I'd like all the definitions to
be exhaustive and correct, so that a literal reading doesn't tell us
that 42 is an lvalue, or that it isn't an expression.

--
Keith Thompson (The_Other_Keith) ks***@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"

[Yevgen Muntyan]

Keith Thompson wrote:

ym******@gmail.com writes:

>On May 24, 3:05 am, Keith Thompson <[e-mail]:

>>[e-mail] writes:
On May 23, 6:05 pm, Keith Thompson <[e-mail]:
[...]
But the question is whether the expressions 1 and 1u have the same
"value". Since the standard defines "value" in terms of "object",
No it doesn't, that's the thing. It defines value *of object*, it
doesn't define the human language term "value". I.e. it defines
what it means for a C object to have value 1, not what value 1
is.
I disagree. C99 3.17 is the standard's definition of the word "value":

value
precise meaning of the contents of an object when interpreted as
having a specific type

This isn't a definition of the phrase "value of an object", it's a
definition of the word "value". (And the flaw in that definition is
that it doesn't define the value of an expression.)

By this reasoning, the standard also defines the word "access",
is this correct? I think not, the standard defines what access
to an object means.

Here's the definition (C99 3.1):

access

(execution-time action) to read or modify the value of an object

I don't see a problem with that. I haven't done a complete search,
but I don't think the standard talks about "accessing" expressions

It does talk about accessing other things. Are expressions
special somehow? I only meant that the definition in bold
in that section doesn't mean that every use of the *word*
refers to that definition. So, if it defines the word
"access", how can you understand every use of this word?
There are uses where the definition doesn't make sense
(naturally). (Acrobat reader has this nifty feature by
the way, text search)

as
opposed to objects. If it did, it would need to define what it means
to "access" an expression (as it fails to do for the "value" of an
expression).

It doesn't fail to do that, it simply doesn't have to.
"Value" is a primary term. Value of an expression, number
1.2. *Value of object* *has* to be defined because an object
doesn't have a type, it doesn't make sense to talk about
a value of a region of storage. It's funny but true, if you
have a declaration

int a = 5;

then the value of the object designated by a isn't 5, there
is no value at all, unless you look at the type. On the other
hand, "5" has a type (int) and a value (5).

>

> Same thing with value, it does not define
what word "value" means, it defines what "value" means when applied
to a C object. I can't prove it, nor can you disprove it, but my
version makes most of the standard logical, so I'll stick to it.
Example: what does "sum of operands" mean? Math defines sum for
numbers, not for C entities. Is addition undefined in the C standard?

The C standard is an odd mix of formality and informality. In places,
technical terms are given specific definitions, but many of those
definitions are incomplete. In other places, plain informal English
is used rather than the more strictly defined technical terms, or
shortcuts are taken to avoid having to double or triple the size of
the text. In *most* such cases, a reasonably friendly reading works
(i.e., interpreting the text under the assumption that it's intended
to express something sensible, rather than an absolutely literal
interpretation). In this particular case, I think it's sufficiently
obvious what "sum of the operands" means, namely the sum of the
numeric values of the two expressions, interpreted as the appropriate
type.

So you choose to use obvious interpretation in this case, yet
you think that most of the occurrences of the word "value" in
the standard is wrong?

Oh well, just one more thing in the standard to argue about.
I do understand your point of view, I think, and I can't prove
that it's wrong. It's wrong of course, but I can't quote the
standard to prove that :)

Yevgen