Date: Mon, 15 Feb 2021 22:07:49 +0100
Joseph,
on Mon, 15 Feb 2021 20:33:16 +0000 you (Joseph Myers via Liaison
<liaison_at_[hidden]>) wrote:
> At the last WG14 meeting I asked if anyone was still using a
> preprocessor separate from the compiler that did not have
> configuration information about types from the compiler (about the
> number of bits in char, in the case of the #embed discussion), and
> was advised that separate preprocessors like that were indeed still
> in use.
>
> I suppose that allowing character literals to have different values
> in #if is another thing intended to help such preprocessor
> implementations that are more or less independent of the compiler.
> So while I support requiring literals to have the same values in the
> compiler and the preprocessor, there may be concerns from those using
> such a separate preprocessor.
You are right that such questions are probably the reason that this is
in this state, currently.
But if we have a particular encodings/locale for preprocessor and then
another in later phases, doesn't hat mean that there can also be
inconsistencies for macro names (being identical to function
identifiers in some cases), preprocessor stringification and `_Pragma`
destringification ?
It looks weird to me that we wouldn't expect the preprocessor and
later phases to have the same rules for encoding.
Thanks
Jens
on Mon, 15 Feb 2021 20:33:16 +0000 you (Joseph Myers via Liaison
<liaison_at_[hidden]>) wrote:
> At the last WG14 meeting I asked if anyone was still using a
> preprocessor separate from the compiler that did not have
> configuration information about types from the compiler (about the
> number of bits in char, in the case of the #embed discussion), and
> was advised that separate preprocessors like that were indeed still
> in use.
>
> I suppose that allowing character literals to have different values
> in #if is another thing intended to help such preprocessor
> implementations that are more or less independent of the compiler.
> So while I support requiring literals to have the same values in the
> compiler and the preprocessor, there may be concerns from those using
> such a separate preprocessor.
You are right that such questions are probably the reason that this is
in this state, currently.
But if we have a particular encodings/locale for preprocessor and then
another in later phases, doesn't hat mean that there can also be
inconsistencies for macro names (being identical to function
identifiers in some cases), preprocessor stringification and `_Pragma`
destringification ?
It looks weird to me that we wouldn't expect the preprocessor and
later phases to have the same rules for encoding.
Thanks
Jens
-- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Received on 2021-02-15 15:07:55