warnings compiling emacs28 with gcc 12.1

warnings compiling emacs28 with gcc 12.1

[Jose A. Ortega Ruiz]

Hi,

I'm sending this email to devel because i'm not sure this is to be
considered a bug.

I compiled today the emacs28 branch with gcc version
'gcc (Debian 12.1.0-7) 12.1.0' and configured with

   ./configure --with-x-toolkit=no

and i am seeing several new (to me) compilation warnings. 

Some of them are about possible uses of null pointers, like this one:

   In file included from intervals.c:45:
   intervals.c: In function ‘graft_intervals_into_buffer’:
   intervals.h:101:29: warning: potential null pointer dereference [-Wnull-dereference]
     101 | #define TOTAL_LENGTH(i) ((i)->total_length)
         |                         ~~~~^~~~~~~~~~~~~~~

and there's another one about free that looks a bit scary:

   alloc.c: In function ‘lisp_free’:
   alloc.c:1052:3: warning: pointer ‘block’ used after ‘free’ [-Wuse-after-free]
    1052 |   mem_delete (mem_find (block));
         |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   alloc.c:1050:3: note: call to ‘free’ here
    1050 |   free (block);
         |   ^~~~~~~~~~~~

There are also several out-of-bounds access in xdisp.c that look like
this one:

   xdisp.c: In function ‘append_space_for_newline’:
   xdisp.c:22011:7: warning: ‘memset’ offset [2352, 2359] from the object at ‘it’ is out of the bounds of referenced subobject ‘charpos’ with type ‘long int’ at offset 2344 [-Warray-bounds]
   22011 |       memset (&it->position, 0, sizeof it->position);
         |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   In file included from composite.h:29,
                    from xdisp.c:441:
   dispextern.h:214:13: note: subobject ‘charpos’ declared here
     214 |   ptrdiff_t charpos;
         |             ^~~~~~~

And so on.  I guess the whole list is easily reproducible by anyone
compiling git gcc 12.1 in a GNU/Linux system, so i'm not sending it in
full.  I can do that in a bug report if you think it's needed.

Apologies if all this is already well-known/spurious.

Thanks,
jao
-- 
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. - Don Knuth

Re: warnings compiling emacs28 with gcc 12.1

[Eli Zaretskii]

> From: "Jose A. Ortega Ruiz" <jao@gnu.org>
> Date: Thu, 28 Jul 2022 04:32:39 +0100
> 
> I compiled today the emacs28 branch with gcc version
> 'gcc (Debian 12.1.0-7) 12.1.0' and configured with

The lesson to be learned here is never use NN.1 version of GCC with
too high level of warnings: you get a lot of noise due to bugs in an
immature GCC version.

>    In file included from intervals.c:45:
>    intervals.c: In function ‘graft_intervals_into_buffer’:
>    intervals.h:101:29: warning: potential null pointer dereference [-Wnull-dereference]
>      101 | #define TOTAL_LENGTH(i) ((i)->total_length)
>          |                         ~~~~^~~~~~~~~~~~~~~

Nonsense.

> and there's another one about free that looks a bit scary:
> 
>    alloc.c: In function ‘lisp_free’:
>    alloc.c:1052:3: warning: pointer ‘block’ used after ‘free’ [-Wuse-after-free]
>     1052 |   mem_delete (mem_find (block));
>          |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    alloc.c:1050:3: note: call to ‘free’ here
>     1050 |   free (block);
>          |   ^~~~~~~~~~~~

Another nonsense.  Look in mem_find, and you will see that it uses its
argument as just a number, it never dereferences it.

> There are also several out-of-bounds access in xdisp.c that look like
> this one:
> 
>    xdisp.c: In function ‘append_space_for_newline’:
>    xdisp.c:22011:7: warning: ‘memset’ offset [2352, 2359] from the object at ‘it’ is out of the bounds of referenced subobject ‘charpos’ with type ‘long int’ at offset 2344 [-Warray-bounds]
>    22011 |       memset (&it->position, 0, sizeof it->position);
>          |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    In file included from composite.h:29,
>                     from xdisp.c:441:
>    dispextern.h:214:13: note: subobject ‘charpos’ declared here
>      214 |   ptrdiff_t charpos;
>          |             ^~~~~~~

I see no problem there.

> And so on.  I guess the whole list is easily reproducible by anyone
> compiling git gcc 12.1 in a GNU/Linux system, so i'm not sending it in
> full.  I can do that in a bug report if you think it's needed.
> 
> Apologies if all this is already well-known/spurious.

I wouldn't worry about these.

Thanks.

Re: warnings compiling emacs28 with gcc 12.1

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> and there's another one about free that looks a bit scary:
>> 
>>    alloc.c: In function ‘lisp_free’:
>>    alloc.c:1052:3: warning: pointer ‘block’ used after ‘free’ [-Wuse-after-free]
>>     1052 |   mem_delete (mem_find (block));
>>          |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>    alloc.c:1050:3: note: call to ‘free’ here
>>     1050 |   free (block);
>>          |   ^~~~~~~~~~~~
>
> Another nonsense.  Look in mem_find, and you will see that it uses its
> argument as just a number, it never dereferences it.

