Doubts regarding the issue (bug 62181)

Doubts regarding the issue (bug 62181)

[Krishna Narayanan]

Respected Sir/Madam,
I have been working on an issue (bug 62181) [C/C++] Expected new warning:
"adding 'char' to a string does not append to the string"
[-Wstring-plus-int].This is asking for a warning being added to gcc for
such a case.Not using concat and indexing which were mentioned earlier as a
solution to the warning I tried the example given in  https://godbolt.org/
and was trying different permutations of addresses and pointers in clang
and gcc (trunk), I am not sure but I tried '-w' in compiler flags and it
worked fine for both clang and gcc ,it did not show any warning.I am not
sure what exactly did the flag do but the warning arises in other
optimizations.
I had a doubt regarding the output of a slightly modified code in which I
have taken a character instead of int ,
#include <stdio.h>
 char ch ='o';
char bar()  {
return 1;
 }
int foobar()  {
 return ch; }
 int main()
{   const char* a = "aa";
 const char *b = "bb" + bar();
const char *c = "cc" + foobar();
  printf("%s, %s, %s", a, b, c);
 return 0 ;
}
In the output I get zR when I did it with gcc and get unicode when done
with g++10.1 .I did not understand how does this output arise.Can you
please help me out with this?
Please correct me if I am going wrong somewhere.
Hoping for your reply soon.
Thanks and Regards,
Krishna Narayanan.

Re: Doubts regarding the issue (bug 62181)

[Jonathan Wakely]

On Thu, 3 Feb 2022 at 18:46, Krishna Narayanan via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> Respected Sir/Madam,
> I have been working on an issue (bug 62181) [C/C++] Expected new warning:
> "adding 'char' to a string does not append to the string"
> [-Wstring-plus-int].This is asking for a warning being added to gcc for
> such a case.Not using concat and indexing which were mentioned earlier as a
> solution to the warning I tried the example given in  https://godbolt.org/
> and was trying different permutations of addresses and pointers in clang
> and gcc (trunk), I am not sure but I tried '-w' in compiler flags and it
> worked fine for both clang and gcc ,it did not show any warning.I am not
> sure what exactly did the flag do but the warning arises in other
> optimizations.
> I had a doubt regarding the output of a slightly modified code in which I
> have taken a character instead of int ,
> #include <stdio.h>
>  char ch ='o';
> char bar()  {
> return 1;
>  }
> int foobar()  {
>  return ch; }
>  int main()
> {   const char* a = "aa";
>  const char *b = "bb" + bar();
> const char *c = "cc" + foobar();
>   printf("%s, %s, %s", a, b, c);
>  return 0 ;
> }
> In the output I get zR when I did it with gcc and get unicode when done
> with g++10.1 .I did not understand how does this output arise.Can you
> please help me out with this?

What do you mean you get "unicode"?

"bb" + bar() is equivalent to "bb" + (int)bar()
which is equivalent to "bb" + 1

"cc" + foobar() is equivalent to "cc" + (int)'o'
which has undefined behaviour, because it produces a pointer that is
outside the array of three chars "cc\0".
It will print whatever happens to be in memory approximately 100 bytes
after the "cc" string literal. That is random garbage of some kind.

The precise behaviour you get from this undefined behaviour is not
important, the point is that it's undefined behaviour, and that's why
a warning would be useful.

Re: Doubts regarding the issue (bug 62181)

[Jonathan Wakely]

On Thu, 3 Feb 2022 at 18:46, Krishna Narayanan via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> Respected Sir/Madam,
> I have been working on an issue (bug 62181) [C/C++] Expected new warning:
> "adding 'char' to a string does not append to the string"
> [-Wstring-plus-int].This is asking for a warning being added to gcc for
> such a case.Not using concat and indexing which were mentioned earlier as a
> solution to the warning I tried the example given in  https://godbolt.org/
> and was trying different permutations of addresses and pointers in clang
> and gcc (trunk), I am not sure but I tried '-w' in compiler flags and it
> worked fine for both clang and gcc ,it did not show any warning.

-w means disables all warnings, so of course you didn't get any
warnings when you use it!

See the GCC manual.
https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

Re: Doubts regarding the issue (bug 62181)

[Krishna Narayanan]

Respected sir,
I went through the compiler flags and mistake was on my side using the 'w'
suppressor flag to remove the warnings without knowing it.Thanks for the
docs and reply.

By unicode I meant there is a question mark inside a diagonal.(unicode
error symbol) Sir this is perspective with the third print that is
"cc"+foobar() where I get zR for gcc (9.3.0) and unicode for g++-10.1.
I got your point regarding the garbage value and to throw a warning is
better than to get such an unwanted output.

