meeting minutes by michael

On Wed, Apr 17, 2019 at 8:42 AM Michael Wong <fraggamuffin_at_[hidden]> wrote:

> Sorry I need to add Niall's paper to the Pointer providence discussion. I
> have already linked to Hal's paper and Paul McKenney's paper.
>
> On Wed, Apr 17, 2019 at 8:38 AM Michael Wong <fraggamuffin_at_[hidden]>
> wrote:
>
>> Hi we are switching to Zoom instead of Webex for our SG14 meetings.
>> Please let me know if there are additional agenda items.
>>
>> Michael Wong is inviting you to a scheduled Zoom meeting.
>>
>> Topic: SG14 Low Latency Monthly
>> Join URL: https://iso.zoom.us/j/406503386
>> Time: Apr 17, 2019 2:00 PM Eastern Time (US and Canada)
>> Apr 17, 2019 2:00 PM
>> May 8, 2019 2:00 PM
>> Jun 12, 2019 2:00 PM
>> Jul 10, 2019 2:00 PM
>> Aug 14, 2019 2:00 PM
>> Sep 11, 2019 2:00 PM
>> Oct 9, 2019 2:00 PM
>> Please download and import the following iCalendar (.ics) files to
>> your calendar system.
>> Monthly:
>> https://iso.zoom.us/meeting/406503386/ics?icsToken=8d46c9bf03730dd553cc4f9306ceedfc45867014725c0aca989cb39d9602ae7c
>>
>> Join from PC, Mac, Linux, iOS or Android: https://iso.zoom.us/j/406503386
>>
>> Or iPhone one-tap :
>> US: +16468769923,,406503386# or +16699006833,,406503386#
>> Or Telephone:
>> Dial(for higher quality, dial a number based on your current
>> location):
>> US: +1 646 876 9923 or +1 669 900 6833 or +1 408 638 0968 or
>> 877 369 0926 (Toll Free) or 877 853 5247 (Toll Free)
>> Meeting ID: 406 503 386
>> International numbers available: https://zoom.us/u/abhaIjFKLZ
>>
>> Or Skype for Business (Lync):
>> https://iso.zoom.us/skype/406503386
>>
>>
>> Agenda:
>>
>> 1. Opening and introductions
>>
>> 1.1 Roll call of participants
>>
> Guy Davidson, Jan Wilmans, Ben Craig, Niall , Andreas Fertig, Steven
Varga, Grafik Robot (Rene Rivera
), Michael Wong, Andreas Weis, Hubert Tong, Maged Michael, Paul McKenney,
Staffan TJ, Jens Maurer, John Macfarlane, Charles Bay

>
>> 1.2 Adopt agenda
>>
>>
>> Yes

> 1.3 Approve minutes from previous meeting, and approve publishing
>> previously approved minutes to ISOCPP.org
>>
> Yes

> 1.4 Action items from previous meetings
>>
>> 2. Main issues (125 min)
>>
>> 2.1 General logistics
>>
>> Review last call discussions.
>>
>> CPPCON SG14 meeting is now up for attendance

>
>> 2.2 Paper reviews
>> 2.2.1 Embedded/freestanding vs hosted Summary of freestanding evening
>> session discussions
>> http://wiki.edg.com/bin/view/Wg21kona2019/SG14FreestandingImplementations
>>
>>
we did do polls on library stuff, added EWG, LWG, outside of SG14 SG1
1. add library feature to FS subset that dont use troublesome: 11/11/5/0/1
2. same as 1 but adds eh: 3/12/7/4/1
strongly against was chandler: concerned about being able to ship a
compiler that does not have a std library, and relies on an external vendor
for std library
have a lowest module that have the interestign bits that requires compiler
knowledge,
What part of proposal is inhibiting Chandler? he wants to ship FS impl with
little as possible and have others layer the hosted part on top
if we add stringview and std sort then it adds a lot on implementation, its
not libC++ that is providing it, he should provide a product that is
partial or non conforming and let the user adds what ever is still needed

what about method on classes that throws, e.g. std array at, array makes a
lot of sense in FS, but at throws if out of range

lot of neutrals on this poll
Make calls to potentially-throwing library functions ill-formed.
(7/6/10/1/2)dont provide std array at
Make the library turn throw statements into abort (for example, by
preprocessor), as is common practice in no exception builds. (1/7/7/6/5)
today we terminate and going away from that is not realistic, Ben may have
a way through this with some std weasel wording, nonrmative: in a program
with no catch statement, it is untectable diff between callign std
terminate and throwing an exception and your impl does not unwind the stack
when an uncaught exception is thrown i.e. if you have no exception mode,
then just call terminate because program has no catch statement
Make the library turn throw statements into terminate (for example, by
preprocessor). (1/5/14/2/4)
Make the exception handling strategy implementation defined. (0/5/10/6/2)

