https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92987
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Wed, 18 Dec 2019, lhyatt at gmail dot com wrote: > I was about to work on adding support for -finput-charset into diagnostics > infrastructure (it currently ignores it), however it seems like this issue > should probably be dealt with first, since it may entail adding the notion > that > different source files have a different input encoding. I am not sure what > would be the desired way to address it. Are there use cases where it is > desirable that -finput-charset applies to the #includes too (I guess systems Presumably headers in the user's own project might be in the specified character set. > could exist where the system headers are not ASCII)? Would it make sense to > add > a new option that changed the charset only for source files, and not the > #includes? Or maybe it should be kept for "..." includes and not for <...> or > something like this? Plenty of code does e.g. #include "stdio.h" rather than using <>. I think -finput-charset may only be usable for character sets that are valid locale character sets (we don't implement the POSIX rule of interpreting source files in the locale encoding), which does mean supersets of ASCII. And headers provided by one project for use by another indeed do practically need to be ASCII to be maximally portable.