I thought there would be a specific reason why it had come because in const
char *a ="aa"+'operator/number' i.e when I add some character with some
change it gives blank space for numbers and operators, where as for
addition of 'a' in *a= "aa"+'a' it give 4 times the unicode symbol but for
*c="cc" +'c' and *b="bb"+'b' gives a space as output.Yes it has been quite
unpredictable and undefined behaviour.

So has the request of warning been granted in the upcoming gcc version!?

Thanks and regards,
Krishna Narayanan.

On Fri, Feb 4, 2022 at 2:18 AM Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:

> On Thu, 3 Feb 2022 at 18:46, Krishna Narayanan via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
> >
> > Respected Sir/Madam,
> > I have been working on an issue (bug 62181) [C/C++] Expected new warning:
> > "adding 'char' to a string does not append to the string"
> > [-Wstring-plus-int].This is asking for a warning being added to gcc for
> > such a case.Not using concat and indexing which were mentioned earlier
> as a
> > solution to the warning I tried the example given in
> https://godbolt.org/
> > and was trying different permutations of addresses and pointers in clang
> > and gcc (trunk), I am not sure but I tried '-w' in compiler flags and it
> > worked fine for both clang and gcc ,it did not show any warning.I am not
> > sure what exactly did the flag do but the warning arises in other
> > optimizations.
> > I had a doubt regarding the output of a slightly modified code in which I
> > have taken a character instead of int ,
> > #include <stdio.h>
> >  char ch ='o';
> > char bar()  {
> > return 1;
> >  }
> > int foobar()  {
> >  return ch; }
> >  int main()
> > {   const char* a = "aa";
> >  const char *b = "bb" + bar();
> > const char *c = "cc" + foobar();
> >   printf("%s, %s, %s", a, b, c);
> >  return 0 ;
> > }
> > In the output I get zR when I did it with gcc and get unicode when done
> > with g++10.1 .I did not understand how does this output arise.Can you
> > please help me out with this?
>
> What do you mean you get "unicode"?
>
> "bb" + bar() is equivalent to "bb" + (int)bar()
> which is equivalent to "bb" + 1
>
> "cc" + foobar() is equivalent to "cc" + (int)'o'
> which has undefined behaviour, because it produces a pointer that is
> outside the array of three chars "cc\0".
> It will print whatever happens to be in memory approximately 100 bytes
> after the "cc" string literal. That is random garbage of some kind.
>
> The precise behaviour you get from this undefined behaviour is not
> important, the point is that it's undefined behaviour, and that's why
> a warning would be useful.
>

Re: Doubts regarding the issue (bug 62181)

[Jonathan Wakely]

On Fri, 4 Feb 2022 at 11:36, Krishna Narayanan via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> Respected sir,
> I went through the compiler flags and mistake was on my side using the 'w'
> suppressor flag to remove the warnings without knowing it.Thanks for the
> docs and reply.
>
> By unicode I meant there is a question mark inside a diagonal.(unicode
> error symbol)

That means it's printing garbage characters that can't be processed as
valid UTF-8, so explicitly NOT unicode. Calling that unicode is very
confusing.


> Sir this is perspective with the third print that is
> "cc"+foobar() where I get zR for gcc (9.3.0) and unicode for g++-10.1.
> I got your point regarding the garbage value and to throw a warning is
> better than to get such an unwanted output.
>
> I thought there would be a specific reason why it had come because in const
> char *a ="aa"+'operator/number' i.e when I add some character with some
> change it gives blank space for numbers and operators, where as for
> addition of 'a' in *a= "aa"+'a' it give 4 times the unicode symbol but for
> *c="cc" +'c' and *b="bb"+'b' gives a space as output.Yes it has been quite
> unpredictable and undefined behaviour.

The nature of undefined behaviour is to be unpredictable.

Compile with -fsanitize=address to get a lot more detail about what
your buggy code is doing. You'll see an explanation of where the
pointer arithmetic goes, and what's in memory there.



>
> So has the request of warning been granted in the upcoming gcc version!?

Do you get any warning when compiling your buggy example with gcc? I don't.

However, when I compile it with clang I get:

oflow.c:10:23: warning: adding 'char' to a string does not append to
the string [-Wstring-plus-int]
const char *b = "bb" + bar();
                ~~~~~^~~~~~~
oflow.c:10:23: note: use array indexing to silence this warning
const char *b = "bb" + bar();
                     ^
                &    [      ]
oflow.c:11:22: warning: adding 'int' to a string does not append to
the string [-Wstring-plus-int]
const char *c = "cc" + foobar();
               ~~~~~^~~~~~~~~~
