Thanks Michael. I was in a meeting and could not attend; these minutes are
appreciated

Le mer. 17 avr. 2019 à 15:32, Michael Wong via SG14 <sg14_at_[hidden]>
a écrit :

> 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
>>>
>>> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg14
>