> If you have any concerns, please share a message on the reflector.

Will do.

> And the string is critically never observed again.

The thread name is definitely observable by the user, otherwise this
facility is useless and shouldn't be standardized.

Cheers,
Victor


On Wed, Oct 9, 2024 at 12:07 PM Corentin Jabot <corentinjabot_at_[hidden]>
wrote:

>
>
> On Wed, Oct 9, 2024 at 8:50 PM Tom Honermann via SG16 <
> sg16_at_[hidden]> wrote:
>
>> On 10/9/24 9:41 AM, Victor Zverovich wrote:
>>
>> Hi Tom,
>>
>> Can we finish the review of P2019 Thread Attributes? The end of the last
>> meeting was a bit rushed because we ran out of time and I don't think we
>> even went through all the poll candidates.
>>
>> I don't mind continuing discussion on it if we have time left over today,
>> but I'll be surprised if that is the case.
>>
>> I don't have other poll candidates for P2019 at the moment, but I agree
>> that there is more to discuss. I don't think we resolved questions of
>> behavior on POSIX vs Windows platforms and I believe you raised some
>> possible concerns with the use of string_view that weren't discussed. If
>> there are other items, please let me know. I've tentatively added further
>> discussion to my list of topics for the 10/23 meeting.
>>
>
> If you have any concerns, please share a message on the reflector.
>
> But I think that there is a fundamental misunderstanding of what the
> library does.
> The string is passed to the system and the system can do absolutely
> anything with it (truncate it, ignore it, upper case it, convert it to
> ebcdic, ignore or support embedded nulls, etc) - and we cannot specify
> anything because we cannot mandate anything of POSIX or the kernel
> (I mean, we could but it would be an exercise in pointlessness as it would
> not be implementable).
>
> And the string is critically never observed again. Even if you use a
> system-specific query function (that not all platforms provide) you cannot
> guarantee round tripping because the platform may truncate (although for
> linux that would happen in the standard library), ignore the value, etc
> The only difference between windows and posix is that windows expect a
> string in UTF-16. In both cases the intent is that the string is valid text
> as the only use cases are for debuggers and system monitors to show
> that string (but then again if it isn't something somewhere will silently
> ignore such errors)
>
>
>
> Tom.
>>
>>
>> - Victor
>>
>> On Tue, Oct 8, 2024 at 2:28 PM Tom Honermann via SG16 <
>> sg16_at_[hidden]> wrote:
>>
>>> SG16 will hold a meeting *tomorrow*, Wednesday, October 9th, at 19:30
>>> UTC (timezone conversion
>>> <https://www.timeanddate.com/worldclock/converter.html?iso=20241009T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>
>>> ).
>>>
>>> The agenda follows.
>>>
>>> - P3094R3: std::basic_fixed_string <https://wg21.link/p3094r3>
>>> - P3045R1: Quantities and units library <https://wg21.link/p3045r1>
>>> - P3258R0: Formatting of charN_t <https://wg21.link/p3258r0>
>>>
>>> SG16 has not previously reviewed P3094, but did discuss a fixed_string
>>> type in the context of a predecessor paper, P2980R0 (A motivation,
>>> scope, and plan for a physical quantities and units library)
>>> <https://wg21.link/p2980r0> during its 2023-11-29 meeting
>>> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2023.md#november-29th-2023>.
>>> Since we're fairly familiar with the subject matter, so I'll ask Mateusz to
>>> provide a brief overview and we'll move on to discussion of any concerns.
>>> SG16 has not previously polled this paper or its predecessor; the LEWG
>>> chair will be looking for SG16 to bless this paper even if we don't see
>>> SG16 specific concerns to ensure this paper is ready for progress in
>>> Wrocław.
>>>
>>> SG16 reviewed previous revisions of P3045 during its 2023-11-29 meeting
>>> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2023.md#november-29th-2023>
>>> and 2024-01-24 meeting
>>> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README.md#january-24th-2024>.
>>> Previous discussion concerned which encodings to support and representation
>>> for symbols, particularly those not represented in the basic character
>>> sets. Mateusz can provide an overview of the changes and any relevant
>>> design changes that have been made. The LEWG chair will also be looking for
>>> SG16 to determine if there are any lingering SG16 concerns that would
>>> prevent this paper progressing at Wrocław.
>>>
>>> P3258R0 comes to us courtesy of Corentin and seeks to achieve what most
>>> people expect to be trivial but which we have always known to be
>>> impossible; provide formatting and I/O support for text in char*N*_t,
>>> sort of, as limited by the characters representable in the ordinary and
>>> wide literal encodings. Corentin to provide an overview and frown while the
>>> rest of us quibble about transcoding details and locale encodings and,
>>> probably, reluctantly, conclude that the behavior Corentin has proposed is
>>> how things should be.
>>>
>>> Tom.
>>> --
>>> SG16 mailing list
>>> SG16_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>>
>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
>