oflow.c:11:22: note: use array indexing to silence this warning
const char *c = "cc" + foobar();
                    ^
               &    [         ]
2 warnings generated.

Re: Doubts regarding the issue (bug 62181)

[Krishna Narayanan]

Respected Sir,
I am getting the same warning for clang and no warning for gcc.
I did try the code with fsanitize=address for a detailed note.It is a
global buffer overflow,This is the exact error:
==18062==ERROR: AddressSanitizer: global-buffer-overflow on address
0x5607c52ff66f at pc 0x5607c523468b bp 0x7ffc44b71dd0 sp 0x7ffc44b71548
READ of size 1 at 0x5607c52ff66f thread T0
    #0 0x5607c523468a in printf_common(void*, char const*, __va_list_tag*)
(/home/krishna/xyz/str+0x8268a)
    #1 0x5607c52356ac in vprintf (/home/krishna/xyz/str+0x836ac)
    #2 0x5607c52357a6 in printf (/home/krishna/xyz/str+0x837a6)
    #3 0x5607c52e6a9d in main (/home/krishna/xyz/str+0x134a9d)
    #4 0x7f6ebf30e0b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #5 0x5607c51ba41d in _start (/home/krishna/xyz/str+0x841d)
0x5607c52ff66f is located 36 bytes to the right of global variable '*.LC3'
defined in 'str.c' (0x5607c52ff640) of size 11
  '*.LC3' is ascii string '%s, %s, %s'
SUMMARY: AddressSanitizer: global-buffer-overflow
(/home/krishna/xyz/str+0x8268a) in printf_common(void*, char const*,
__va_list_tag*)
Shadow bytes around the buggy address:
  0x0ac178a57e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac178a57e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac178a57e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac178a57ea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac178a57eb0: 03 f9 f9 f9 f9 f9 f9 f9 03 f9 f9 f9 f9 f9 f9 f9
=>0x0ac178a57ec0: 03 f9 f9 f9 f9 f9 f9 f9 00 03 f9 f9 f9[f9]f9 f9
  0x0ac178a57ed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac178a57ee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac178a57ef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac178a57f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac178a57f10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==18062==ABORTING
Thanks and Regards,
Krishna Narayanan.

On Fri, Feb 4, 2022 at 5:43 PM Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:

> On Fri, 4 Feb 2022 at 11:36, Krishna Narayanan via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
> >
> > Respected sir,
> > I went through the compiler flags and mistake was on my side using the
> 'w'
> > suppressor flag to remove the warnings without knowing it.Thanks for the
> > docs and reply.
> >
> > By unicode I meant there is a question mark inside a diagonal.(unicode
> > error symbol)
>
> That means it's printing garbage characters that can't be processed as
> valid UTF-8, so explicitly NOT unicode. Calling that unicode is very
> confusing.
>
>
> > Sir this is perspective with the third print that is
> > "cc"+foobar() where I get zR for gcc (9.3.0) and unicode for g++-10.1.
> > I got your point regarding the garbage value and to throw a warning is
> > better than to get such an unwanted output.
> >
> > I thought there would be a specific reason why it had come because in
> const
> > char *a ="aa"+'operator/number' i.e when I add some character with some
> > change it gives blank space for numbers and operators, where as for
> > addition of 'a' in *a= "aa"+'a' it give 4 times the unicode symbol but
> for
> > *c="cc" +'c' and *b="bb"+'b' gives a space as output.Yes it has been
> quite
> > unpredictable and undefined behaviour.
>
> The nature of undefined behaviour is to be unpredictable.
>
> Compile with -fsanitize=address to get a lot more detail about what
> your buggy code is doing. You'll see an explanation of where the
> pointer arithmetic goes, and what's in memory there.
>
>
>
> >
> > So has the request of warning been granted in the upcoming gcc version!?
>
> Do you get any warning when compiling your buggy example with gcc? I don't.
>
> However, when I compile it with clang I get:
>
> oflow.c:10:23: warning: adding 'char' to a string does not append to
> the string [-Wstring-plus-int]
> const char *b = "bb" + bar();
>                 ~~~~~^~~~~~~
> oflow.c:10:23: note: use array indexing to silence this warning
> const char *b = "bb" + bar();
>                      ^
>                 &    [      ]
> oflow.c:11:22: warning: adding 'int' to a string does not append to
> the string [-Wstring-plus-int]
> const char *c = "cc" + foobar();
>                ~~~~~^~~~~~~~~~
> oflow.c:11:22: note: use array indexing to silence this warning
> const char *c = "cc" + foobar();
>                     ^
>                &    [         ]
> 2 warnings generated.
>