«

James Kuyper wrote:
> CBFalconer wrote:
>
.... snip ...
>
>> Any such would require storage of the actual stored format, and
>> the requested format.
>
> As the result depends only upon the bits that were stored, and
> not upon the format that was used to store them, why would you
> need to store that format?

Any union can have an unlimited number of formats, and will only
occupy the space needed for the largest format. So access has to
know the format to be accessed. Conversion needs to know the
format to be converted to. QED.

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

CBFalconer <> writes:

> James Kuyper wrote:
>> CBFalconer wrote:
>>
> ... snip ...
>>
>>> Any such would require storage of the actual stored format, and
>>> the requested format.
>>
>> As the result depends only upon the bits that were stored, and
>> not upon the format that was used to store them, why would you
>> need to store that format?
>
> Any union can have an unlimited number of formats, and will only
> occupy the space needed for the largest format. So access has to
> know the format to be accessed. Conversion needs to know the
> format to be converted to. QED.

You have snipped so much all the context is lost. Are you still
thinking that the OP expected conversion rather than reinterpretation?
James was quite clear in his reply that the OP was talking about the
usual reinterpretation that happens with a union and not a conversion
from the type last stored to the type that is later accessed.

The format (as you call it) is know to the compiler when a union
member is written or read, so no format needs to be stored to
implement the reinterpretation semantics required by C.

--
Ben.

Ben Bacarisse wrote:
> CBFalconer <> writes:
>> James Kuyper wrote:
>>> CBFalconer wrote:
>>>
>> ... snip ...
>>>
>>>> Any such would require storage of the actual stored format,
>>>> and the requested format.
>>>
>>> As the result depends only upon the bits that were stored, and
>>> not upon the format that was used to store them, why would you
>>> need to store that format?
>>
>> Any union can have an unlimited number of formats, and will only
>> occupy the space needed for the largest format. So access has to
>> know the format to be accessed. Conversion needs to know the
>> format to be converted to. QED.
>
> You have snipped so much all the context is lost. Are you still
> thinking that the OP expected conversion rather than
> reinterpretation? James was quite clear in his reply that the OP
> was talking about the usual reinterpretation that happens with a
> union and not a conversion from the type last stored to the type
> that is later accessed.
>
> The format (as you call it) is know to the compiler when a union
> member is written or read, so no format needs to be stored to
> implement the reinterpretation semantics required by C.

When the bit pattern is different, what is the difference between
conversion and reinterpretation? And, while the compiler may know
when union u has format f written into it, the code that reads from
u is reading a specific format. The compiler, when generating that
code, has no idea what was last written into it.

#include <all needed>

union un {
char ch;
int i;
float d;
} u;

void setval(int val) {
switch 3 * rand() / RAND_MAX { /* returning 0 thru 2 */
case 0: u.ch = val;
case 1: u.i = val;
case 2: u.d = val;
default: puts("error");
}
}

int main(void) {
int ct = 0;

for (ct = 0; ct < 10; ct++) {
setval(ct);
printf("%c %d %f\n", u.ch, u.i, u.d);
}
return 0;
}

Please explain how the extraction code (u.i for example) knows what
conversions to apply? Please ignore silly coding errors.

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

CBFalconer <> writes:

> Ben Bacarisse wrote:
>> CBFalconer <> writes:
>>> James Kuyper wrote:
>>>> CBFalconer wrote:
>>>>
>>> ... snip ...
>>>>
>>>>> Any such would require storage of the actual stored format,
>>>>> and the requested format.
>>>>
>>>> As the result depends only upon the bits that were stored, and
>>>> not upon the format that was used to store them, why would you
>>>> need to store that format?
>>>
>>> Any union can have an unlimited number of formats, and will only
>>> occupy the space needed for the largest format. So access has to
>>> know the format to be accessed. Conversion needs to know the
>>> format to be converted to. QED.
>>
>> You have snipped so much all the context is lost. Are you still
>> thinking that the OP expected conversion rather than
>> reinterpretation? James was quite clear in his reply that the OP
>> was talking about the usual reinterpretation that happens with a
>> union and not a conversion from the type last stored to the type
>> that is later accessed.
>>
>> The format (as you call it) is know to the compiler when a union
>> member is written or read, so no format needs to be stored to
>> implement the reinterpretation semantics required by C.
>
> When the bit pattern is different, what is the difference between
> conversion and reinterpretation?

