Date: Thu, 27 May 2021 21:18:00 -0400
On Thu, May 27, 2021 at 8:22 PM Steve Downey <sdowney_at_[hidden]> wrote:
> IFNDR is definitely too far. I think even weak library UB is too far. The
> function behaves perfectly deterministically even though it's not the
> desired result. Mojibake is not UB. That we've improved the descriptive
> language so we can discuss "literal encoding" hasn't changed the behavior
> of anything.
>
> `sprintf` has had this behavior forever.
>
> Since the format is user extensible, I don't think any assumptions can be
> made about the result of print, or format, being well formed for any
> encoding that has well formed conditions. For the UTF-8 to UTF-16 case,
> print has to do _something_, so it might as well try to do something
> sensible.
>
Implementation defined behaviour might do the trick but may not be strong
enough to discourage users from writing code that is dependent on the
behaviour of a specific implementation at some point in time.
> In most cases, though, it should be doing nothing.
>
> On Wed, May 26, 2021 at 11:05 PM Hubert Tong via SG16 <
> sg16_at_[hidden]> wrote:
>
>> On Wed, May 26, 2021 at 5:46 PM Corentin Jabot via SG16 <
>> sg16_at_[hidden]> wrote:
>>
>>>
>>>
>>> On Wed, May 26, 2021 at 11:01 PM Peter Brett via SG16 <
>>> sg16_at_[hidden]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I prepared these 2 polls for tonight's meeting, but we did not have the
>>>> opportunity to vote on them. I hope we will be able to vote on them next
>>>> time. Please suggest alternative or additional polls that you think would
>>>> be informative!
>>>>
>>>> Peter
>>>>
>>>>
>>>> If, and only if, the literal encoding is UTF-8, <print> facilities
>>>> should assume
>>>> that their formatted results are UTF-8 text.
>>>>
>>>> SF F N A SA
>>>>
>>>> Attendance:
>>>>
>>>> Consensus:
>>>>
>>>> Author's position:
>>>>
>>>>
>>>> If a <print> facility assumes that the result of formatting is UTF-8
>>>> text, but
>>>> it is not, then the program is ill-formed, no diagnostic required.
>>>>
>>>
>>> Please make it UB
>>>
>>
>> +1
>>
>>
>>> IFNDR is really nasty and should be reserved for things that the
>>> compiler has no real control over like ODR issues.
>>>
>>
>> IFNDR can only be applied based on the source code. IFNDR cannot be
>> applied depending on user input at run-time.
>>
>>
>>>
>>> Library has wording stating that preconditions violations are UB
>>> http://eel.is/c++draft/library#structure.specifications-3.3
>>> I think having wording along the line of "Precondition: The format
>>> string is UTF-8 encoded" in the wording of vprint_unicode is the best way
>>> to achieve this intent.
>>>
>>
>> The above won't cover strings provided by the user for replacements (and
>> that's probably just the easiest case to identify).
>>
>>
>>>
>>>
>>>>
>>>> SF F N A SA
>>>>
>>>> Attendance:
>>>>
>>>> Consensus:
>>>>
>>>> Author's position:
>>>>
>>>> --
>>>> 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
>>>
>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
>
> IFNDR is definitely too far. I think even weak library UB is too far. The
> function behaves perfectly deterministically even though it's not the
> desired result. Mojibake is not UB. That we've improved the descriptive
> language so we can discuss "literal encoding" hasn't changed the behavior
> of anything.
>
> `sprintf` has had this behavior forever.
>
> Since the format is user extensible, I don't think any assumptions can be
> made about the result of print, or format, being well formed for any
> encoding that has well formed conditions. For the UTF-8 to UTF-16 case,
> print has to do _something_, so it might as well try to do something
> sensible.
>
Implementation defined behaviour might do the trick but may not be strong
enough to discourage users from writing code that is dependent on the
behaviour of a specific implementation at some point in time.
> In most cases, though, it should be doing nothing.
>
> On Wed, May 26, 2021 at 11:05 PM Hubert Tong via SG16 <
> sg16_at_[hidden]> wrote:
>
>> On Wed, May 26, 2021 at 5:46 PM Corentin Jabot via SG16 <
>> sg16_at_[hidden]> wrote:
>>
>>>
>>>
>>> On Wed, May 26, 2021 at 11:01 PM Peter Brett via SG16 <
>>> sg16_at_[hidden]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I prepared these 2 polls for tonight's meeting, but we did not have the
>>>> opportunity to vote on them. I hope we will be able to vote on them next
>>>> time. Please suggest alternative or additional polls that you think would
>>>> be informative!
>>>>
>>>> Peter
>>>>
>>>>
>>>> If, and only if, the literal encoding is UTF-8, <print> facilities
>>>> should assume
>>>> that their formatted results are UTF-8 text.
>>>>
>>>> SF F N A SA
>>>>
>>>> Attendance:
>>>>
>>>> Consensus:
>>>>
>>>> Author's position:
>>>>
>>>>
>>>> If a <print> facility assumes that the result of formatting is UTF-8
>>>> text, but
>>>> it is not, then the program is ill-formed, no diagnostic required.
>>>>
>>>
>>> Please make it UB
>>>
>>
>> +1
>>
>>
>>> IFNDR is really nasty and should be reserved for things that the
>>> compiler has no real control over like ODR issues.
>>>
>>
>> IFNDR can only be applied based on the source code. IFNDR cannot be
>> applied depending on user input at run-time.
>>
>>
>>>
>>> Library has wording stating that preconditions violations are UB
>>> http://eel.is/c++draft/library#structure.specifications-3.3
>>> I think having wording along the line of "Precondition: The format
>>> string is UTF-8 encoded" in the wording of vprint_unicode is the best way
>>> to achieve this intent.
>>>
>>
>> The above won't cover strings provided by the user for replacements (and
>> that's probably just the easiest case to identify).
>>
>>
>>>
>>>
>>>>
>>>> SF F N A SA
>>>>
>>>> Attendance:
>>>>
>>>> Consensus:
>>>>
>>>> Author's position:
>>>>
>>>> --
>>>> 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
>>>
>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
>
Received on 2021-05-27 20:18:29