libstdc++/9679: Strange behaviour of valarray::apply method

libstdc++/9679: Strange behaviour of valarray::apply method

[dens]

>Number:         9679
>Category:       libstdc++
>Synopsis:       Strange behaviour of valarray::apply method
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 12 22:16:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     dens@stl.sarov.ru
>Release:        libstdc++-3.2-7
>Organization:
>Environment:
cat /etc/issue
Red Hat Linux release 8.0 (Psyche)
Kernel \r on an \m

g++ --version
g++ (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
>Description:
There is very strange(for me) behaviour of apply method of valarray:

#include <valarray>
#include <string.h>
char bar(char arg)
{
    return tolower(arg);
}

char foo(char * x)
{
    return toupper(*x);
}

int main(void)
{
        char * str = new char[7];
        strcpy(str,"STRING");

        std::valarray<char> y(str, 6);
///   Strange behaviour    
        char some = foo(&(y.apply(bar)[0]));
        return 0;
}

If I understood correctly then apply method should return valarray<char> object which operator [] should return reference to char (char &). (C++ standard 26.3.2.3 and 26.3.2.7 8.)

But in our case this operator returns non-lvalue and I can't get it address. It is very strange for me.
>How-To-Repeat:
Try to compile attached sample
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="new.cpp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="new.cpp"

I2luY2x1ZGUgPHZhbGFycmF5PgojaW5jbHVkZSA8c3RyaW5nLmg+CmNoYXIgYmFyKGNoYXIgYXJn
KQp7CiAgICByZXR1cm4gdG9sb3dlcihhcmcpOwp9CgpjaGFyIGZvbyhjaGFyICogeCkKewogICAg
cmV0dXJuIHRvdXBwZXIoKngpOwp9CgppbnQgbWFpbih2b2lkKQp7CgljaGFyICogc3RyID0gbmV3
IGNoYXJbN107CglzdHJjcHkoc3RyLCJTVFJJTkciKTsKCglzdGQ6OnZhbGFycmF5PGNoYXI+IHko
c3RyLCA2KTsKCWNoYXIgc29tZSA9IGZvbygmKHkuYXBwbHkoYmFyKVswXSkpOwoJcmV0dXJuIDA7
Cn0K

Re: libstdc++/9679: Strange behaviour of valarray::apply method

[Gabriel Dos Reis]

The following reply was made to PR libstdc++/9679; it has been noted by GNATS.

From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: dens@stl.sarov.ru
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/9679: Strange behaviour of valarray::apply method
Date: 12 Feb 2003 23:33:04 +0100

 dens@stl.sarov.ru writes:
 
 | >Number:         9679
 | >Category:       libstdc++
 | >Synopsis:       Strange behaviour of valarray::apply method
 
 strange but standard conforming with C++98, not C++0x...
 
 [...]
 
 | #include <valarray>
 | #include <string.h>
 | char bar(char arg)
 | {
 |     return tolower(arg);
 | }
 | 
 | char foo(char * x)
 | {
 |     return toupper(*x);
 | }
 | 
 | int main(void)
 | {
 |         char * str = new char[7];
 |         strcpy(str,"STRING");
 | 
 |         std::valarray<char> y(str, 6);
 | ///   Strange behaviour    
 |         char some = foo(&(y.apply(bar)[0]));
 |         return 0;
 | }
 | 
 | If I understood correctly then apply method should return valarray<char> object which operator [] should return reference to char (char &). (C++ standard 26.3.2.3 and 26.3.2.7 8.)
 | 
 | But in our case this operator returns non-lvalue and I can't get it address. It is very strange for me.
 
 Here is what is happening.  Firstly, let's recall
 
 26.3.1/3:
   Any function returning a valarray<T> is permitted to return an
   object of another type, provided all the const member functions of
   valarray<T> are also applicable to this type. This return type shall
   not add more than two levels of template nesting over the most
   deeply nested argument type.
 
 apply() being a const member function actually returns something that
 is -not- a valarray.  Subsequent application of operator[] to that
 object is considered to be application of "operator[] const" which is
 defined by C++08 to return an rvalue.  Therefore, pedantically
 speaking your program is not required to compile.
 
 However, I happen to be the other guy that champions 
 "valarray<T>::operator[] const" returning a const T&; that, in effect,
 conflicts with loosened return type.  Too bad :-(
 
 -- Gaby