On Fri, 16 Apr 2021 at 09:54, Marc Glisse <marc.glisse@xxxxxxxx> wrote: > > On Fri, 16 Apr 2021, NightStrike via Gcc-help wrote: > > > On Fri, Apr 16, 2021 at 2:59 AM Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > >> On Fri, 16 Apr 2021, 02:43 NightStrike via Gcc-help, <gcc-help@xxxxxxxxxxx> wrote: > >>> > >>> Currently, printing a "void *" works fine, and printing a "volatile > >>> void *" fails with a very unclear error. This appears to be due to > >>> the nonexistence of a function that can handle a volatile pointer. > >>> While I am guessing that it is not covered by the standard, would GCC > >>> folks consider having a GCC extension that can properly print it? > >> > >> > >> No, I don't think so. Can't you just use const_cast? > > > > Yes, and I can also just write the overload myself (which is what I > > ultimately did) as: > > > > inline std::ostream & operator<<(std::ostream & os, void const volatile * p) { > > return os << const_cast<void const *>(p); > > } > > > > But, I find it surprising as a user that I have to do this, and I > > don't understand the rationale for why the standard would > > intentionally leave it out. > > You could try proposing the extra overload(s) on > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals (or maybe as a > replacement for the void const* one?), this is much less formal than > sending a paper to the C++ committee and could get some quick feedback. Or > of course you can directly write a paper for WG21... > > Nowadays, gcc tries to minimize new non-standard extensions, so the way in > is through the standard. In fact there is already a proposal, waiting to be reviewed by LWG: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1147r0.html