Given

union { float f; int i; } u; u.f = 66;

then u.i is reinterpretation and (int)u.f is (what I mean by)
conversion. Conversion requires knowledge of the last stored member,
reinterpretation does not. That is why I though you were talking
about conversions.

> And, while the compiler may know
> when union u has format f written into it, the code that reads from
> u is reading a specific format. The compiler, when generating that
> code, has no idea what was last written into it.

Yes, that is why the standard says that the bits are reinterpreted as
a (possibly invalid) value of the type being read. I am sure you know
this. I (and James) are just wondering what point you are making.
The OP knows the second retrieved value will be "garbage" (their word)
but they did not know the result could be an invalid (trap) value. I
don't think they ever expected a conversion to the new type to happen.

> #include <all needed>
>
> union un {
> char ch;
> int i;
> float d;
> } u;
>
> void setval(int val) {
> switch 3 * rand() / RAND_MAX { /* returning 0 thru 2 */
> case 0: u.ch = val;
> case 1: u.i = val;
> case 2: u.d = val;
> default: puts("error");
> }
> }
>
> int main(void) {
> int ct = 0;
>
> for (ct = 0; ct < 10; ct++) {
> setval(ct);
> printf("%c %d %f\n", u.ch, u.i, u.d);
> }
> return 0;
> }
>
> Please explain how the extraction code (u.i for example) knows what
> conversions to apply?

It does not. As far as I can tell, you complicated the discussion by
suggesting that someone was expecting a conversion when no one was. I
think James was just pointing out that no one expected the Span^H^H^H^H
a conversion to take place.

> Please ignore silly coding errors.

Unfortunately, one of them means that in your example, we always know
that last member written, but that is incidental to the issue.

--
Ben.

CBFalconer wrote:
> Ben Bacarisse wrote:
>> CBFalconer <> writes:
>>> James Kuyper wrote:
>>>> CBFalconer wrote:
>>>>
>>> ... snip ...
>>>>> Any such would require storage of the actual stored format,
>>>>> and the requested format.
>>>> As the result depends only upon the bits that were stored, and
>>>> not upon the format that was used to store them, why would you
>>>> need to store that format?
>>> Any union can have an unlimited number of formats, and will only
>>> occupy the space needed for the largest format. So access has to
>>> know the format to be accessed. Conversion needs to know the
>>> format to be converted to. QED.
>> You have snipped so much all the context is lost. Are you still
>> thinking that the OP expected conversion rather than
>> reinterpretation? James was quite clear in his reply that the OP
>> was talking about the usual reinterpretation that happens with a
>> union and not a conversion from the type last stored to the type
>> that is later accessed.
>>
>> The format (as you call it) is know to the compiler when a union
>> member is written or read, so no format needs to be stored to
>> implement the reinterpretation semantics required by C.
>
> When the bit pattern is different, what is the difference between
> conversion and reinterpretation?

I don't know what you're referring to when you say "the bit pattern is
different". I can tell you what the difference between conversion and
reinterpretation is. Conversion of a float value of 66.0F to an int
results in an int value of 66. Reinterpretation of bits representing a
float value of 66.0F as bits representing an int will, in general,
generate an implementation-depended result that might be a trap
representation (the key point that the OP seemed unaware of), that
depends upon the representation used for float and int, and will
generally be a number other than 66. In the OP's case, reinterpretation
led to an int result of 1115947008. The OP knew this was a plausible
outcome, and was not surprised by it. He might even know enough about
the representations used for float and int on his machine to predict
that result, though he said nothing to confirm that possibility.

> ... And, while the compiler may know
> when union u has format f written into it, the code that reads from
> u is reading a specific format. The compiler, when generating that
> code, has no idea what was last written into it.

That's correct, and the OP seemed quite well aware of that fact. If he
were not, he might have expressed surprise at getting a u.i value of
1115947008 after storing a value of 66.0 in u.f. He expressed no such
surprise, and every message you've posted since that time seems to be
based upon the misconception that he was surprised by it. Are you in
fact aware of the fact that he was not surprised by it? That he wasn't
asking why he got that result, because it was the result he expected to get?

> #include <all needed>
>
> union un {
> char ch;
> int i;
> float d;
> } u;
>
> void setval(int val) {
> switch 3 * rand() / RAND_MAX { /* returning 0 thru 2 */
> case 0: u.ch = val;
> case 1: u.i = val;
> case 2: u.d = val;
> default: puts("error");
> }
> }
>
> int main(void) {
> int ct = 0;
>
> for (ct = 0; ct < 10; ct++) {
> setval(ct);
> printf("%c %d %f\n", u.ch, u.i, u.d);
> }
> return 0;
> }
>
> Please explain how the extraction code (u.i for example) knows what
> conversions to apply? Please ignore silly coding errors.

It's not supposed to apply any conversions, so that makes the decision
easy: it just takes the bits stored in u.ch, and interprets them as a
char. It takes the bits stored in u.i, and interprets them as an int. It
takes the bits stored in u.d, and interprets them as a float. There's
not a single conversion anywhere in that process.

pete wrote:
> pete wrote:
>> CBFalconer wrote:
>>
>>> When the bit pattern is different, what is the difference between
>>> conversion and reinterpretation?
>>
>> When an int object with a value of (-1) is interpreted as unsigned,
>> then the resulting unsigned value depends on the representation of (-1).
>>
>> (-1) converted to type unsigned,
>> is always UINT_MAX and does not depend on the representation of (-1).
>
> Another way of putting that is that there is no such thing as
> reinterpretation when the bit pattern is different.

In other words, one form of conversion is the identity relation.

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

Ben Bacarisse wrote:
> CBFalconer <> writes:
>> Ben Bacarisse wrote:
>>> CBFalconer <> writes:
>>>> James Kuyper wrote:
>>>>> CBFalconer wrote:
>>>>>
>>>> ... snip ...
>>>>>
>>>>>> Any such would require storage of the actual stored format,
>>>>>> and the requested format.
>>>>>
>>>>> As the result depends only upon the bits that were stored, and
>>>>> not upon the format that was used to store them, why would you
>>>>> need to store that format?
>>>>
>>>> Any union can have an unlimited number of formats, and will only
>>>> occupy the space needed for the largest format. So access has to
>>>> know the format to be accessed. Conversion needs to know the
>>>> format to be converted to. QED.
>>>
>>> You have snipped so much all the context is lost. Are you still
>>> thinking that the OP expected conversion rather than
>>> reinterpretation? James was quite clear in his reply that the OP
>>> was talking about the usual reinterpretation that happens with a
>>> union and not a conversion from the type last stored to the type
>>> that is later accessed.
>>>
>>> The format (as you call it) is know to the compiler when a union
>>> member is written or read, so no format needs to be stored to
>>> implement the reinterpretation semantics required by C.
>>
>> When the bit pattern is different, what is the difference between
>> conversion and reinterpretation?
>
> Given
>
> union { float f; int i; } u; u.f = 66;
>
> then u.i is reinterpretation and (int)u.f is (what I mean by)
> conversion. Conversion requires knowledge of the last stored member,
> reinterpretation does not. That is why I though you were talking
> about conversions.
>
>> And, while the compiler may know
>> when union u has format f written into it, the code that reads from
>> u is reading a specific format. The compiler, when generating that
>> code, has no idea what was last written into it.
>
> Yes, that is why the standard says that the bits are reinterpreted as
> a (possibly invalid) value of the type being read. I am sure you know
> this. I (and James) are just wondering what point you are making.
> The OP knows the second retrieved value will be "garbage" (their word)
> but they did not know the result could be an invalid (trap) value. I
> don't think they ever expected a conversion to the new type to happen.

So am I (wondering) at this point.

>
>> #include <all needed>
>>
>> union un {
>> char ch;
>> int i;
>> float d;
>> } u;
>>
>> void setval(int val) {
>> switch 3 * rand() / RAND_MAX { /* returning 0 thru 2 */
>> case 0: u.ch = val;
>> case 1: u.i = val;
>> case 2: u.d = val;
>> default: puts("error");
>> }
>> }
>>
>> int main(void) {
>> int ct = 0;
>>
>> for (ct = 0; ct < 10; ct++) {
>> setval(ct);
>> printf("%c %d %f\n", u.ch, u.i, u.d);
>> }
>> return 0;
>> }
>>
>> Please explain how the extraction code (u.i for example) knows what
>> conversions to apply?
>
> It does not. As far as I can tell, you complicated the discussion by
> suggesting that someone was expecting a conversion when no one was. I
> think James was just pointing out that no one expected the Span^H^H^H^H
> a conversion to take place.
>
>> Please ignore silly coding errors.
>
> Unfortunately, one of them means that in your example, we always know
> that last member written, but that is incidental to the issue.

