An example such as this seems to be handled badly by the current rules in C:
const char str[] = {
#embed "/maybe/empty/file" if_empty("error: \"resource file empty!\"")
};
In particular, 6.4.1/4 says:
> There is one exception to this rule: header name preprocessing tokens are recognized only within #include and #embed preprocessing directives, in __has_include and __has_embed expressions, as well as in implementation-defined locations within #pragma directives. In such contexts, a sequence of characters that could be either a header name or a string literal is recognized as the former.
So the first preprocessing token in the `if_empty` ends at the first `\"`, forms a header name, and the program is invalid if the given file is empty because it tries to convert a header name preprocessing token to a token (violation of constraint in 6.4.1/2).
I don't think this was intended. C++ has a different rule that doesn't have this problem. In its [lex.pptoken]/5:
"""
[...C++-specific deviations from max-munch...]
Otherwise, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token, even if that would cause further lexical analysis to fail, except that
-- a string-literal token is never formed when a header-name token can be formed, and
-- a header-name ([lex.header]) is only formed
-- immediately after the include or embed preprocessing token in a #include ([cpp.include]) or #embed ([cpp.embed]) directive, respectively, or
-- immediately after an import preprocessing token that is at the start of a logical source line, or
-- immediately after a preprocessing token sequence of __has_include or __has_embed immediately followed by ( in a #if, #elif, or #embed directive ([cpp.cond], [cpp.embed]).
A preprocessing token is considered to be immediately after another preprocessing token if the preprocessing tokens are on the same logical source line and there are no intervening preprocessing tokens.
"""
The "import preprocessing token" part is for C++ modules, but I think the rest would be directly applicable to C. Perhaps a similar rule should be adopted, at least for #embed and __has_embed (though ideally for includes as well)?
Note that this would affect the validity and meaning of cases where there is an empty macro expansion between the directive-introducing token and the name of the header:
#define EMPTY
// Works in C++, not in C.
#include EMPTY "foo\"bar.h"
// Works in C, not in C++.
#include EMPTY "baz\quux.h"
Other fun cases include:
#define MAKE_HEADER(prefix, suffix) prefix/bar/suffix
#include MAKE_HEADER(<foo,baz.h>)
... which the C++ rules map into an inclusion of the reconstituted <foo/bar/baz.h>, whereas the C rules reject because the MAKE_HEADER macro was not given enough arguments.
For what it's worth: the GCC preprocessor appears to implement the C++ rule in all languages (for both #embed and #include), and has done at least all the way back to version 3; the Clang preprocessor implements the C rule in all languages up until it reaches the end of the filename for `#embed`, then switches to a "no header-names" mode. I did not find any implementation of #embed that follows the C rule as written.