Discussion:
Another thread on "and any program that depends on the side effects produced by the destructor has undefined behavior."
(too old to reply)
Brian Bi
2018-11-05 22:09:10 UTC
Permalink
OK, this question has come up before, but I haven't seen a definitive
answer yet. What do these words at the end of [basic.life]/5 actually mean?

Here's a contrived example that demonstrates what I *think* it means:

#include <memory>

struct Foo {
Foo();
~Foo();
};

std::aligned_storage_t<sizeof(Foo), alignof(Foo)> buf;
int buf_use_count = 0;

Foo::Foo() {
if (this == buf_addr) {
if (buf_use_count == 0) {
buf_use_count = 1;
} else {
// the previous object here should have been destroyed,
// therefore I'm going to throw a temper tantrum
1 / 0;
}
}
}

Foo::~Foo() {
if (this == buf_addr) {
--buf_use_count;
}
};

int main() {
Foo* foo = new (&buf) Foo;
delete foo;
foo = new (&buf) Foo; // ok
foo = new (&buf) Foo; // UB
}

This program "depends" on the false belief that a destructor will be called
on an object before any new object is constructed there. Thus, we can make
the program exhibit UB by subverting its expectations.

If this was the intent, then these words in the standard are
redundant---it's already obvious that this program has UB. However, there
have been many threads where the question of what these words mean has been
raised in passing, indicating that they are clearly confusing people, and
should be removed from the standard.

I hope we can get an "authoritative" answer on the meaning of those words
and put this confusion to rest.
--
*Brian Bi*
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Nicolas Lesser
2018-11-05 22:18:30 UTC
Permalink
Post by Brian Bi
OK, this question has come up before, but I haven't seen a definitive
answer yet. What do these words at the end of [basic.life]/5 actually mean?
#include <memory>
struct Foo {
Foo();
~Foo();
};
std::aligned_storage_t<sizeof(Foo), alignof(Foo)> buf;
int buf_use_count = 0;
Foo::Foo() {
if (this == buf_addr) {
if (buf_use_count == 0) {
buf_use_count = 1;
} else {
// the previous object here should have been destroyed,
// therefore I'm going to throw a temper tantrum
1 / 0;
}
}
}
Foo::~Foo() {
if (this == buf_addr) {
--buf_use_count;
}
};
int main() {
Foo* foo = new (&buf) Foo;
delete foo;
foo = new (&buf) Foo; // ok
foo = new (&buf) Foo; // UB
}
This program "depends" on the false belief that a destructor will be
called on an object before any new object is constructed there. Thus, we
can make the program exhibit UB by subverting its expectations.
If this was the intent, then these words in the standard are
redundant---it's already obvious that this program has UB. However, there
have been many threads where the question of what these words mean has been
raised in passing, indicating that they are clearly confusing people, and
should be removed from the standard.
I hope we can get an "authoritative" answer on the meaning of those words
and put this confusion to rest.
Nobody agrees. See https://github.com/cplusplus/draft/pull/2342

I don't know if a CWG issue has already been filed.
--
Post by Brian Bi
*Brian Bi*
--
---
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Brian Bi
2018-11-05 22:23:44 UTC
Permalink
Post by Nicolas Lesser
Nobody agrees. See https://github.com/cplusplus/draft/pull/2342
I don't know if a CWG issue has already been filed.
Is filing a CWG issue the "correct" way to get the committee to explain
their intent? I suppose it might well be, since nobody from the committee
seems to have chimed in to give an authoritative clarification so far.
--
*Brian Bi*
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Nicolas Lesser
2018-11-05 22:30:29 UTC
Permalink
Well, several committee members have commented, included one from Core
(Jens).

Yeah, that's a way. Some also hang out here. :)
Post by Brian Bi
Post by Nicolas Lesser
Nobody agrees. See https://github.com/cplusplus/draft/pull/2342
I don't know if a CWG issue has already been filed.
Is filing a CWG issue the "correct" way to get the committee to explain
their intent? I suppose it might well be, since nobody from the committee
seems to have chimed in to give an authoritative clarification so far.
--
*Brian Bi*
--
---
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Brian Bi
2018-11-05 22:32:54 UTC
Permalink
Post by Nicolas Lesser
Well, several committee members have commented, included one from Core
(Jens).
Yeah, that's a way. Some also hang out here. :)
Jens's comment makes it clear that he's also guessing like the rest of us,
but there's gotta be someone out there who actually wrote these words and
can tell us what they intended for them to mean.
--
*Brian Bi*
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Balog Pal
2018-11-06 14:26:15 UTC
Permalink
2018. november 5., hétfő 23:33:08 UTC+1 időpontban Brian Bi a következőt
Post by Brian Bi
Jens's comment makes it clear that he's also guessing like the rest of us,
but there's gotta be someone out there who actually wrote these words and
can tell us what they intended for them to mean.
No longer, the last, very recent comment suggests the board decided to go
on accepting the change as is.

It's an interesting issue, I made several circles agreeing with different
parties :-) on opposing sides. Meanwhile having a fixed point that it is
clearly an issue on the standard text that is supposed to be clear and
carry the same meaning to all readers.

Short recap of my journey:
- reading the standard text, p5 clearly states the behavior, that1: the
user is allowed to never explicitly end the object lifetime; 2: if the
destructor was not called before the release/reuse of storage, the
implementation is forbidden to make a dtor call. The very last part is
redundant at best, baffling at worst. A fit ending would be "... will fail
on its expectations." instead of UB.
- looking at the change request, it fixed this very problem in a sensible
way (though CaseyCarter's version looks even better).
- Jonathan's initial comments go orthogonal, yes we can call a program
built on false expectations incorrect. That is beyond the standard's scope.
- getting to Jens' first comment, fist I rejected it outright
- but then kept rereading and found what (IMHO) he meant there. Indeed it
can be read as "if the program relies on the behavior, then it is obliged
to call the dtor orherwise UB -- and if having a proof the implementation
can rely on it too; changing that would be more than editorial." I
also feel for the next comment on a different mandated behavior that would
clearly change a lot.
- then an extra read on Jens' comment revealed a bug: he puts the
obligation as absolute, while the text outs it under a condition "IF the
program depends".

From here I see two possibilities, either the implementation can't
interpret "depends" so this extra part is good for nothing.
Or it can, through following all the mandated behavior and allowed UB, but
in that case this text is redundant.

Then reading on I found the last msg that reflect a similar conclusion.
-
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Brian Bi
2018-11-07 05:42:22 UTC
Permalink
Post by Balog Pal
2018. november 5., hétfő 23:33:08 UTC+1 időpontban Brian Bi a következőt
Post by Brian Bi
Jens's comment makes it clear that he's also guessing like the rest of
us, but there's gotta be someone out there who actually wrote these words
and can tell us what they intended for them to mean.
No longer, the last, very recent comment suggests the board decided to go
on accepting the change as is.
good to know, thanks for pointing that out!
--
*Brian Bi*
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Itaj Sherman
2018-11-09 02:43:42 UTC
Permalink
Why is it "delete foo;" rather than "foo->~Foo();"?
Post by Brian Bi
OK, this question has come up before, but I haven't seen a definitive
answer yet. What do these words at the end of [basic.life]/5 actually mean?
#include <memory>
struct Foo {
Foo();
~Foo();
};
std::aligned_storage_t<sizeof(Foo), alignof(Foo)> buf;
int buf_use_count = 0;
Foo::Foo() {
if (this == buf_addr) {
if (buf_use_count == 0) {
buf_use_count = 1;
} else {
// the previous object here should have been destroyed,
// therefore I'm going to throw a temper tantrum
1 / 0;
}
}
}
Foo::~Foo() {
if (this == buf_addr) {
--buf_use_count;
}
};
int main() {
Foo* foo = new (&buf) Foo;
delete foo;
foo = new (&buf) Foo; // ok
foo = new (&buf) Foo; // UB
}
This program "depends" on the false belief that a destructor will be
called on an object before any new object is constructed there. Thus, we
can make the program exhibit UB by subverting its expectations.
If this was the intent, then these words in the standard are
redundant---it's already obvious that this program has UB. However, there
have been many threads where the question of what these words mean has been
raised in passing, indicating that they are clearly confusing people, and
should be removed from the standard.
I hope we can get an "authoritative" answer on the meaning of those words
and put this confusion to rest.
--
*Brian Bi*
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Brian Bi
2018-11-09 02:57:27 UTC
Permalink
that was my mistake, sorry
Post by Itaj Sherman
Why is it "delete foo;" rather than "foo->~Foo();"?
Post by Brian Bi
OK, this question has come up before, but I haven't seen a definitive
answer yet. What do these words at the end of [basic.life]/5 actually mean?
#include <memory>
struct Foo {
Foo();
~Foo();
};
std::aligned_storage_t<sizeof(Foo), alignof(Foo)> buf;
int buf_use_count = 0;
Foo::Foo() {
if (this == buf_addr) {
if (buf_use_count == 0) {
buf_use_count = 1;
} else {
// the previous object here should have been destroyed,
// therefore I'm going to throw a temper tantrum
1 / 0;
}
}
}
Foo::~Foo() {
if (this == buf_addr) {
--buf_use_count;
}
};
int main() {
Foo* foo = new (&buf) Foo;
delete foo;
foo = new (&buf) Foo; // ok
foo = new (&buf) Foo; // UB
}
This program "depends" on the false belief that a destructor will be
called on an object before any new object is constructed there. Thus, we
can make the program exhibit UB by subverting its expectations.
If this was the intent, then these words in the standard are
redundant---it's already obvious that this program has UB. However, there
have been many threads where the question of what these words mean has been
raised in passing, indicating that they are clearly confusing people, and
should be removed from the standard.
I hope we can get an "authoritative" answer on the meaning of those words
and put this confusion to rest.
--
*Brian Bi*
--
---
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.
--
*Brian Bi*
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Continue reading on narkive:
Loading...