emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 6e2e7265a04: Prefer static switch-case checking in pdumper


From: Stefan Kangas
Subject: Re: master 6e2e7265a04: Prefer static switch-case checking in pdumper
Date: Sun, 26 Jan 2025 14:43:30 -0600

Eli Zaretskii <eliz@gnu.org> writes:

>> Auto-Submitted: auto-generated
>> Date: Sun, 26 Jan 2025 14:10:18 -0500 (EST)
>> From: Stefan Kangas <stefankangas@gmail.com>
>>
>> branch: master
>> commit 6e2e7265a04f63f482db7fbdfd8e2519d8bfe03e
>> Author: Stefan Kangas <stefankangas@gmail.com>
>> Commit: Stefan Kangas <stefankangas@gmail.com>
>>
>>     Prefer static switch-case checking in pdumper
>>
>>     * src/pdumper.c (dump_fwd, dump_symbol, dump_drain_cold_data)
>>     (dump_do_fixup, dump_anonymous_allocate_w32)
>>     (dump_anonymous_allocate_posix, dump_map_file_w32, dump_map_file_posix)
>>     (dump_do_emacs_relocation): Remove default clauses to allow static
>>     checking using -Wswitch.
>
> This causes a compiler warning in a non-native-comp build:
>
>   pdumper.c: In function 'dump_drain_cold_data':
>   pdumper.c:3575:7: warning: enumeration value 'COLD_OP_NATIVE_SUBR' not 
> handled in switch [-Wswitch]
>    3575 |       switch (op)
>       |       ^~~~~~

Thanks, I didn't test that configuration.  This already is an example of
the usefulness of moving this to static checking, I think.

> We are using COLD_OP_NATIVE_SUBR inconsistently: on the one hand it is
> defined unconditionally in the enumeration, and used unconditionally
> in dump_subr; OTOH it is used in dump_drain_cold_data only in the
> native-comp build.  Which one do we want: define and use it in the
> code unconditionally, or only if HAVE_NATIVE_COMP?  If we want static
> checks for switch values, we should decide either or.

Agreed.  In dump_subr, it is used only if non_primitive is true, but in
!HAVE_NATIVE_COMP, it is always false.  So I installed a fix that ifdefs
that stuff out, silencing the warning (commit aec9e661787).  I didn't
check, but I don't expect that this will make a difference on the
generated code in -Og and higher.

Please clean it up if you see a better way to do it.

I'm copying in Andrea, in case I missed something.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]