P3471R4 Standard library hardening #7703

Eisenwave · 2025-02-19T13:04:07Z

Fixes #7674.
Fixes cplusplus/papers#2125.

Eisenwave · 2025-02-19T13:15:12Z

@jwakely I have had some issues when creating this PR:

The new note for [string.view.access] looks as if it had a paragraph number, but it's most likely intended to be attached to the hardened precondition paragraph. I have elected to ignore the paragraph number.
The paper deletes "Two kinds of implementations are defined" in [intro.compliance] but the library has the same sort of wording in [compliance] (library intro). How to proceed? Delete redundant wording? Mirror changes?
[structure.specifications] in the paper explains "Hardened preconditions" simply with two bullets that begin with "When". This is not how we usually do things. My suggestion would be something like "If the implementation is hardened ([intro.compliance]), ..." for the first bullet, and "Otherwise, ..." for the second bullet.
[basic.contract.eval] is a dead reference at this point. It should be resolved after merging with contracts.
It was very annoying that the paper doesn't have a wording diff that follows the structure of the standard linearly. For example, the paper first has the wording diff for 23.7.3.6.3 [mdspan.mdspan.members], and then the diff for 27.7.3.6.2 [mdspan.mdspan.cons]. The only thing this accomplishes is to bully the editor, and I'm the editor, and I feel bullied!

frederick-vs-ja · 2025-02-26T03:00:29Z

The new note for [string.view.access] looks as if it had a paragraph number, but it's most likely intended to be attached to the hardened precondition paragraph. I have elected to ignore the paragraph number.

The old note was semantically connected to the preconditions paragraph but placed in a bad (IMO) place. I guess the intent wasn't attaching the note to the paragraph, but such attaching seems to be an editorial improvement to me.

The paper deletes "Two kinds of implementations are defined" in [intro.compliance] but the library has the same sort of wording in [compliance] (library intro). How to proceed? Delete redundant wording? Mirror changes?

I think it's safest to mirror changes.

burblebee

The paper was applied correctly except for 2 missing edits, but there were other issues - see comments.

burblebee · 2025-03-05T04:50:13Z

source/intro.tex

 A freestanding
 implementation is one in which execution may take place without the benefit of


Not your doing (from existing text), but wanted to point out that this is where the \defnadj for "freestanding implementation" should be (not above) since this is the definition. Same for "hosted implementation" in the sentence below.

I think we want the defnadj to be on the first occurrence of the term.

burblebee · 2025-03-05T04:57:22Z

source/intro.tex

+It is
+\impldef{whether the implementation is a hardened implementation}
+whether the implementation is a
+\defnadj{hardened}{implementation}.


Also not your doing (from paper), but this doesn't define what a "hardened implementation" is - what is it?

It's not uncommon that we use definition italics for things that aren't really explained, but simply the first occurrence of that term. I wouldn't be opposed to some semi-normative wording that attempts to define it, but that seems outside the scope of this PR, even considering fixups.

The way it was stated in R2 was "A hardened implementation is one in which violating a hardened precondition is a contract violation." That is a bit more like an actual definition, but I don't think it's a problem the way R4 is phrased. We specify the properties of a hardened implementation, and say it's implementation-defined whether the implementation is one. That's sufficient IMHO. An impl has to say if it is or isn't one, and if it is, we say how that affects behaviour.

burblebee · 2025-03-05T05:09:48Z

source/lib-intro.tex

 \item
 \expects
-the conditions
-that the function assumes to hold whenever it is called;
+conditions that the function assumes to hold whenever it is called;
 violation of any preconditions results in undefined behavior.

+\item
+\hardexpects
+conditions that the function assumes to hold whenever it is called.


This is a problem with existing source, but also the new source since it's following the existing convention:

\clauses should always be preceded with a \pnum, not an \item, and

Sentences following each \clause should start with capital letter.

burblebee · 2025-03-05T09:35:33Z

source/lib-intro.tex

+prior to any other observable side effects of the function,
+one or more contract assertions
+whose predicates are as described in the hardened precondition
+are evaluated with a checking semantic\iref{basic.contract.eval}.


[basic.contract.eval] doesn't exist; is it being added by one of the other motions?

#7695 is adding that section.

burblebee · 2025-03-05T10:26:11Z

source/utilities.tex

@@ -9372,7 +9372,7 @@

 \begin{itemdescr}
 \pnum
-\expects
+\hardexpects


Missing 2 of these edits around line 9418 for [expected.void.obs]/p7 and line 9435 for expected.void.obs/p9.

burblebee · 2025-03-05T10:35:16Z

source/support.tex

@@ -837,6 +856,11 @@
 Freestanding implementations should only define a macro from \libheader{version}
 if the implementation provides the corresponding facility in its entirety.

+\pnum
+\recommended


Does it make sense to have 2 \recommendeds following each other like this, verses having a bulleted list under a single \recommended?

I think it would be stylistically better if there was a single paragraph, and I don't even think that bullets are required.

However, it's not really wrong, and CWG signed off on it knowing that there are two recommendations in a row, so I'm not sure if that's a fixup candidate.

P3471R4 Standard library hardening

31df2c8

burblebee requested changes Mar 5, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

P3471R4 Standard library hardening #7703

P3471R4 Standard library hardening #7703

Eisenwave commented Feb 19, 2025

Eisenwave commented Feb 19, 2025

frederick-vs-ja commented Feb 26, 2025 •

edited

Loading

burblebee left a comment

burblebee Mar 5, 2025

jwakely Mar 5, 2025

burblebee Mar 5, 2025

Eisenwave Mar 5, 2025

jwakely Mar 5, 2025

burblebee Mar 5, 2025

burblebee Mar 5, 2025

frederick-vs-ja Mar 5, 2025

burblebee Mar 5, 2025

burblebee Mar 5, 2025

Eisenwave Mar 5, 2025 •

edited

Loading

		A freestanding
		implementation is one in which execution may take place without the benefit of

P3471R4 Standard library hardening #7703

Are you sure you want to change the base?

P3471R4 Standard library hardening #7703

Conversation

Eisenwave commented Feb 19, 2025

Eisenwave commented Feb 19, 2025

frederick-vs-ja commented Feb 26, 2025 • edited Loading

burblebee left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Eisenwave Mar 5, 2025 • edited Loading

Choose a reason for hiding this comment

frederick-vs-ja commented Feb 26, 2025 •

edited

Loading

Eisenwave Mar 5, 2025 •

edited

Loading