- std::hexfloat - 7 Updates
| David Brown <david.brown@hesbynett.no>: May 20 09:49PM +0200 On 20/05/2019 15:52, Paavo Helde wrote: > 1.724e-43#DEN which of course gets converted to 0 in the output. > So the compiler has dutifully carried out the type punning as written, > even if it was not obliged to. What's there to complain about? You are right - sorry for the bad example. The principle is right, however - the casting here is bad code with undefined behaviour and the compiler can optimise it as it wants. (It is free, for example, to reduce "foo" to a single "ret" instruction.) And it is certainly the case that gcc and clang use type-based alias analysis to optimise code, and it is certainly the case that this happens sometimes in real life code. I've seen it cause trouble in my own code once, on a platform where "int32_t" is "long int" and therefore incompatible with "int" despite both being 32-bit. (I did not say I like these rules!). But I have to try a little harder to make a clear example: int foo(float* f, int *i) { *i = 1; *f = 0.0f; return *i; } int bar(void) { int x = 0; x = foo((float*) &x, &x); return x; } With -O2, gcc and clang generate: mov eax, 1 ret With -O1, or "-O2 -fno-strict-aliasing", they return 0. |
| David Brown <david.brown@hesbynett.no>: May 20 09:55PM +0200 On 20/05/2019 17:47, Ben Bacarisse wrote: >> behaves.) > I consider that to be allowed. There's no way that C can't specify the > result, so this is as "defined" a construct as it can. Did you mean "there's no way that C /can/ specify the result" ? If so, then that is not quite true - C99 (and C11) specify it better, even though the final result is still implementation dependent. > C does not use the term allowed and disallowed. Did you mean it would > have been better to make it undefined? If so, I disagree (but that's > hardly important). Sorry, I meant it would have been better if /I/ had said "type punning via unions is not clearly allowed by the C90 standard". I did not mean to suggest the standard should be different. (I do think the C99 wording is better, however - even if it is a clarification rather than a change.) > not have an annex listing all UB constructs with normative references. > Oh well... I don't doubt anyone's word about this, I'd just like to see > the wording. Agreed. |
| David Brown <david.brown@hesbynett.no>: May 20 09:57PM +0200 On 20/05/2019 20:20, Tim Rentsch wrote: > changed in C90, or changed between C90 and C99, such a change > surely would have been mentioned in the Rationale documents. > AFAICT there isn't any. I don't think that all the changes in C99 are covered in the rationale documents (at least, not that I have seen). However, I am happy to believe that the intended behaviour for unions has not changed between C90 and C99, and it is merely the wording that has been made clearer. |
| David Brown <david.brown@hesbynett.no>: May 20 10:01PM +0200 On 20/05/2019 21:06, Tim Rentsch wrote: <snip detailed explanation and references> > Taken together I think these passages make the case pretty > airtight. Thank you. I can see why I failed to find a simple, clear reference covering this case! |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 20 09:17PM +0100 > (7.1) -- the glvalue is used to access the object, [...] > Taken together I think these passages make the case pretty > airtight. Ah, thank you so much. I hope this did not take too long. I thought it would be the result of a number of passages but it never occurred me to to look at lifetime. -- Ben. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 20 09:21PM +0100 >> I consider that to be allowed. There's no way that C can't specify the >> result, so this is as "defined" a construct as it can. > Did you mean "there's no way that C /can/ specify the result" ? <sigh> Yes I did. Far too many of my typos negate my meaning. > If so, then that is not quite true - C99 (and C11) specify it better, > even though the final result is still implementation dependent. Sure, they are clearer in a footnote (I take it you refer to the "reinterpret the bits" footnote). Given the context (the late 80s) I don't think anyone was ever in much doubt about what the implementation defined result would be. Those were simpler times! <cut> -- Ben. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 20 09:24PM +0100 > can be stored in a union at any time." > Which would imply that reading from a non-active member is the same as > reading from an uninitialized variable. I didn't think that was quite enough, though it should have been enough to prompt me to look for some more details. As you say it implies as much as it says! Tim has very helpfully provided a thorough collection of quotes. -- Ben. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment