Unicode security

[Mike Frysinger]

On 10 Jan 2022 22:13, Joseph Myers 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.

this really is the only reasonable & maintainable position for the toolchain
projects to take.  higher level concerns about NFC are best left to higher
level diagnostics (like gcc's -W flag you highlighted already).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20220121/d5cc8aa7/attachment.sig>