C++ Logo


Advanced search

Re: [wg14/wg21 liaison] N2539 / P2331R0 Unsequenced functions

From: Jens Gustedt <jens.gustedt_at_[hidden]>
Date: Fri, 2 Apr 2021 12:13:40 +0200
I have now gone through your remarks and I hope that we will have a
new version, soon. Comments, also to your original mail, below.

on Thu, 25 Mar 2021 12:13:26 +0100 you (Jens Maurer <Jens.Maurer_at_[hidden]>) wrote:

> On 25/03/2021 11.12, Jens Gustedt wrote:
> >> Special-casing call_once in all of this seems to be very much a
> >> quality-of-implementation concern. Every implementation should
> >> choose whether it wants to teach its optimizer about the
> >> special "call_once" properties. (After all, this is all about
> >> optimizations, which are optional anyway.)
> >
> > I think that I don't agree completely. The text should make
> > guarantees about the data dependencies that can be induced by calls
> > to C library functions. `call_once` is one of them, and in addition
> > it has very special semantics that are relevant for the properties
> > at hand. So something should be said in one form or another.
> Ok, but maybe that's a property of this particular function
> (that should be stated near where it's specified) instead
> of something we need to talk about in the specification of the
> attributes.

We added a text to the introductory part of that clause that describes
why this exception is necessary.

> This has practical impact for C++: We "inherit" (almost) all
> of the C standard library, but none of the core language.
> So, if the relevant text for call_once goes into the
> call_once specification, chances are we'll get its properties
> "for free" into C++. (Hm... I just realized C++ doesn't
> provide <threads.h> at all, so maybe the "inheritance" argument
> doesn't apply for this particular situation.)

Yes, you don't have `call_once` because C++ has other means to
initialized static variables dynamically. So a C++ implementation
should then relate to these mechanisms and explain if (or not) they
are impacted.

> > on Thu, 25 Mar 2021 10:44:09 +0100 you (Jens Maurer via Liaison
> > <liaison_at_[hidden]>) wrote:
> >
> >> These look like possibly useful attributes for C++ as well,
> >> but the wording needs to be totally redone.
> >>
> >> First of all, these attributes assert certain facts about a
> >> function to the compiler, which possibly cannot be deduced by
> >> the compiler.
> >> This is most useful if the compiler cannot "see" the definition
> >> of the function. However, this wording contains quite a bit
> >> of text talking about "is implied", meaning that the
> >> compiler analyzes a function definition and then implicitly
> >> adds the attribute to the definition. But if the
> >> compiler can "see" the function definition, there is little
> >> need for an implied attribute in the first place, because the
> >> compiler already has all the information it can possibly infer
> >> about the function (and it might inline the call anyway).
> >>
> >> I'd like to see some explanation in the prose why the "is implied"
> >> parts of the proposal are worth having. If "is implied" goes
> >> away, the wording should be rephrased in the form of
> >> assertions that the user makes, and should give the user
> >> liberty to assert any function, without further constraints
> >> on what the function actually does.

As said, all of these fall through the cracks because WG14 didn't like
them either.

> >> ...
> >>
> >>
> >> - It would help me if the wording would show monospace font where
> >> the standard does, for example in p2 (list of attribute
> >> names) and p1 (same).

yes, that's the disadvantage of not working on the LaTeX sources
directly. I try my best for the next version

> >> ...

> >> - noleak: Any function -> All functions
> >>
> >> Why do we have to mention allocation functions explicitly? They
> >> certainly don't carry the "noleak" attribute, so the first bullet
> >> covers them nicely.

No, allocation functions only change the state of the memory system by
returning a new pointer, they have themselves no leak (hopefully). So
by the definition as presented here they could have the attribute.

> >> - noleak: p3 This appears to define the term "storage
> >> leak", but it's not used going forward. "can be deduced by the
> >> translator" seems vague at best: some compilers can deduce more
> >> than others; the specification of the standard needs to draw the
> >> line by explicitly saying what's going on.
> >>
> >> - p4 "with the exception of an allocated return value"
> >> What does that mean, exactly? When is a return value "allocated"?
> >> Also "shall be" sounds like a Constraint, not a Description.

This was probably not so well formulated. Hope this will be clearer, then.

> >> ...

> >> - p2 "are const qualified variables that may range over
> >> the whole admissible set" This feels like "value" is missing
> >> somewhere, e.g. "whose values may range over..." What's the
> >> "admissible set" of function arguments? Using const-qualified
> >> variables as function arguments doesn't do anything, because the
> >> function parameter values are copies of those arguments anyway.
> >> Also, I don't think the fact that something is const-qualified is
> >> the point here, but the fact that no writes happen (you can choose
> >> not to write to a non-const variable, too).

yes, reformulated just with values

the C Jens

:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

Received on 2021-04-02 05:13:50