Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[expr.call]p1 Use a more idiomatic way to specify the expression has undefined behavior #898

Merged
merged 1 commit into from Nov 12, 2016

Conversation

AaronBallman
Copy link
Contributor

I find the phrasing to be a little weird to just say "is undefined" and think it's nominally more clear to state that the behavior of the call is what's undefined.

@Eelis
Copy link
Contributor

Eelis commented Aug 11, 2016

Makes sense to me. There's another one here: http://eel.is/c++draft/util.dynamic.safety#10

"Hence indirection through a pointer located there is undefined if the object it points to was created by global operator new and not previously declared reachable."

@AaronBallman
Copy link
Contributor Author

If the editors like this direction, I can do a more thorough pass through the standard and correct them all at once in a "big" patch. Or, I can correct them with individual patches.

@Eelis
Copy link
Contributor

Eelis commented Aug 11, 2016

I'm no editor, but I think that's a great idea, because there's also dubious stuff like (for valarray::min(), http://eel.is/c++draft/valarray.members#6):

The value returned for an array of length 0 is undefined.

This makes it sound like the undefinedness could be confined to the return value itself (so that other behavior would still be defined), but in reality, this is full-blown undefined behavior (libstd++ just gives an assertion failure). :)

@AlisdairM
Copy link
Contributor

Again, not an editor :)

Looking at 1.9p4 [intro.exection] we see that operations may be described as undefined, and the original wording is consistent with that form of specification. If you want to make a pass for more consistent usage of the term, I would start there - and make sure the standard remains consistent with that approach (so we don't editorially break something).

It seems like a lot of work, and I am only mildly in favor (but still in favor of you doing the work, not opposed ;))

@Eelis
Copy link
Contributor

Eelis commented Aug 11, 2016

Yeah, I see a lot of "the effect is undefined", and that seems fine. But "the value is undefined" sounds different to me.

@AaronBallman
Copy link
Contributor Author

Alisdair, you bring up a good point about 1.9p4 that kind of deflates this particular change. However, I still find the wording to be kind of obtuse, whereas "results in undefined behavior" is a bit easier to intuit for [expr.call], IMO.

I'll let the editors make the call -- if they like the new wording, great, and if they don't, feel free to close the pull request. :-)

@tkoeppe
Copy link
Contributor

tkoeppe commented Sep 25, 2016

@zygoloid: What do you think of Aaron's suggestion of a general wording review regarding how we say that the behaviour is undefined?

@zygoloid
Copy link
Member

This change is good. If a general wording review would find more like this, that'd be nice too!

@zygoloid zygoloid merged commit 0f15558 into cplusplus:master Nov 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants