Unicode security

[Paul Koning]

> On Jan 10, 2022, at 5:13 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> On Mon, 10 Jan 2022, Paul Koning via Binutils wrote:
> 
>> A standard that needs to handle Unicode and have a definition of "equal 
>> strings" will want to refer to a particular normalization.
> 
> For the purposes of ELF, equal strings are equal octet sequences, with no 
> further interpretation.
> 
> The ELF bindings to C do not need a concept of "equal", they just need to 
> say that UTF-8 is used to encode the sequence of Unicode code points in 
> the C symbol.  Those bindings need to handle multiple C versions with 
> different sets of allowed characters in identifiers, some of which allow 
> identifiers that are different as sequences of Unicode code points, and 
> thus different in C and in UTF-8, although the same in NFC.  In those 
> cases, the bindings need to result in different octet sequences in ELF 
> symbols for those different (but normalized the same) C identifiers.  When 
> a C identifier is written in NFC, so must the ELF symbol be; when a C 
> identifier is written in NFD, so must the ELF symbol be; when a C 
> identifier is in neither normalization form, so must the ELF symbol be.

Yikes.  So if you use a different text editor than the previous author, or a different compiler, your C code with Unicode identifiers might suddenly get link errors because the same string got encoded a different way.

This is clearly bad; is there some way for this to be fixed?

	paul