Repository navigation
libc++ char_traits.h assumes EOF is always available #85158
Description
Activity
- addedlibc++libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.embeddedSupport for embedded developmentSupport for embedded development
on Mar 14, 2024 - added a commit that references this issue
on Mar 14, 2024 I can't really think of a good reason a libc shouldn't provide it. Given that the main thing this might lead to are ODR violations, since libc++ would have to provide it's own if it can't find the libc's, IMO the libc should just provide it. It's not much harder than adding
#define EOF (-1)to a header.Reacted by A. Jiang- added a commit that references this issue
on Mar 15, 2024 - addedwontfixIssue is real, but we can't or won't fix it. Not invalidIssue is real, but we can't or won't fix it. Not invalid
on Mar 15, 2024 I've come across this issue in a different setting and I had the same conclusion -- libc should provide it.
Basically,
EOFis just a really unfortunately-named macro, but it is technically not tied specifically to input and output. It's literally just a macro defined to some integer, and that should be defined even when the underlying system has no notion of I/O or files. It feels really weird to have a header named<stdio.h>in a freestanding C library and to provide a macro namedEOFbut not any other IO related functionality, but I think that's the right thing to do.I suspect that there should be an LWG issue - currently
std::char_traits<char>::eofis required to be freestanding due to P2338R4, but it's also required to return the value ofEOFwhich is not yet freestanding.The
eof,not_eof,to_int_typeandto_char_typemembers ofchar_traitsare only needed by iostreams, so I see no reason for them to be present in freestanding.In libstdc++ we make
eofandnot_eofdepend on hosted, so they're absent for freestanding.Reacted by A. Jiang- added a commit that references this issue
on Oct 7, 2026
libc++ assumes that
EOFis always available and uses it unconditionally in thechar_traits.himplementation.LLVM libc doesn't currently define
EOFon baremetal targets because there's no filesystem support (since baremetal targets typically don't have filesystem to begin with) which results in a compiler error.We could extend LLVM libc to define
EOFeven on baremetal targets, but it's an open question whether libc++ should be able to handle the case whereEOFis undefined.This is related to issue #84879.