[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs

["ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Given that C++ says e.g. in https://eel.is/c++draft/lex.ccon#3.1
> that program is ill-formed if some character lacks encoding in the execution
> character set, I'm afraid the Solaris iconv behavior results in violation of
> the C++ standard requirements, it is hard to argue that in the Solaris case
> e.g. ISO-8859-1 execution charset would be some special character set where ?
> character represents all Unicode characters which don't have a representation
> in the character set in addition to ?.

I've now started digging into this myself.

* Solaris iconv(1) says

       output. If no conversion exists for a particular character,  an  imple-
       mentation-defined conversion is performed on this character.

* This seems to at least partially match with XPG7:

-s  Suppress any messages written to standard error concerning invalid
    characters. When -s is not used, the results of encountering invalid
    characters in the input stream (either those that are not valid
    characters in the codeset of the input file or that have no
    corresponding character in the codeset of the output file) shall be
    specified in the system documentation. The presence or absence of -s
    shall not affect the exit status of iconv.

  AFAIU that's related to what Solaris iconv(1) does, although they
  don't specify the output '?' and produce no message.  However, they
  still exit with 0, which seems wrong to me.

I've not yet tried to understand what either iconv(3) has to say on the
matter.

> I'm afraid we don't want to maintain iconv replacement inside of libcpp though.

Agreed.