Is diagnostics of const violation required

Please consider:

struct X {

int x;

X ( int i = 0 )
: x ( i )
{}

operator X & ( void ) const {
return ( *this );
}

};

void add_one ( X & ref ) {
++ ref.x;
}

#include <iostream>

int main ( void ) {
X const a ( 2 );
add_one( a );
std::cout << a.x << '\n';
}


This code is clearly in violation of the standard [9.3.2/2]:

In a const member function, the object for which the function is called is
accessed through a const access path; [...]


However, I wonder whether diagnostics for this violation is required -- on
my machine, the code compiles but the program segfaults and I am
considering submitting a bug report to the compiler vendor.

Can someone give me chapter and verse on this?


Thanks

Kai-Uwe Bux

re: Is diagnostics of const violation required

Kai-Uwe Bux wrote:[color=blue]
> Please consider:
>
> struct X {
>
> int x;
>
> X ( int i = 0 )
> : x ( i )
> {}
>
> operator X & ( void ) const {
> return ( *this );
> }[/color]

This "conversion function" is not used. It cannot be used according
to 12.3.2.
[color=blue]
>
> };
>
> void add_one ( X & ref ) {
> ++ ref.x;
> }
>
> #include <iostream>
>
> int main ( void ) {
> X const a ( 2 );
> add_one( a );
> std::cout << a.x << '\n';
> }
>
>
> This code is clearly in violation of the standard [9.3.2/2]:
>
> In a const member function, the object for which the function is
> called is accessed through a const access path; [...][/color]

Which part do you think is in violation? I don't believe 9.3.2/2
has anything to do with it. What happens here is a violation of the
subclause 8.5.3/5 that essentially says that a reference to non-const
object cannot be initialised with an object if its 'cv-qualifiers'
are stronger than that of the reference. A diagnostic is required
according to 1.4.
[color=blue]
> However, I wonder whether diagnostics for this violation is required[/color]

Yes.
[color=blue]
> -- on my machine, the code compiles but the program segfaults and I am
> considering submitting a bug report to the compiler vendor.
>
> Can someone give me chapter and verse on this?[/color]

I have, I hope.

V
--
Please remove capital As from my address when replying by mail

re: Is diagnostics of const violation required

Victor Bazarov wrote:
[color=blue]
> Kai-Uwe Bux wrote:[color=green]
>> Please consider:
>>
>> struct X {
>>
>> int x;
>>
>> X ( int i = 0 )
>> : x ( i )
>> {}
>>
>> operator X & ( void ) const {
>> return ( *this );
>> }[/color]
>
> This "conversion function" is not used. It cannot be used according
> to 12.3.2.
>[color=green]
>>
>> };
>>
>> void add_one ( X & ref ) {
>> ++ ref.x;
>> }
>>
>> #include <iostream>
>>
>> int main ( void ) {
>> X const a ( 2 );
>> add_one( a );
>> std::cout << a.x << '\n';
>> }
>>
>>
>> This code is clearly in violation of the standard [9.3.2/2]:
>>
>> In a const member function, the object for which the function is
>> called is accessed through a const access path; [...][/color]
>
> Which part do you think is in violation? I don't believe 9.3.2/2
> has anything to do with it. What happens here is a violation of the
> subclause 8.5.3/5 that essentially says that a reference to non-const
> object cannot be initialised with an object if its 'cv-qualifiers'
> are stronger than that of the reference. A diagnostic is required
> according to 1.4.[/color]

I wasn't aware of [12.3.2]. Since my compiler didn't complain, I was under
the impression that the conversion was responsible for the initialization
of the X & from the const X object. In that case, a violation of [9.3.2/2]
would happen since the code modifies a const object.

However, I think you are right that the conversion function is immaterial
and that the code is invalid for the reasons you stated.
[color=blue][color=green]
>> However, I wonder whether diagnostics for this violation is required[/color]
>
> Yes.
>[color=green]
>> -- on my machine, the code compiles but the program segfaults and I am
>> considering submitting a bug report to the compiler vendor.
>>
>> Can someone give me chapter and verse on this?[/color]
>
> I have, I hope.[/color]

Yes you have. Thanks a lot.


Best

Kai-Uwe Bux

re: Is diagnostics of const violation required

