[Bug libstdc++/27340] New: valarray uses __cos which may conflict with libm functions

[Bug libstdc++/27340] New: valarray uses __cos which may conflict with libm functions

[marc dot glisse at normalesup dot org]

valarray defines structs with names like __cos, __sin, etc. It is often the
case (glibc, solaris) that the libc declares functions with those same names.
In the current situation we are lucky because the structs are in namespace std
and the functions in the global namespace. But playing around with namespace
std soon brings something like this:

namespace std {
    double __cos(double);
    struct __cos
    {
        template<typename _Tp>
            _Tp operator()(const _Tp& __t) const;
    };
}
template <class T> struct A {};
int main(){
    A<std::__cos> a;
}

which results in:

error: type/value mismatch at argument 1 in template parameter list for
'template<class T> struct A'
error:   expected a type, got 'std::__cos'
error: invalid type in declaration before ';' token


It would be preferable to use a less conflict-prone name.


-- 
           Summary: valarray uses __cos which may conflict with libm
                    functions
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: marc dot glisse at normalesup dot org


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-04-27 19:07 -------
Both libc and libstdc++ are considered part of the implementation which means
both are valid to use this name space.


-- 


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[marc dot glisse at normalesup dot org]

------- Comment #2 from marc dot glisse at normalesup dot org  2006-04-28 10:33 -------
(In reply to comment #1)
> Both libc and libstdc++ are considered part of the implementation which means
> both are valid to use this name space.

Which means both should take care not to use a name (in this name space)
already used by the other one. I actually don't understand what your point is.


-- 

marc dot glisse at normalesup dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marc dot glisse at
                   |                            |normalesup dot org


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[pcarlini at suse dot de]

------- Comment #3 from pcarlini at suse dot de  2006-04-28 20:01 -------
(In reply to comment #2)
> (In reply to comment #1)
> > Both libc and libstdc++ are considered part of the implementation which means
> > both are valid to use this name space.
> 
> Which means both should take care not to use a name (in this name space)
> already used by the other one. I actually don't understand what your point is.

Well, I think Andrew has a point: suppose we rename all those functions to
_M_cos and co. Then, later, we discover that a third libc (not Solaris, not
GNU) conflicts with those names too... The point is that there is no *robust*
concept of less-conflict prone name: if such conflicts happen then something is
wrong in the design, something profound is wrong, somewhere. We already
discussed this issue in another context (header guards names), and, not having
looked very closely into this specific issue, I'm pretty convinced.


-- 


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[marc dot glisse at normalesup dot org]

------- Comment #4 from marc dot glisse at normalesup dot org  2006-04-28 20:43 -------
(In reply to comment #3)
> Well, I think Andrew has a point: suppose we rename all those functions to
> _M_cos and co. Then, later, we discover that a third libc (not Solaris, not
> GNU) conflicts with those names too... The point is that there is no *robust*
> concept of less-conflict prone name:

I thought about a name that contains gcc or glibcxx or something like that, but
now I understand Andrew's point, thank you.

> if such conflicts happen then something is
> wrong in the design, something profound is wrong, somewhere.

So something is wrong in the design. If the wrong thing is in that the libc and
compiler are separate entities, there is little we can do about it. So what can
be done? Should all those private classes and functions be declared in some
specific namespace std::glibcxx_private to have a single point of failure? The
current names (__cos and similar) do conflict, and unless a better solution is
proposed, renaming (and re-renaming if there still are problems) seems like the
easy way to fix it.

> We already
> discussed this issue in another context (header guards names), and, not having
> looked very closely into this specific issue, I'm pretty convinced.

Convinced of what? (sorry about my slow understanding of these conversations, I
am quite new to gcc, and I guess the style needs some time to sink in)


-- 


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[pcarlini at suse dot de]

------- Comment #5 from pcarlini at suse dot de  2006-04-28 21:18 -------
(In reply to comment #4)

> Convinced of what?

Of course convinced that before renaming and re-renaming (endlessly, in
principle) we should really give some serious tought to those issues, figure
out what we are trying to achieve, by which means, and so on. Again, I
encourage you to post on the libstdc++ list a careful analysis of the issue,
complete of mini-patch (fixing  only one header, for example). At this point
what you mean by "playing around" is not at all clear.


-- 


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[marc dot glisse at normalesup dot org]

------- Comment #6 from marc dot glisse at normalesup dot org  2006-04-28 21:57 -------
(In reply to comment #4)
> Should all those private classes and functions be declared in some
> specific namespace std::glibcxx_private to have a single point of failure? 

Oups, I just noticed that was one of the roles of __gnu_cxx (although I don't
understand why this namespace is not a subnamespace of std:: as tr1 (or at
least contains a using namespace std;), which would at the same time fix things
like getenv not being prefixed by std:: in ext/mt_allocator.h). So in this case
it would seem reasonable to move the classes to that namespace.

(In reply to comment #5)
> Again, I
> encourage you to post on the libstdc++ list a careful analysis of the issue,
> complete of mini-patch (fixing  only one header, for example). At this point
> what you mean by "playing around" is not at all clear.

I had posted this bug report because I found it quite independant from the
rest. It is easy to see on solaris that __cplusplus>=199711L declares a
function __cos in namespace std, and I think I read somewhere that changing tha
value of __cplusplus was being considered.

I will eventually post something on the libstdc++ mailing list, but I am slowed
down by several things:
- I have only limited access to solaris 8 and 9, and several things would
require solaris 10 to work properly (at least it would be less work)
- the _GLIBCPP_USE_NAMESPACES in glibc has dozens of bugs (besides design
issues), to the point that doing: namespace std { #include <foo.h> } actually
works better than defining the macro right now...
- tracking why and where all the macros like __USE_GNU are defined is a
nightmare
- it may not be possible to work on each header independantly, because headers
include other headers

But I haven't quite given up hope yet. Depends how much time I will get to work
on this.


-- 


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[gdr at integrable-solutions dot net]

------- Comment #7 from gdr at integrable-solutions dot net  2006-05-01 23:39 -------
Subject: Re:  valarray uses __cos which may conflict with libm functions

"marc dot glisse at normalesup dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #4)
| > Should all those private classes and functions be declared in some
| > specific namespace std::glibcxx_private to have a single point of failure? 
| 
| Oups, I just noticed that was one of the roles of __gnu_cxx (although I don't
| understand why this namespace is not a subnamespace of std:: as tr1 (or at
| least contains a using namespace std;),

Why shall it?


Before people suggest more tricky playing with libstdc++ name spaces,
I would recommand people understand that namespaces are not silver bullet
against machivelic playing with names. 


| which would at the same time fix things
| like getenv not being prefixed by std:: in ext/mt_allocator.h).

That is a separate problem that does not require namespace nesting. 

Nesting namespaces does not come for free.  You really need to
understand its consequences (name lookp, overload resolution, etc.)
before proposing it.   

-- Gaby


-- 


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[paolo dot carlini at oracle dot com]

------- Comment #8 from paolo dot carlini at oracle dot com  2010-02-05 13:07 -------
It seems this can be safely closed as invalid, there is no reason why
std::__cos should be wrong.


-- 

paolo dot carlini at oracle dot com changed:

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


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[marc dot glisse at normalesup dot org]

------- Comment #9 from marc dot glisse at normalesup dot org  2010-02-06 17:52 -------
(In reply to comment #8)
> It seems this can be safely closed as invalid, there is no reason why
> std::__cos should be wrong.

Marking this as invalid means that we can never include solaris libc headers
with __cplusplus >= 199711 (which declare std::__cos as a function) without
fixincluding them beyond recognition.

Even without this problem on solaris, using in libstdc++ names as generic as
std::__cos for a functionality limited to valarray doesn't seem like an ideal
naming convention.

But then, the choice is yours, I am not ticking the "reopen" box.


-- 


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[paolo dot carlini at oracle dot com]

------- Comment #10 from paolo dot carlini at oracle dot com  2010-02-06 19:07 -------
I'll re-open this only if Gaby, maintainer of valarray, thinks it's the right
thing to do.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at integrable-solutions
                   |                            |dot net


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[gdr at gcc dot gnu dot org]

------- Comment #11 from gdr at gcc dot gnu dot org  2010-02-06 19:17 -------
(In reply to comment #10)
> I'll re-open this only if Gaby, maintainer of valarray, thinks it's the right
> thing to do.
> 

If someone wants to rename __cos to _Cos, that is fine by me.
But, it should be noted that this silly name play is not
scalable, and I'm unsympathetic to further uglyfication.

-- Gaby


-- 


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
                   |dot org                     |dot com
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-02-06 19:43:08
               date|                            |


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[paolo dot carlini at oracle dot com]

------- Comment #12 from paolo dot carlini at oracle dot com  2010-02-06 19:42 -------
I totally agree. Anyway, ok, I can do that, it will require a bit of tweaking
to the valarray_after.h macros, no big deal.


-- 

paolo dot carlini at oracle dot com changed:

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


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[paolo at gcc dot gnu dot org]

------- Comment #13 from paolo at gcc dot gnu dot org  2010-02-06 20:41 -------
Subject: Bug 27340

Author: paolo
Date: Sat Feb  6 20:41:09 2010
New Revision: 156555

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156555
Log:
2010-02-06  Paolo Carlini  <paolo.carlini@oracle.com>

        PR libstdc++/27340
        * include/bits/valarray_before.h: Uglify the structs wrapping
        cmath functions differently, eg, _Cos instead of __cos.
        * include/bits/valarray_after.h: Adjust.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/bits/valarray_after.h
    trunk/libstdc++-v3/include/bits/valarray_before.h


-- 


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[paolo dot carlini at oracle dot com]

------- Comment #14 from paolo dot carlini at oracle dot com  2010-02-06 20:44 -------
Done.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


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

[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions

[gdr at integrable-solutions dot net]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 456 bytes --]



------- Comment #15 from gdr at integrable-solutions dot net  2010-02-06 22:21 -------
Subject: Re:  valarray uses __cos which may conflict with 
        libm functions

On Sat, Feb 6, 2010 at 2:44 PM, paolo dot carlini at oracle dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
> ------- Comment #14 from paolo dot carlini at oracle dot com  2010-02-06 20:44 -------
> Done.

Thanks, Paolo.

-- Gaby


-- 


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