Date: Wed, 14 Apr 2021 14:46:34 +0000
Hi Peter,
Thanks for your feedback. I’m looking forward to your counter-proposal that makes the Windows situation well-formed.
Best regards,
Peter
From: SG16 <sg16-bounces_at_[hidden]> On Behalf Of Peter Bindels via SG16
Sent: 14 April 2021 15:24
To: Corentin Jabot <corentinjabot_at_[hidden]>
Cc: Peter Bindels <peterbindels_at_[hidden]>; SG16 <sg16_at_[hidden]>
Subject: Re: [SG16] P2362R0 Make obfuscating wide character literals ill-formed
EXTERNAL MAIL
I value portable code highly. If we have known platforms, and a competing proposal that makes the Windows situation well-formed, it makes this an odd sell to me. I do not want a specification that requires code to compile on Unix and fail on Windows, even if it is not currently according to spec and somehow unportable code.
Blocking multi-character literals, sure. Blocking some single-character literals as IFDR when they work fine on other platforms, that's just not right. I don't think I like either variant - making it ill-formed on Unix, or to allow it on Unix while making it ill-formed on Windows.
On Wed, 14 Apr 2021 at 16:16, Corentin Jabot <corentinjabot_at_[hidden]<mailto:corentinjabot_at_[hidden]>> wrote:
On Wed, Apr 14, 2021 at 4:07 PM Peter Bindels <peterbindels_at_[hidden]<mailto:peterbindels_at_[hidden]>> wrote:
Then I have the inverse problem, now we create code that is conditionally portable, and only ill-formed on Windows. That's horrible.
How is that worse that code that is well-formed everywhere but does the wrong thing on windows?
wchar_t was never portable
On Wed, 14 Apr 2021 at 15:55, Corentin Jabot <corentinjabot_at_[hidden]<mailto:corentinjabot_at_[hidden]>> wrote:
On Wed, Apr 14, 2021 at 3:49 PM Peter Bindels via SG16 <sg16_at_[hidden]<mailto:sg16_at_[hidden]>> wrote:
Please explain how that facepalm is now illegal on Unix, where wchar_t is 32 bit and it clearly fits.
It's only ill-formed if it doesn't fit!
On Wed, 14 Apr 2021 at 15:27, Peter Brett via SG16 <sg16_at_[hidden]<mailto:sg16_at_[hidden]>> wrote:
Hi all,
Corentin and I have authored https://isocpp.org/files/papers/P2362R0.pdf<https://urldefense.com/v3/__https:/isocpp.org/files/papers/P2362R0.pdf__;!!EHscmS1ygiU1lA!RfZ-3ZpziALRJn_sSJwrR0gyUZRhOWjr3syeOIG6No1guMhBgIjMCHcZYaJ_cQ$>, which will be in the April mailing. This addresses https://github.com/sg16-unicode/sg16/issues/65<https://urldefense.com/v3/__https:/github.com/sg16-unicode/sg16/issues/65__;!!EHscmS1ygiU1lA!RfZ-3ZpziALRJn_sSJwrR0gyUZRhOWjr3syeOIG6No1guMhBgIjMCHcbQmBgqQ$>.
Best regards,
Peter
--
SG16 mailing list
SG16_at_lists.isocpp.org<mailto:SG16_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg16<https://urldefense.com/v3/__https:/lists.isocpp.org/mailman/listinfo.cgi/sg16__;!!EHscmS1ygiU1lA!RfZ-3ZpziALRJn_sSJwrR0gyUZRhOWjr3syeOIG6No1guMhBgIjMCHeZhljmpA$>
--
SG16 mailing list
SG16_at_[hidden]<mailto:SG16_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg16<https://urldefense.com/v3/__https:/lists.isocpp.org/mailman/listinfo.cgi/sg16__;!!EHscmS1ygiU1lA!RfZ-3ZpziALRJn_sSJwrR0gyUZRhOWjr3syeOIG6No1guMhBgIjMCHeZhljmpA$>
Thanks for your feedback. I’m looking forward to your counter-proposal that makes the Windows situation well-formed.
Best regards,
Peter
From: SG16 <sg16-bounces_at_[hidden]> On Behalf Of Peter Bindels via SG16
Sent: 14 April 2021 15:24
To: Corentin Jabot <corentinjabot_at_[hidden]>
Cc: Peter Bindels <peterbindels_at_[hidden]>; SG16 <sg16_at_[hidden]>
Subject: Re: [SG16] P2362R0 Make obfuscating wide character literals ill-formed
EXTERNAL MAIL
I value portable code highly. If we have known platforms, and a competing proposal that makes the Windows situation well-formed, it makes this an odd sell to me. I do not want a specification that requires code to compile on Unix and fail on Windows, even if it is not currently according to spec and somehow unportable code.
Blocking multi-character literals, sure. Blocking some single-character literals as IFDR when they work fine on other platforms, that's just not right. I don't think I like either variant - making it ill-formed on Unix, or to allow it on Unix while making it ill-formed on Windows.
On Wed, 14 Apr 2021 at 16:16, Corentin Jabot <corentinjabot_at_[hidden]<mailto:corentinjabot_at_[hidden]>> wrote:
On Wed, Apr 14, 2021 at 4:07 PM Peter Bindels <peterbindels_at_[hidden]<mailto:peterbindels_at_[hidden]>> wrote:
Then I have the inverse problem, now we create code that is conditionally portable, and only ill-formed on Windows. That's horrible.
How is that worse that code that is well-formed everywhere but does the wrong thing on windows?
wchar_t was never portable
On Wed, 14 Apr 2021 at 15:55, Corentin Jabot <corentinjabot_at_[hidden]<mailto:corentinjabot_at_[hidden]>> wrote:
On Wed, Apr 14, 2021 at 3:49 PM Peter Bindels via SG16 <sg16_at_[hidden]<mailto:sg16_at_[hidden]>> wrote:
Please explain how that facepalm is now illegal on Unix, where wchar_t is 32 bit and it clearly fits.
It's only ill-formed if it doesn't fit!
On Wed, 14 Apr 2021 at 15:27, Peter Brett via SG16 <sg16_at_[hidden]<mailto:sg16_at_[hidden]>> wrote:
Hi all,
Corentin and I have authored https://isocpp.org/files/papers/P2362R0.pdf<https://urldefense.com/v3/__https:/isocpp.org/files/papers/P2362R0.pdf__;!!EHscmS1ygiU1lA!RfZ-3ZpziALRJn_sSJwrR0gyUZRhOWjr3syeOIG6No1guMhBgIjMCHcZYaJ_cQ$>, which will be in the April mailing. This addresses https://github.com/sg16-unicode/sg16/issues/65<https://urldefense.com/v3/__https:/github.com/sg16-unicode/sg16/issues/65__;!!EHscmS1ygiU1lA!RfZ-3ZpziALRJn_sSJwrR0gyUZRhOWjr3syeOIG6No1guMhBgIjMCHcbQmBgqQ$>.
Best regards,
Peter
--
SG16 mailing list
SG16_at_lists.isocpp.org<mailto:SG16_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg16<https://urldefense.com/v3/__https:/lists.isocpp.org/mailman/listinfo.cgi/sg16__;!!EHscmS1ygiU1lA!RfZ-3ZpziALRJn_sSJwrR0gyUZRhOWjr3syeOIG6No1guMhBgIjMCHeZhljmpA$>
--
SG16 mailing list
SG16_at_[hidden]<mailto:SG16_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg16<https://urldefense.com/v3/__https:/lists.isocpp.org/mailman/listinfo.cgi/sg16__;!!EHscmS1ygiU1lA!RfZ-3ZpziALRJn_sSJwrR0gyUZRhOWjr3syeOIG6No1guMhBgIjMCHeZhljmpA$>
Received on 2021-04-14 09:46:42