The warning is not about dereferencing the pointer.

Re: warnings compiling emacs28 with gcc 12.1

[Jose A. Ortega Ruiz]

On Thu, Jul 28 2022, Eli Zaretskii wrote:

>> From: "Jose A. Ortega Ruiz" <jao@gnu.org>
>> Date: Thu, 28 Jul 2022 04:32:39 +0100
>> 
>> I compiled today the emacs28 branch with gcc version
>> 'gcc (Debian 12.1.0-7) 12.1.0' and configured with
>
> The lesson to be learned here is never use NN.1 version of GCC with
> too high level of warnings: you get a lot of noise due to bugs in an
> immature GCC version.

Fair enough.  A curious fact is that the master branch compiles cleanly
with the same GCC version, without any warning at all in fact.  I guess
someone already took the time to pacify non-sense warnings.

[...]

> I wouldn't worry about these.

I won't, thanks.

jao
-- 
Not far from the invention of fire must rank the invention of doubt.
-Thomas Henry Huxley, biologist (1825-1895)

Re: warnings compiling emacs28 with gcc 12.1

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 28 Jul 2022 19:12:00 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> and there's another one about free that looks a bit scary:
> >> 
> >>    alloc.c: In function ‘lisp_free’:
> >>    alloc.c:1052:3: warning: pointer ‘block’ used after ‘free’ [-Wuse-after-free]
> >>     1052 |   mem_delete (mem_find (block));
> >>          |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>    alloc.c:1050:3: note: call to ‘free’ here
> >>     1050 |   free (block);
> >>          |   ^~~~~~~~~~~~
> >
> > Another nonsense.  Look in mem_find, and you will see that it uses its
> > argument as just a number, it never dereferences it.
> 
> The warning is not about dereferencing the pointer.

What other problems could be caused by using it after freeing it?

Re: warnings compiling emacs28 with gcc 12.1

[Lars Ingebrigtsen]

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

> Fair enough.  A curious fact is that the master branch compiles cleanly
> with the same GCC version, without any warning at all in fact.  I guess
> someone already took the time to pacify non-sense warnings.

Yes, they were fixed on the trunk by:

commit 0f731c49e6a8ccf3aa4c30c3f8ca82ed0a2cefb7
Author:     Paul Eggert <eggert@cs.ucla.edu>
AuthorDate: Thu May 12 17:01:10 2022 -0700

    Pacify GCC 12 in default developer build

For instance:

    * src/term.c (Fsuspend_tty): Don’t look at a pointer after freeing
    it, even just to test it for equality with some other pointer, as
    this has undefined behavior in C and GCC 12 diagnoses this.

Re: warnings compiling emacs28 with gcc 12.1

[Andreas Schwab]

On Jul 28 2022, Eli Zaretskii wrote:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Thu, 28 Jul 2022 19:12:00 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> and there's another one about free that looks a bit scary:
>> >> 
>> >>    alloc.c: In function ‘lisp_free’:
>> >>    alloc.c:1052:3: warning: pointer ‘block’ used after ‘free’ [-Wuse-after-free]
>> >>     1052 |   mem_delete (mem_find (block));
>> >>          |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >>    alloc.c:1050:3: note: call to ‘free’ here
>> >>     1050 |   free (block);
>> >>          |   ^~~~~~~~~~~~
>> >
>> > Another nonsense.  Look in mem_find, and you will see that it uses its
>> > argument as just a number, it never dereferences it.
>> 
>> The warning is not about dereferencing the pointer.
>
> What other problems could be caused by using it after freeing it?

Evan just reading the value of a pointer after free is undefined.  If
you want to preserve its bit pattern, you need to convert it to an
integer type before the call to free.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: warnings compiling emacs28 with gcc 12.1

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Thu, 28 Jul 2022 19:12:00 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> and there's another one about free that looks a bit scary:
>> >> 
>> >>    alloc.c: In function ‘lisp_free’:
>> >>    alloc.c:1052:3: warning: pointer ‘block’ used after ‘free’ [-Wuse-after-free]
>> >>     1052 |   mem_delete (mem_find (block));
>> >>          |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >>    alloc.c:1050:3: note: call to ‘free’ here
>> >>     1050 |   free (block);
>> >>          |   ^~~~~~~~~~~~
>> >
>> > Another nonsense.  Look in mem_find, and you will see that it uses its
>> > argument as just a number, it never dereferences it.
>> 
>> The warning is not about dereferencing the pointer.
>
> What other problems could be caused by using it after freeing it?

Lars mentioned the reason Paul gave when he fixed the warning.

Another reason is that using a pointer after freeing the pointed object
usually indicates the possibility of future problems, like a
dereference. In general, such a pointer is meaningless as a proper
pointer. If one is using it later as a key (which in itself is a
questionable practice) the right thing is to convert it to a suitable
integral type. Otherwise, it is advisable to forget about a pointer as
soon as its pointed memory becomes invalid.