Oh? Are you claiming that you can back up and find the previous
value emitted by rand? I don't think that is guaranteed.

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

James Kuyper wrote:
> CBFalconer wrote:
>
.... snip ...
>
>> #include <all needed>
>>
>> union un {
>> char ch;
>> int i;
>> float d;
>> } u;
>>
>> void setval(int val) {
>> switch 3 * rand() / RAND_MAX { /* returning 0 thru 2 */
>> case 0: u.ch = val;
>> case 1: u.i = val;
>> case 2: u.d = val;
>> default: puts("error");
>> }
>> }
>>
>> int main(void) {
>> int ct = 0;
>>
>> for (ct = 0; ct < 10; ct++) {
>> setval(ct);
>> printf("%c %d %f\n", u.ch, u.i, u.d);
>> }
>> return 0;
>> }
>>
>> Please explain how the extraction code (u.i for example) knows
>> what conversions to apply? Please ignore silly coding errors.
>
> It's not supposed to apply any conversions, so that makes the
> decision easy: it just takes the bits stored in u.ch, and
> interprets them as a char. It takes the bits stored in u.i, and
> interprets them as an int. It takes the bits stored in u.d, and
> interprets them as a float. There's not a single conversion
> anywhere in that process.

As usual I have not been sufficiently specific. Imagine some sort
of cast in each printf item, possibly implemented by a routine.
i.e.:

printf("%c %d %f\n", cnvt(u.ch), cnvt(u.i), cnvt(u.d));


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

CBFalconer wrote:
> Ben Bacarisse wrote:
>> CBFalconer <> writes:

<snip>

>>> #include <all needed>
>>>
>>> union un {
>>> char ch;
>>> int i;
>>> float d;
>>> } u;
>>>
>>> void setval(int val) {
>>> switch 3 * rand() / RAND_MAX { /* returning 0 thru 2 */
>>> case 0: u.ch = val;
>>> case 1: u.i = val;
>>> case 2: u.d = val;
>>> default: puts("error");
>>> }
>>> }
>>>
>>> int main(void) {
>>> int ct = 0;
>>>
>>> for (ct = 0; ct < 10; ct++) {
>>> setval(ct);
>>> printf("%c %d %f\n", u.ch, u.i, u.d);
>>> }
>>> return 0;
>>> }

<snip>

>>> Please ignore silly coding errors.
>> Unfortunately, one of them means that in your example, we always know
>> that last member written, but that is incidental to the issue.
>
> Oh? Are you claiming that you can back up and find the previous
> value emitted by rand? I don't think that is guaranteed.

Wrong, it is guaranteed.

The description of srand includes the following which explicitly
guarantees that you can:

| The srand function uses the argument as a seed for a new sequence of
| pseudo-random numbers to be returned by subsequent calls torand. If
| srand is then called with the same seed value, the sequence of
| pseudo-random numbers shall be repeated. If rand is called before
| any calls to srand have been made, the same sequence shall be
| generated as when srand is �rst called with a seed value of 1.
--
Flash Gordon

Flash Gordon <> writes:
> CBFalconer wrote:
[...]
>> Oh? Are you claiming that you can back up and find the previous
>> value emitted by rand? I don't think that is guaranteed.
>
> Wrong, it is guaranteed.
>
> The description of srand includes the following which explicitly
> guarantees that you can:
>
> | The srand function uses the argument as a seed for a new sequence of
> | pseudo-random numbers to be returned by subsequent calls torand. If
> | srand is then called with the same seed value, the sequence of
> | pseudo-random numbers shall be repeated. If rand is called before
> | any calls to srand have been made, the same sequence shall be
> | generated as when srand is Þrst called with a seed value of 1.

Yes, that means you can recover the previous value returned by rand()
*if* you've remembered the original value passed to srand() and the
number of times rand() has been called since then. But then you might
as well just remember the previous value returned by rand().

--
Keith Thompson (The_Other_Keith) kst- <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"