future progress: on std library got go head to push it along for C++23
every meeting I had to update the paper, like a giant merge conflict
so split P0829 into multiple small papers

updating our editorial technique so other papers in flight can ride along
also touch on feature testing macros

core language side: have exception as the most important but most
contentious
will discuss next month
teh size cost of eh
return value is smaller costs
by Belfast, plan for an exception runtime paper to show happy paths to
start providing more paper
operator new and delete a paper on that through ewg, this seems one of the
easier one to accept
this will say dont require allocating form of op new and delete, you can
provide your own just like you can today
by default they are not required to be there


Herb and I talked at ACCU, he advises taht we we get what agreement we can
in SG14 where SG14 is in full agreement, then go to EWG with SG14 blessing.
but first makes sure we can get SG14 agreement first.

JM likes the split exception idea making a case indistinguishable if there
is no catch clause
make code with throw statements compilable, but make it no different
AW: yes when std library throws eh, what is semantics, then semantics does
not change,
upshot is you can compile these libraries
BC: must meet same requirement as on hosted implementations, so in those
mode they would provide an array at

HT: that latter point of doing no unwinding unless you find a handler, if
you have a binary distributed mode, of yoru library and it does throw, any
stack unwinding that may happen in the library will be enough to kill this.
For those impl if they want to stay conforming, then they dont provide at,
or dont unwind
so there is still burden for implementor imvestigation

I know GCC documents throwing with no catch does not unwind stack, clang
might unwind

JW: this could force them to all do it the same way
could be whether they use libunwnd or libgcc_eh
or it could be the type info is not properly encoded when they have
noexcept fn calling something that is noexcept code





Outcome from Dec call:
>> In the SG14 session, he mentioned 2 that he prefers
>> * Freestanding is signal / interrupt safe
>> * Freestanding requires no special dispensation from the operating
>> environment above what freestanding C99 requires
>>
>> But there are other possible directions
>> * Freestanding should be as small as possible
>> * Freestanding has all the same core language features as hosted
>>
>> Nov Evening Session:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1376r0.html
>>
>>
>> 2.2.2 Pointer Provedence:
>>
>> Pointer Provenance. I know this is a WG14 paper. But there is now
>> interest in following this with a WG21 paper.
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2369.pdf
>> <https://www.google.com/url?q=http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2369.pdf&sa=D&source=hangouts&ust=1555590655253000&usg=AFQjCNEA6AjXuTUdhbL8PtTJyYfBGcrhzQ>
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1434r0.html
>>
>>
>> https://dedi5.nedprod.com/static/files/other/Dxxxx%20draft%202%20-%20Enhanced%20C%2B%2B%20memory%20and%20object%20model.pdf
>>
>> push from cambridge, peter Sewell's team trying to formalize C MM
mathematically
Chandler opposed
SG12 did more work work with C, Han did most of the liasion,
also was at Euro LLVM, this is Niall's interpretation
if object;'s lifetime, all conforming impl may have all pointers pointing
at that object invalid
if you new an item using placement new, then reuse that address, previous
pointers are invalid, new pointers to the new object is valid
these 2 ptrs can potentially equal, and this can cause problems
the rationale behind std launder which can point to an area to tell
lifetime is not what the compiler expects

C is now bringing this into their standard
hopefully get reconcilliation between the 2
compare equal and substitute one for the other are 2 different things

zap pointer life time
are they bitwise identical if pointed to the same object

N2369:
History on why we set it this way
What does C say,
best you can say is that if someone free a ptr, compiler is within its
right to cause indeterminate all copies of that pointer in the program no
matter where they are, cant load, compare or deref or touch the bits

difference in C++ lifetime (object lifetime) and storage duration (what
paul is talkign about)

What is the difference with C++?

If you free obj, all copies will be inderterminate, or at best have a trap
rep, cant load, store, or deref
this has been since C99, been there for a long time

for concurrent programming , this is too restrictive

Use after free bugs
have the free fn invalidate the pointer, std says you can do that, useful
for diagnotics
enables some optimizations,
if compiler can see ptr has it lifetime ending, then can kill one of the
branch, just use the else clause
Also future hardware can also traps on the load

ptr becoming indeterminate when obj lifetime ends in C (when you use
storage free and when stackframe dies),, can we have a motivating use case
for that

LIFO is old since 1973
classic algo push stuff on the stack
then atomically pop things off the stack and operate on it
set the next ptr, if we fail then try again
as soon as we load the value on the stack, this can become indeterminate