Kai-Uwe Bux posted:
[color=blue]
> Please consider:
>
> struct X {
>
> int x;
>
> X ( int i = 0 )
> : x ( i )
> {}
>
> operator X & ( void ) const {
> return ( *this );
> }
>
> };
>
> void add_one ( X & ref ) {
> ++ ref.x;
> }
>
> #include <iostream>
>
> int main ( void ) {
> X const a ( 2 );
> add_one( a );
> std::cout << a.x << '\n';
> }
>
>
> This code is clearly in violation of the standard [9.3.2/2]:
>
> In a const member function, the object for which the function is
> called is accessed through a const access path; [...]
>
>
> However, I wonder whether diagnostics for this violation is required --
> on my machine, the code compiles but the program segfaults and I am
> considering submitting a bug report to the compiler vendor.
>
> Can someone give me chapter and verse on this?
>
>
> Thanks
>
> Kai-Uwe Bux[/color]


I wrote a thread recently entitled "This is ridiculous!" which deals with
the same thing. Basically, some compilers are retarded and only give a
warning if you do the following:

std::string const a;

std::string &b = a;


-Tomás

re: Is diagnostics of const violation required

Tomás wrote:[color=blue]
> [...]
> I wrote a thread recently entitled "This is ridiculous!" which [...][/color]

....which was a huge waste of bandwidth if you ask me...

re: Is diagnostics of const violation required

Tomás wrote:
[color=blue]
> Kai-Uwe Bux posted:
>[color=green]
>> Please consider:
>>
>> struct X {
>>
>> int x;
>>
>> X ( int i = 0 )
>> : x ( i )
>> {}
>>
>> operator X & ( void ) const {
>> return ( *this );
>> }
>>
>> };
>>
>> void add_one ( X & ref ) {
>> ++ ref.x;
>> }
>>
>> #include <iostream>
>>
>> int main ( void ) {
>> X const a ( 2 );
>> add_one( a );
>> std::cout << a.x << '\n';
>> }
>>[/color][/color]
[snip][color=blue]
>
> I wrote a thread recently entitled "This is ridiculous!" which deals with
> the same thing. Basically, some compilers are retarded and only give a
> warning if you do the following:
>
> std::string const a;
>
> std::string &b = a;[/color]


I would be happy if I got a warning. The code I showed compiled without any
diagnostic output at the highest warning level that my compiler allows. By
and large, the standard only requires "diagnostics" and is silent about
their particular wording, e.g., whether something is labelled and error
message or a warning. Since I got nothing, it's a bug in the compiler.
Otherwise, it may or may not be a bug, depending on the documentation of
the compiler.


Best

Kai-Uwe Bux

re: Is diagnostics of const violation required

Kai-Uwe Bux wrote:[color=blue]
> Tomás wrote:
> [snip]
>[color=green]
>>I wrote a thread recently entitled "This is ridiculous!" which [...][/color]
>
> I would be happy if I got a warning. [...]
> Since I got nothing, it's a bug in the compiler.
> [...][/color]

Please don't start again. The other thread has gone on long enough and
recently enough to justify another one on the same essential topic. If
you would like to continue the discussion [whether it's a bug or not
a bug and what diagnostic is required and what it should be marked as],
please join that thread and contribute. At least others will have
an opportunity to ignore it easier. Thanks!

V
--
Please remove capital As from my address when replying by mail

re: Is diagnostics of const violation required

Victor Bazarov wrote:
[color=blue]
> Kai-Uwe Bux wrote:[color=green]
>> Tomás wrote:
>> [snip]
>>[color=darkred]
>>>I wrote a thread recently entitled "This is ridiculous!" which [...][/color]
>>
>> I would be happy if I got a warning. [...]
>> Since I got nothing, it's a bug in the compiler.
>> [...][/color]
>
> Please don't start again. The other thread has gone on long enough and
> recently enough to justify another one on the same essential topic. If
> you would like to continue the discussion [whether it's a bug or not
> a bug and what diagnostic is required and what it should be marked as],
> please join that thread and contribute. At least others will have
> an opportunity to ignore it easier. Thanks![/color]

I have no intention of going on in that direction. The other thread was
about wether a warning is good enough. I have no opinion on that. I just
wanted to know whether (any) diagnosics is required for my code. It is. I
am satisfied with the information I got (from you! thanks again). As far as
I am concerned, this thread is finished.


Best

Kai-Uwe Bux