https://bugs.llvm.org/show_bug.cgi?id=47645
Bug ID: 47645
Summary: Trigraph support in various C language modes
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangbugs at nondot.org
Reporter: aaron at aaronballman.com
CC: blitzrakete at gmail.com, dgregor at apple.com,
erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
richard-llvm at metafoo.co.uk
Clang's trigraph support is disabled by default when the language standard is
set to GNU C mode. Not supporting trigraphs is perhaps reasonable because the
user is specifying that they want something other than standard C.
However, when *no* -std= option is passed on the command line, we silently
default to gnu17 mode which then disables this standard C feature and that
seems less reasonable to me because this is a case where we're *removing*
support for a feature rather than adding a conforming extension. The user is
saying "here's my C file, please compile it" and I think we should be able to
compile conforming C in that case (for some C standard version, but all of them
currently support trigraphs).
Confounding matters somewhat, we define __STDC__ to 1 in GNU mode despite
trigraph support in C being mandatory.
Should trigraphs remain enabled when no -std is present (even though we would
still default to gnu17) so that users can compile conforming C code?
Should __STDC__ be paying attention to whether trigraph support is enabled or
not?
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200925/0539f89f/attachment.html>