Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: What a bug
Date: Tue, 05 Sep 2023 03:04:44 -0700
Organization: None to speak of
Lines: 88
Message-ID: <87v8cp3phf.fsf@nosuchdomain.example.com>
References: <uct7ch$3uope$1@dont-email.me> <ud08l2$i4aq$1@dont-email.me> <ud2t4q$12vk6$1@dont-email.me> <87pm2y6af4.fsf@nosuchdomain.example.com> <ud6qom$1tniq$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: dont-email.me; posting-host="d633fa9147221aa5a66d8a19b6f926fe"; logging-data="2040859"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+bMa9tAZPBm7NtqmVkXEzF"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:WeasPzFMx/iuNnbOwPi0xnO5poU= sha1:zZccEZo5WchUjJtnQk+/gzc+GGE=
Xref: csiph.com comp.lang.c++:91544

jak <nospam@please.ty> writes:
[...]
> I probably expressed myself badly. I agree with what you answered and
> everything is clear to me. What I am contesting is the part where you
> say "...may or may not be stored at the same memory location" because
> that would mean that a program like this:
>
> #include <iostream>
>
> int main()
> {
>     auto eif = [] (bool t) {
>         std::cout << ( t ? "equal" : "not equal" ) << std::endl;
>     };
>
>     char const *sp = "hello";
>     char sl[] = "hello";
>
>     eif( sp == sp );
>
>     eif( "hello" == sp );
>
>     eif( "hello" == "hello" );
>
>     eif( "hello" == sl );
>
>     return 0;
> }
>
> which has this as a result:
>
> equal
> equal
> equal
> not equal
>
> could give different results depending on how the compiler acts when
> deciding where to store strings (because here we are comparing
> pointers).

Yes, that's exactly what it means.

>            I simply think that different objects shouldn't be lumped
> together just because they contain the same things, otherwise I would
> have declared a single string and would have used its pointer around the
> code. Pointers are for that too. it is my opinion that the program I
> posted should have this as a result:
>
> equal
> not equal
> not equal
> not equal

I suggest the language standard is more relevant than either of our
opinions.

C++17 5.13.5 [lex.string] paragraph 16:

    Evaluating a *string-literal* results in a string literal
    object with static storage duration, initialized from the given
    characters as specified above. Whether all string literals are
    distinct (that is, are stored in nonoverlapping objects) and
    whether successive evaluations of a *string-literal* yield the
    same or a different object is unspecified. [ Note: The effect
    of attempting to modify a string literal is undefined. — end
    note ]

I believe that all versions of C and C++ have similar rules.

Which means that ("hello" == "hello") may be either true or false, and
an implementation is not required to document which.

In your program above, this:
    sp == sp
is guaranteed to be true, these:    
    "hello" == sp
    "hello" == "hello"
may be either true or false, and this:
    "hello" == sl
is false because sl is distinct and explicitly defined array object.

If you compile your program with clang++, it prints warnings on all four
comparisons.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */