- Is this undefined behavior? - 3 Updates
- DCAS-atomic - 1 Update
| Ian Collins <ian-news@hotmail.com>: Jun 20 11:42AM +1200 On 20/06/2020 09:08, Öö Tiib wrote: > is not different in any way. Abstracting away is not for to lose > awareness about what is going on but for to lose pointless need to > address every of well-known details explicitly. There be trolls. -- Ian. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 20 01:02AM -0400 On 6/19/20 6:02 PM, Alf P. Steinbach wrote: ... > * C++ permission to implement an iterative function as recursive. I agree that C++, like C, gives implementations permission to convert an iterative function into an equivalent recursive one. But "equivalent" is the key word here. If the C++ standard requires that the original code has certain observable behavior, the converted code must meet that same requirement. > are undesired), I'm very unhappy about the lunacy in the standard that > formally permits this last point, that the /compiler/ is permitted to > /introduce/ undefined behavior. I have no idea what in the world you're referring to. Whether or not the behavior is undefined is determined entirely by the source code. What the consequences are when the behavior is undefined is entirely up to the implementation. In what context do you believe that the standard permits an implementation to take code that does not have undefined behavior, and do something (and please identify what that something is) that makes the behavior undefined? > wants and still be formally correct. Of course, that possibility is also > there by just silently omitting to blink the NumLock indicator, as a > diagnostic about language extension, An implementation is required to document how diagnostics can be identified as such. Would you voluntarily use a compiler whose documentation specifies that method for identifying a diagnostic? >> seem to live in the early 90's. > I don't think /any/ C coders believe they know the exact kind of machine > code, ... People who believe that falsehood post regularly to comp.lang.c, usually complaining about the failure of their expectations to be met by a particular compiler. People who believe the corresponding falsehood about C++ post right here, regularly. > ... except that possibly the C standard requires source code loops to > be machine code loops. No, it imposes no such requirement. Like C++, the only requirements are imposed on the observable behavior - there's no requirements on how that behavior is achieved. > usage in the source code is not translated to O(n) resource usage in the > machine code. I don't know if C does, indeed I suspect it's as lunatic > as C++ here, but it would be really nice if one could rely on C. The C standard absolutely positively fails to impose any performance requirements on the generated code. That's entirely a matter of QoI. An implementation that generates code for "int main(void) {}" which takes 2 billion years to execute could still be fully conforming, so long as, during those 2 billion years, it produces exactly the required observable behavior (in this case, none). It would be hard to convince anybody to use such a compiler - but that's what QoI is about. C++ actually does slightly better: many templates call functions provided by the user (usually member functions of classes provided as template type arguments), and many of those templates have requirements on how many calls to those functions will occur. However, it still fails to impose any requirements on how long those calls actually take. Even when the standard requires that an operation take O(1) time, such as std::forward_list::splice_after() (26.3.9.6p8), a fully conforming implementation of the standard library could still take 2 billion years to execute that function - so long as it takes approximately the same amount of time regardless of how many items there are in the list. |
| Manfred <noname@add.invalid>: Jun 20 05:50PM +0200 On 6/20/2020 7:02 AM, James Kuyper wrote: > the key word here. If the C++ standard requires that the original code > has certain observable behavior, the converted code must meet that same > requirement. I am no expert on this point, rather I am curious: does the standard say something explicit (if so, a pointer would be appreciated) about converting iterations into a recursive function, or is this "permission" merely based on the lack of prohibition under the umbrella of the "as if" rule? >> /introduce/ undefined behavior. > I have no idea what in the world you're referring to. Whether or not the > behavior is undefined is determined entirely by the source code. The way I see it, the point is that a recursive function has different requirements and may be more demanding in terms of resources (not just time) than iterative ones, so the source code may have well defined behavior in the iterative form, but run into UB in the recursive form due to resource exhaustion. What > permits an implementation to take code that does not have undefined > behavior, and do something (and please identify what that something is) > that makes the behavior undefined? [...] > during those 2 billion years, it produces exactly the required > observable behavior (in this case, none). It would be hard to convince > anybody to use such a compiler - but that's what QoI is about. Alf mentioned resource usage, not just time. In this case running out of stack space is a typical risk to be managed, which does not apply to iterative loops. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 19 07:09PM -0700 On 6/19/2020 2:55 PM, Chris M. Thomasson wrote: >> You're talking stupid stuff. > Wrong! For instance, if RCU was forced to execute a full memory barrier > for every operation, it would basically be useless. Algorithm A that uses membars all over the place, vs Algorithm B that uses them in the right strategic places, and can eliminate them altogether in the read side, well DEC ALpha aside for a moment. Just enough to make it correct. Humm... |
| 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