[Bug libstdc++/30928] New: add casts to libc overloads

[Bug libstdc++/30928] New: add casts to libc overloads

[marc dot glisse at normalesup dot org]

Headers like cwchar add overloads to libc functions. Here I am interested in
the functions for which the standard C version takes a const pointer and
returns a non-const pointer and in C++ this version is replaced by one with
const everywhere and one with no const anywhere. For this, in c_std mode, g++
takes the libc version (instead of the full-const version) and adds an overload
which looks like:

  inline wchar_t*
  wcschr(wchar_t* __p, wchar_t __c)
  { return wcschr(const_cast<const wchar_t*>(__p), __c); }

The const_cast does not look very useful, but that is not the issue (it makes
it easier to understand, which is good). I was wondering whether it would be
acceptable to add a const_cast<wchar_t*> to the returned value? For the current
uses, it would do nothing. But now if a libc decided to provide the full-const
version when called by a c++ compiler, this would make it work.

Is there any real case where it would help? Well if bugs 27340 (trivial) and
30112 get fixed, with the following fixinclude rule, it would be the last thing
preventing from being able to set __cplusplus to either 1 or 199711L with no
testsuite regression (except for breaking the ABI) on solaris (I only checked
with 8). Of course this is only one way to achieve this (not the best one, but
it requires very little patching).

I will understand if you say no, I am just hoping for a "why not? It doesn't
hurt." (remember that in this bug I am only talking about adding some
const_casts, the __cplusplus value is an other issue)

The fixinclude rule, for info (I am not proposing it here, just mentionning it
for completeness)
/*
 *  Remove extern "C++" parts of solaris libc
 */
fix = {
    hackname  = solaris_no_extern_cpp;
    mach     = '*-*-solaris*';
    files     = "iso/ctype_iso.h";
    files     = "iso/limits_iso.h";
    files     = "iso/locale_iso.h";
    files     = "iso/math_iso.h";
    files     = "iso/setjmp_iso.h";
    files     = "iso/signal_iso.h";
    files     = "iso/stdarg_iso.h";
    files     = "iso/stddef_iso.h";
    files     = "iso/stdio_iso.h";
    files     = "iso/stdlib_iso.h";
    files     = "iso/string_iso.h";
    files     = "iso/time_iso.h";
    files     = "iso/wchar_iso.h";
    files     = "iso/wctype_iso.h";
    select    = 'extern[ \t]*"C\+\+"';
    shell     = "perl -e 'undef $/;$_=<>;s/extern[ \t]*\"C\\\+\\\+\"[
\t]*{([^{}]*{[^{}]*})*[^{}]*}//gs;print'";
    test_text = 'extern "C++" {void f();}';
};

(this uses perl, which I think has been part of the system for a very long
time, because I don't know how to do it with sed. I also don't know if the
files field accepts wildcards)


-- 
           Summary: add casts to libc overloads
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: marc dot glisse at normalesup dot org
  GCC host triplet: sparc-sun-solaris2.8


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928

[Bug libstdc++/30928] add casts to libc overloads

[jakub at gcc dot gnu dot org]

------- Comment #1 from jakub at gcc dot gnu dot org  2009-01-30 11:48 -------
For very recent glibc this has been fixed with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143773


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928

[Bug libstdc++/30928] add casts to libc overloads

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-01-30 12:07:28
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928

[Bug libstdc++/30928] add casts to libc overloads

[paolo dot carlini at oracle dot com]

------- Comment #2 from paolo dot carlini at oracle dot com  2009-01-30 12:08 -------
*** Bug 33935 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928

[Bug libstdc++/30928] add casts to libc overloads

[marc dot glisse at normalesup dot org]

------- Comment #3 from marc dot glisse at normalesup dot org  2009-01-30 20:38 -------
Hello,

looking at the two last comments, I think we are speaking of slightly different
things, although they are related. I was asking for some const_cast of the
return value, in case the const version of wcschr (or other) we are forwarding
to (from the non-const overload) has the official C++ prototype. In any case,
it can't hurt and makes the code a bit cleaner with respect to the intended
behaviour. I was then planning to ask glibc to insert a macro in the
declaration:
extern MYMACRO void* memchr(const void*,int,size_t); where MYMACRO could be
defined as "const" by a C++ implementation, but apparently an even better fix
was adopted, cool :-)

The fix mentionned by Jakub is the right way to do things for a well-behaved
libc (solaris with __cplusplus>=199711L, or apparently a very recent glibc).
Hopefully the same thing will be done for the other headers (cstdlib or cmath
for instance), although the interaction with C99/C++0X may require 2 macros
instead of just one.

Bug 33935 asks that g++ ship a string.h that is equivalent to cstring when
__CORRECT_ISO_CPP_STRING_H_PROTO is not defined. Obviously it is not that easy
because standard headers including each other may end up including the
wrappers, but now that glibc and its multiply included headers are out of the
way it may be easier (or not). Too bad there is no easy way to distinguish libc
headers from other headers.

Anyway, I want to thank you both because you did not consider these issues
negligible. I'd love to help, I know how to fix most of the bugs I have filed
related to solaris headers, but I still haven't managed to get the legal
paperwork done (keep changing employers, and the FSF disclaimer is not a paper
they have ever signed before).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928

[Bug libstdc++/30928] add casts to libc overloads

[paolo dot carlini at oracle dot com]

------- Comment #4 from paolo dot carlini at oracle dot com  2010-01-14 17:23 -------
It seems to me extremely unlikely that an implementation decides to provide the
full-const version when called by a c++ compiler and nothing else, because C++
does *not* add an overload, *replaces both*. Thus it seems definitely
premature.

About the unrelated point at the beginning, the const_cast in wcschr, that is
*essential* otherwise how can the forwarding to the *other* overload happen? We
can only remove it from the plain char overloads, which forwards to the
builtins.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928

[Bug libstdc++/30928] add casts to libc overloads

[marc dot glisse at normalesup dot org]

------- Comment #5 from marc dot glisse at normalesup dot org  2010-01-14 20:35 -------
(In reply to comment #4)
> It seems to me extremely unlikely that an implementation decides to provide the
> full-const version when called by a c++ compiler and nothing else, because C++
> does *not* add an overload, *replaces both*. Thus it seems definitely
> premature.

As mentionned in the original bug report, on solaris, it is quite easy to get
this behavior. However, I agree that it is not the right way to do it, and the
apparition of macros like __CORRECT_ISO_CPP_WCHAR_H_PROTO seems like a much
better way to handle things. In some sense the main interest of this bug is to
show one way to get c* headers that don't pollute the global namespace on
solaris. But "resolved invalid" is right. #33935 (shouldn't that one be
unmerged?) is a better place to track the incomplete resolution of DR456 wrt
strchr.

> About the unrelated point at the beginning, the const_cast in wcschr, that is
> *essential* otherwise how can the forwarding to the *other* overload happen?

Er, yes, that's obvious. I have no idea what I was thinking when I wrote that
(3 years ago). Maybe just that it is a cast in the direction non-const->const
(not that it matters).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928

[Bug libstdc++/30928] add casts to libc overloads

[paolo dot carlini at oracle dot com]

------- Comment #6 from paolo dot carlini at oracle dot com  2010-01-14 20:44 -------
Yes, I agree, in the light of the resolution of DR456, let's keep open 33935
instead, and clarify in it that non-GNU targets have yet to provide a mechanism
similar to the one used in recent glibcs.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928