C++ Logo


Advanced search

Re: [Tooling] [isocpp-modules] Path to modules with old bad buildsystems

From: Tom Honermann <tom_at_[hidden]>
Date: Thu, 7 Mar 2019 00:14:07 -0500
On 2/25/19 10:06 PM, Ben Boeckel via Modules wrote:
> On Mon, Feb 25, 2019 at 10:44:41 +0100, Nagy-Egri Máté Ferenc wrote:
>> „I have GCC writing out JSON-like syntax right now. It isn't 100%
>> valid since it isn't UTF-8, but I don't want *that* in these files
>> either.”
> <snip>
>> TL;DR: Paths containing UTF-8 is sometimes not the choice of the user
>> but OS or other SW vendor. Please keep that in mind. (In the 21st
>> century, this should really not cause headaches on the end-user side.)
> I know, that's way I said the paths should just be something one can
> pass to `fopen` or whatever API is used on the platform and get the
> correct file handle back. I don't care about the encoding *at all*
> because I'm just doing path joins on the values. But JSON says "Unicode"
> which we cannot require it because it'd be silly if the *compiler* says
> you can't use ISO-8859-1 or Shift-JIS file names with this handy dandy
> dependency output format. Build tools enforce encoding all the time, but
> the compiler is too low-level for that.
> Of course, unless SG16 has something to say about non-Unicode `#include`
> paths…

SG16's guidance on paths and file names is that they are code unit
(typically byte/octet) sequences with no associated encoding. We intend
to update P1238 to record this guidance as a constraint we have to live


> --Ben
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden]
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/modules
> Link to this post: http://lists.isocpp.org/modules/2019/02/0102.php

Received on 2019-03-07 06:14:10