ostream operator<< for volatile void *

ostream operator<< for volatile void *

[NightStrike]

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?

Re: ostream operator<< for volatile void *

[Jonathan Wakely]

On Fri, 16 Apr 2021, 02:43 NightStrike via Gcc-help, <gcc-help@gcc.gnu.org>
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?

>

Re: ostream operator<< for volatile void *

[NightStrike]

On Fri, Apr 16, 2021 at 2:59 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On Fri, 16 Apr 2021, 02:43 NightStrike via Gcc-help, <gcc-help@gcc.gnu.org> 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.

Re: ostream operator<< for volatile void *

[Jonathan Wakely]

On Fri, 16 Apr 2021, 08:40 NightStrike, <nightstrike@gmail.com> wrote:

> On Fri, Apr 16, 2021 at 2:59 AM Jonathan Wakely <jwakely.gcc@gmail.com>
> wrote:
> > On Fri, 16 Apr 2021, 02:43 NightStrike via Gcc-help, <
> gcc-help@gcc.gnu.org> 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.
>


Printing volatile addresses is not commonly needed.

>

Re: ostream operator<< for volatile void *

[Marc Glisse]

On Fri, 16 Apr 2021, NightStrike via Gcc-help wrote:

> On Fri, Apr 16, 2021 at 2:59 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On Fri, 16 Apr 2021, 02:43 NightStrike via Gcc-help, <gcc-help@gcc.gnu.org> 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.

-- 
Marc Glisse

Re: ostream operator<< for volatile void *

[Jonathan Wakely]

On Fri, 16 Apr 2021 at 09:54, Marc Glisse <marc.glisse@inria.fr> wrote:
>
> On Fri, 16 Apr 2021, NightStrike via Gcc-help wrote:
>
> > On Fri, Apr 16, 2021 at 2:59 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >> On Fri, 16 Apr 2021, 02:43 NightStrike via Gcc-help, <gcc-help@gcc.gnu.org> 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