https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #22 from Alejandro Colomar <alx at kernel dot org> --- (In reply to Wentao Zhang from comment #18) > This produces warnings in kernel defconfig builds and they become errors due > to > CONFIG_WERROR. > > Cases I've observed so far: > > 1. initialization > https://elixir.bootlin.com/linux/v6.10-rc7/source/drivers/pnp/quirks.c#L412 > related definition > https://elixir.bootlin.com/linux/v6.10-rc7/source/include/linux/pnp.h#L293 > 2. initialization > https://elixir.bootlin.com/linux/v6.10-rc7/source/drivers/acpi/nhlt.c#L23 > related definition > https://elixir.bootlin.com/linux/v6.10-rc7/source/include/acpi/actbl.h#L69 > 3. > https://elixir.bootlin.com/linux/v6.10-rc7/source/drivers/acpi/tables.c#L385 > 4. initialization > https://elixir.bootlin.com/linux/v6.10-rc7/source/drivers/acpi/acpica/ > acpredef.h#L187 > related definition > https://elixir.bootlin.com/linux/v6.10-rc7/source/drivers/acpi/acpica/ > aclocal.h#L296 > 5. initialization > https://elixir.bootlin.com/linux/v6.10-rc7/source/drivers/acpi/acpica/ > nsrepair.c#L66 > related definition > https://elixir.bootlin.com/linux/v6.10-rc7/source/drivers/acpi/acpica/ > aclocal.h#L373 > 6. initialization > https://elixir.bootlin.com/linux/v6.10-rc7/source/drivers/acpi/acpica/ > nsrepair2.c#L114 > related definition > https://elixir.bootlin.com/linux/v6.10-rc7/source/drivers/acpi/acpica/ > nsrepair2.c#L28 > 7. > https://elixir.bootlin.com/linux/v6.10-rc7/source/drivers/gpu/drm/display/ > drm_dp_dual_mode_helper.c#L163 > 8. initialization > https://elixir.bootlin.com/linux/v6.10-rc7/source/drivers/power/supply/ > power_supply_sysfs.c#L182 > related definition > https://elixir.bootlin.com/linux/v6.10-rc7/source/drivers/power/supply/ > power_supply_sysfs.c#L26 > 9. https://elixir.bootlin.com/linux/v6.10-rc7/source/fs/proc/task_mmu.c#L648 > > In the "drivers/power/supply/power_supply_sysfs.c" case, > > static struct power_supply_attr power_supply_attrs[] = { > ... > POWER_SUPPLY_ATTR(CHARGE_CONTROL_START_THRESHOLD), > ... > } > > will get expanded to > > [POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD] = { > .prop_name = "CHARGE_CONTROL_START_THRESHOLD", > .attr_name = "j" "\0", > .text_values = ((void *)0), > .text_values_len = 0, > }, > > It still triggers the warning even if "\0" is explicitly specified and the > length is exactly MAX_PROP_NAME_LEN + 1 (31). As Martin questioned in <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116082>, I think this should be warned. You've asked to initialize the array with two null bytes, and you only got one. You were trying to achieve the same thing that now can be achieved by enabling -Wunterminated-string-initialization. I suggest that you now remove the "\0", and rely on the warning. For the cases where you do NOT want a string, you can surround it with pragmas to turn off the warning there. These cases should be minimal, and justified. Or you can do like elfutils did, and use array notation: {'f', 'o', 'o'}; this makes it clear that there's no null byte, and won't trigger the warning.
