Date: Tue, 25 Jan 2022 19:38:09 +0100
On 25/01/2022 17.13, Tom Honermann via SG16 wrote:
> On 1/25/22 3:13 AM, Corentin Jabot via SG16 wrote:
>> There is no way that we can accommodate both stability and safety simultaneously for any Unicode related things, nor can we react fast enough to security concerns. In fact there have been a lot of developments in the last few weeks alone.
>>
>> Now, these security concerns are both important, and to handle with care as... It's easy to preclude legitimate use cases.
>>
>> We need as an industry to:
>> * Understand where the diagnostic needs to be produced (ide, compilers, code review tools...)
>> * Find the right way to handle security without excluding legitimate use cases, and a lot of that will come from the Unicode consortium
>> * Have some flexibility to adapt to new best practices
>>
>> I don't think the C++ standard is the place to try to solve these matters, but we could (should?) offer some recommendations.
>
> I think this is a point worth further discussion. For example, addressing these matters via MISRA and other such compliance standards may be preferred; perhaps as a starting point for eventual standardization.
>
> The standard could (I think) also provide normative encouragement to implementors to emit a diagnostic for identifiers that are not inline with TR39 guidance. I'm not sure if we already have examples of encouragement for additional diagnostics elsewhere.
I'm not sure SG16 is the right place to discuss such fundamental matters.
For example, some people like to compile their code with -Werror, and
thus a recommended warning that they cannot possibly avoid (because e.g.
it is inevitably caused by a third-party library) is indistinguishable
from "ill-formed" for them.
Back to the paper at hand: Its unit of consideration is the
"translation unit", which might be formed from header files
from various third-party sources. In a world permeated by
Unicode, it seems very reasonable that each third party would
choose their own script for e.g. identifiers of local
variables in inline functions, yet that inevitably would
cause conflicts under Reini's suggestion.
I don't think it's a good use of SG16's time to discuss this
paper until these concerns are addressed.
Jens
> On 1/25/22 3:13 AM, Corentin Jabot via SG16 wrote:
>> There is no way that we can accommodate both stability and safety simultaneously for any Unicode related things, nor can we react fast enough to security concerns. In fact there have been a lot of developments in the last few weeks alone.
>>
>> Now, these security concerns are both important, and to handle with care as... It's easy to preclude legitimate use cases.
>>
>> We need as an industry to:
>> * Understand where the diagnostic needs to be produced (ide, compilers, code review tools...)
>> * Find the right way to handle security without excluding legitimate use cases, and a lot of that will come from the Unicode consortium
>> * Have some flexibility to adapt to new best practices
>>
>> I don't think the C++ standard is the place to try to solve these matters, but we could (should?) offer some recommendations.
>
> I think this is a point worth further discussion. For example, addressing these matters via MISRA and other such compliance standards may be preferred; perhaps as a starting point for eventual standardization.
>
> The standard could (I think) also provide normative encouragement to implementors to emit a diagnostic for identifiers that are not inline with TR39 guidance. I'm not sure if we already have examples of encouragement for additional diagnostics elsewhere.
I'm not sure SG16 is the right place to discuss such fundamental matters.
For example, some people like to compile their code with -Werror, and
thus a recommended warning that they cannot possibly avoid (because e.g.
it is inevitably caused by a third-party library) is indistinguishable
from "ill-formed" for them.
Back to the paper at hand: Its unit of consideration is the
"translation unit", which might be formed from header files
from various third-party sources. In a world permeated by
Unicode, it seems very reasonable that each third party would
choose their own script for e.g. identifiers of local
variables in inline functions, yet that inevitably would
cause conflicts under Reini's suggestion.
I don't think it's a good use of SG16's time to discuss this
paper until these concerns are addressed.
Jens
Received on 2022-01-25 18:38:16