Re: Doubts regarding the issue (bug 62181)

[Krishna Narayanan <krishnanarayanan132002@gmail.com>]

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.
>