- Is this undefined behavior? - 2 Updates
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 18 10:47PM +0100 On Thu, 18 Jun 2020 14:26:27 -0700 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote: [snip] > compiler error. I posted about it. Will try to find the post. Thanks > again. Will have more time tonight to give you a proper response. > The error was that MSVC failed to give the original allocation size. That's a different point. MSVC's version of the delete[] expression passes operator delete[] the wrong size of memory block to be released - it doesn't comply with the standard, but they can't fix it because that would break existing code, more particularly the window kernel. Placement operations don't use the delete[] expression so that does not impinge on the issues I mentioned. |
| "Öö Tiib" <ootiib@hot.ee>: Jun 18 04:03PM -0700 On Thursday, 18 June 2020 14:41:34 UTC+3, Bo Persson wrote: > > to ever exist. > There could be an opportunity to revise this now, but why would we like > to allow new code to misbehave in ways that were not possible earlier? Can you elaborate that question more clearly? I do not understand how allowing compilers less leeway is equal with allowing new code to misbehave. By my naive logic it is directly opposite: 1) Allowing compiler to generate code that does something else instead of trying to access address null on case of null pointer dereference is potentially allowing some new black magic code to misbehave in rather spectacular ways. 2)Forcing it to generate code that attempts to access address null on case of null pointer dereference is causing the program to segfault on majority of platforms. |
| 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