list_pop_all, get old value, just before excahnage, might get top of stack
and then we delay
we sequence through the stack, capture next ptr, calls foo on it
now copies of p and all ptrs to it become indeterminate
after p
sets p to next
as long as you dont mind having work done in reverse order, all you want to
compare the pointer

This should not work in C++, but some implementations might make it work

Niall says only trap derefernce then this algo will work fine

if you have additional pointer indirection, it could work, but will not
scale and invalidate decades of concurrent algo

if you coincidentally retrieve the same address, so spec use this death
trap to prevent impl from creating new memory, otherwise stack's won't work

Niall: I vaguely remember somebody on WG14 has a C compiler implementing
the trapping pointer thing. I thought it only traps dereference though, so
basically it's the same as setting all pointers to end of lifetimed objects
to null (though they don't do that)
In fact, the guy explained it that pointers get set to something like NaN,
so a non-bit-equal trap value

HT: if you compare ptrs, have to chaneg what compare means, between addr of
old and new object, for this to work to what people want, then have to
change spec to say what you want,
needto change definition of equality, if one or more ptr is to a lifetime
end of object, then it would have to be ok, to give a false positive
equality comparison
might not be a problem for C++

Niall:I thought the comparison of pointers of differing provenance is in
the proposed new C memory model? So, specifically, pointer to alive never
compares equal to pointer to dead?

Please post to Wg14 and C++ parallel mailing list

No one objects to moving forward with some intermediate solution that is
not the status quo for C.

Move forward for C++: because invalid ptr value is the same case for C++,
C++ says its implementation defined
to have it reliably work, then we need to do this, so we can do more with
invalid ptr values

Possibly the same wording, equality compare offer false positive, introduce
the idea of address space and say invalid ptr value just represents an
address
its ok to say they are not equal when they are

make this work for distinct source code, there is push back
existing source code using these algo needs to continue to work, because
our civilization depends on it
if impl change in a place where behaviour is undefined, then change would
only affect use cases in that category

we can check the behaviour of implementations

Jens M: I've been told multiple times that (equality) comparisons are not
in scope of the "provenance" papers.

2 ptrs that compare equal mght be same type, but in C++, can placement new
replace object in same storage,
ptr to old object, ptr to new object, same type, they will compare bitwise
identical
but those pointers are not interchangeable, because the object is not there
any more,
this is why storage duration and lifetime, is more distinct in C++ then C

so const member can have different values on these things, old ptr can
retain old value, but might see the new value as well

stack auto variable can return null

if you are happy to split difference between stack vs heap, this is the
solution based on storage duration
this might invaldate some algorithms but we dont know what those are













2.2.3 Linear Algebra update from April 3rd
>> http://lists.isocpp.org/sg14/2019/04/0076.php
>>
>> Next call: May 1 3 PM ET
>>
>> 2.2.4: Any serious study on cost of Exception vs cost of Error Codes
>>
>>
>> 2.2.5 any other proposal for reviews?
>>
>>
>> 2.3 Domain-specific discussions
>>
>> 2.3.1 Embedded domain discussions: Ben Craig, Wooter and Odin Holmes
>> 2.3.3 Games Domain: John McFarlane, Guy Davidson and Paul Hampson
>> 2.3.4 Finance Domain: Carl Cooke, Neal Horlock, Mateusz Pusz and Clay
>> Trychta
>>
>> 2.4 Other Papers and proposals
>>
>>
>> 2.5 Future F2F meetings:
>>
>> 2.6 future C++ Standard meetings:
>> https://isocpp.org/std/meetings-and-participation/upcoming-meetings
>>
>> - *2019-07-15 to 20: Cologne, Germany; *Nicolai Josuttis
>> - *2019-11-04 to 09: Belfast, Northern Ireland;* Archer Yates
>> -
>> - 2020-02-10 to 15: Prague, Czech Republic
>>
>>
>> - 2020-06-01 to 06: Bulgaria
>> - 2020-11: (New York, tentative)
>> - 2021-02-22 to 27: Kona, HI, USA
>>
>> 3. Any other business
>> Reflector
>> https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!forum/sg14
>> As well as look through papers marked "SG14" in recent standards
>> committee paper mailings:
>> http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/
>> http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/
>>
>> Code and proposal Staging area
>> https://github.com/WG21-SG14/SG14
>> 4. Review
>>
>> 4.1 Review and approve resolutions and issues [e.g., changes to SG's
>> working draft]
>>
>> 4.2 Review action items (5 min)
>>
>>
>> 5. Closing process
>>
>>
>> 5.1 Establish next agenda
>>
>> May 8
>>
>>
>> 5.2 Future meeting
>> Apr 17: todays call
>> May 8
>> June 12: June 17 mailing deadline
>> July 10: likely cancelled due to Cologne Meeting July 15
>>
>>