Footguns
Footguns
Posted Jul 17, 2021 16:09 UTC (Sat) by khim (subscriber, #9252)In reply to: Footguns by mrugiero
Parent article: Rust for Linux redux
> You realloc something, your chunk of memory is not the same from the POV of your application.
Why is not not the same? On the contrary: it is the same. I have verified that.
> I'm talking about the high level in the quoted part.And I'm talking about explicit mention about the possibility of in pointer being the same as out pointer. Why is it there? What can one do with that information? How can I use it?
I assume that standard writers weren't insane and haven't been adding some notes just to make standard bigger and more complex. So what's the reason to include that note as part of the interface?
> My understanding of your claim was precisely that the standard said something about the lines even tho the numeric value (emphasis in numeric) may be the same, the pointers were not equal.But these are just wet dreams of C/C++ compiler developers. Right now standard doesn't allow for the possibility of two pointers being equal and comparable and yet them being different.
One concession which standard did in C11 was to declare some pointer comparisons as being UB (e.g. you are not supposed to compare one-past-the-end-pointer to “normal” pointer… that comparison is UB).
> Just admit you're making an exception for performance, there's nothing in the semantics of realloc that make you think somehow it becomes "one past the end of the array".Except to claim this they would need to show at least one real-world example where it have improved performance. So far nothing was shown thus we may safely assume all that code was added specifically to break otherwise good programs and there are no other reason.
Posted Jul 18, 2021 3:32 UTC (Sun)
by mrugiero (guest, #153040)
[Link] (2 responses)
> And I'm talking about explicit mention about the possibility of in pointer being the same as out pointer. Why is it there? What can one do with that information? How can I use it?
> But these are just wet dreams of C/C++ compiler developers. Right now standard doesn't allow for the possibility of two pointers being equal and comparable and yet them being different.
> One concession which standard did in C11 was to declare some pointer comparisons as being UB (e.g. you are not supposed to compare one-past-the-end-pointer to “normal” pointer… that comparison is UB).
> Except to claim this they would need to show at least one real-world example where it have improved performance. So far nothing was shown thus we may safely assume all that code was added specifically to break otherwise good programs and there are no other reason.
Sorry for answering everything even when I'm just acknowledging I agree with you now that I understand better what you say. It just seemed rude not to.
Posted Jul 19, 2021 16:55 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
> For a start, because for your application they don't (usually) have the same size.
????
Not particularly elegant programming, but it's quite possible that a programmer (a) knows how much space he needs but (b) does not know how much space he's got. So he does a realloc for "safety's sake". The data portion of a linked list, for example. If the majority of your data elements are the same size that could easily result in a lot of reallocs of the same size.
(If I want to throw away the current value in the list, and replace it with a new one, a safety realloc is much quicker than parsing the value to find out whether I need to realloc ...)
Cheers,
Posted Jul 19, 2021 17:38 UTC (Mon)
by khim (subscriber, #9252)
[Link]
Nope. It was only added in C11. And that was done sloppily: main body of text still says that says that
“pointers are equal only if they point to the same object but since one-past-the-end pointer doesn't point to any object it may be identical to the other pointer which points to actual object”… then footnote (added in C11 only) turns that logic on it's ear and says “hey, but you are not supposed to compare pointer which doesn't point to anything to another pointer which points to something”. I think you are confused about different place where standard says about pointers ordering. Indeed, pointer arithmetic and < or > pointer comparisons are only defined for pointers which point to the elements of the same array, but equality/unequality couldn't work like that or else you would make many complex data structures (like Linus list with root node instead of nullptr) invalid. Actually, if you think about it, C89 definition contradicts even MS-DOS memory model where 0x0040:0x0000 and 0x0000:0x0400 pointers point to the exact same memory yet are not identical (but then MS-DOS compilers included
Footguns
For a start, because for your application they don't (usually) have the same size.
> I assume that standard writers weren't insane and haven't been adding some notes just to make standard bigger and more complex. So what's the reason to include that note as part of the interface?
Again, because that allows runtime writers to reduce the cost of calling realloc, that's why it's mentioned. But you're right in that clang breaks this rule, I think I mentioned it in the quoted comment.
Yep, I got that.
I always thought that was there for C89 already. The more you know.
Indeed. But saying that is already an improvement compared to just intentionally misinterpreting the standard. At least it's a lie that the infinite sea of possibilities makes impossible to really disprove.
Regarding intention, I addressed in a different comment that there's a lot of other possibilities that can explain bad decisions.
Footguns
Wol
> I always thought that was there for C89 already. The more you know.
Footguns
huge memory model where they were conformant and other memory models were easily understood by programmers even if they were not 100% C89 conformant).