`configure` mishandles the default and `--disable-*` forms of the safety options

Bug report

Bug description:

Summary

configure.ac mishandles the safety and slower-safety configure options.

• A default configure invocation reports safety as disabled, although the safety options are intended to be enabled by default.
• --disable-safety enables the safety options instead of disabling them.
• --disable-slower-safety enables the slower safety options instead of disabling them.

The latter two cases are not only incorrect status messages: configure actually enters the corresponding enabled branches and probes the associated compiler options.

Reproduction

Using an out-of-tree build directory:

mkdir build
cd build

Default configuration

../configure

Observed:

checking for --enable-safety... no
checking for --enable-slower-safety... no

Disable safety

../configure --disable-safety

Observed:

checking for --enable-safety... yes
checking whether C compiler accepts -fstack-protector-strong... yes
checking whether C compiler accepts -Wtrampolines... yes
checking whether C compiler accepts -Wimplicit-fallthrough... yes
checking whether C compiler accepts -Werror=format-security... yes
checking whether C compiler accepts -Wbidi-chars=any... yes
checking whether C compiler accepts -Wall... yes
checking for --enable-slower-safety... no

Disable slower safety

../configure --disable-slower-safety

Observed:

checking for --enable-safety... no
checking for --enable-slower-safety... yes
checking whether C compiler accepts -D_FORTIFY_SOURCE=3... yes

Actual Behavior

The resulting behavior is:

Configure invocation	safety	slower-safety
../configure	no	no
../configure --disable-safety	yes	no
../configure --disable-slower-safety	no	yes

In particular, the two --disable-* forms enable the options they are intended to disable.

Expected Behavior

The expected behavior is:

Configure invocation	safety	slower-safety
../configure	yes	no
../configure --enable-safety	yes	no
../configure --disable-safety	no	no
../configure --enable-slower-safety	default value for safety	yes
../configure --disable-slower-safety	default value for safety	no

In particular:

• safety should remain enabled by default unless explicitly disabled.
• --disable-safety should set enable_safety=no and should not execute the safety compiler-option checks.
• --disable-slower-safety should set enable_slower_safety=no and should not execute the slower-safety compiler-option checks.

Cause

The affected declarations are in configure.ac in the AC_ARG_ENABLE([safety], ...) and AC_ARG_ENABLE([slower-safety], ...) blocks.

Their action-if-given branches currently test variables named disable_safety and disable_slower_safety.

For an AC_ARG_ENABLE option, Autoconf represents both forms through the corresponding enable option value:

--enable-safety   -> enableval=yes
--disable-safety  -> enableval=no

Likewise for slower-safety.

The current action blocks do not use that value. Instead, because disable_safety / disable_slower_safety are not the variables carrying the Autoconf option state, the fallback branch selects the enabled state whenever either option is explicitly present.

This causes:

--disable-safety
    -> action-if-given runs
    -> disable_safety is not "yes"
    -> enable_safety=yes

and similarly:

--disable-slower-safety
    -> enable_slower_safety=yes

There is also a separate default-value issue in the safety declaration: its action-if-not-given branch currently selects enable_safety=no, despite the option being intended to be enabled by default.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-156767

Start in configure.ac at the AC_ARG_ENABLE([safety], ...) and AC_ARG_ENABLE([slower-safety], ...) blocks, then reproduce the three listed invocations from an out-of-tree build directory. Compare the generated status and compiler-option checks with the expected table; done means default and explicit enable/disable forms select the documented states without unwanted probes.