[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] Trojan Source Attacks
From:       Stuart D Gathman <stuart () gathman ! org>
Date:       2021-11-02 20:43:48
Message-ID: 2dddaf8c-9220-f776-b0b4-13ad94d17e15 () gathman ! org
[Download RAW message or body]

> That's because unicode rendering is a UI element and calling compilers
> "impacted" is misunderstanding the issue.  There's scope for adding
> new diagnostics to square with UI representation of unicode, but
> that's at best an optional warning and it may not even be feasible in
> all cases.  A comprehensive language aware CI lint check is perhaps
> more suitable but if such a check devolves into "7-bit ascii only
> allowed" for all cases then we've regressed.

Bingo.  For many current languages, unicode is supported in string
constants and comments only - so syntax coloring should highlight 
anything beyond 7 or 8-bit outside of those elements.

Some support unicode variable/function names, and again syntax coloring
should be able to highlight sequences that cross word boundaries.

Having some sample source files to test your code editor/viewer on would be
helpful.
[prev in list] [next in list] [prev in thread] [next in thread]