Fixes for gcc 14

[borine]

I've just completely rebuilt my development machine with ubuntu 25.04, and now find some bluez-alsa build errors. This PR fixes the build (with all codecs and utilities enabled).

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :warning: Please upload report for BASE (master@6ccf455). Learn more about missing BASE report. :warning: Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##             master     #768   +/-   ##
=========================================
  Coverage          ?   70.47%           
=========================================
  Files             ?      101           
  Lines             ?    16751           
  Branches          ?     2639           
=========================================
  Hits              ?    11805           
  Misses            ?     4830           
  Partials          ?      116           

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[macmpi]

FWIW Alpine edge branch has moved to GCC 15 (heading to Alpine 3.23), and reports bluez-alsa 4.3.1 (for now) as one of many packages failing to rebuild. Have not checked the details yet, nor if these changes address all issues.

[borine]

reports bluez-alsa 4.3.1 (for now) as one of many packages failing to rebuild.

As noted in https://gcc.gnu.org/gcc-15/porting_to.html the C23 standard makes some significant semantic changes to existing syntax, and this has a widespread impact over many of the dependencies of BlueALSA. So all those dependencies will have to be updated before BlueALSA can be compiled, even before we consider any necessary changes to the BlueALSA code.

In the interim, if anyone is building BlueALSA on a system with gcc 15, a quick workaround is to add CFLAGS="-std=gnu17" to the make command line.

[borine]

I don't have gcc15, but FWIW I've just tried compiling this branch with gcc14 in c23 mode, using

make CFLAGS="-std=gnu23 -Wall -Wextra -Werror -Wshadow -02"

and it fails when compiling utils/rfcomm/rfcomm.c because of a warning from the libreadline header. The error message is:

utils/rfcomm/rfcomm.c:257:52: error: zero-length gnu_printf format string [-Werror=format-zero-length]
  257 |                                         rl_message("");
      |                                                    ^~

I can get it to compile cleanly by applying this patch:

diff --git a/utils/rfcomm/rfcomm.c b/utils/rfcomm/rfcomm.c
index 7a5a3fb..3d3c89d 100644
--- a/utils/rfcomm/rfcomm.c
+++ b/utils/rfcomm/rfcomm.c
@@ -254,7 +254,7 @@ usage:
 			if ((ret = read(rfcomm_fd, buffer, sizeof(buffer) - 1)) <= 0) {
 				if (output_is_tty) {
 					rl_replace_line("disconnected", 0);
-					rl_message("");
+					rl_message("%s", "");
 					rl_redisplay();
 				}
 				break;

and then compiling with:

make CFLAGS="-std-c23 -Wall -Wextra -Werror -Wshadow -02 -DHAVE_STDARG_H"

The extra define is to force libreadline to use a std c compliant declaration for rl_message(). Perhaps that is a problem with ubuntu's packaging of libreadline and may possibly be fixed when ubuntu moves to gcc 15.

[arkq]

and reports bluez-alsa 4.3.1 (for now) as one of many packages failing to rebuild. and it fails when compiling utils/rfcomm/rfcomm.c because of a warning from the libreadline header.

Yes, that's the only error that I can see (on Ubuntu 24.04 using upstream gcc-15). However, I guess that the problem is on the libreadline side, because is should be valid to call rl_message("some const string")...

@borine as for -Wclobbered, I wonder whether it would be possible to rearrange the code so the compiler will not produce any clobbered warnings... I've seen this warning since long time ago (only when building with -O2 though), but since it was not occurring on CI I've just ignored it. There were more warnings like that, but I've "fixed" them by changing slightly the place where some variables are defined or used (in respect to pthread_cleanup_push).

[borine]

it would be possible to rearrange the code so the compiler will not produce any clobbered warnings...

You are correct. I've rebased to current master and re-ordered the lines in the affected functions to get rid of the warnings.

should be valid to call rl_message("some const string")...

Yes, but the prototype for that function is annotated:

extern int rl_message (const char *, ...)  __rl_attribute__((__format__ (printf, 1, 2)));

and that attribute causes gcc to enforce the same diagnostics rules as for printf(), and with -std=gnu23 those rules issue a warning if the first argument to printf() is the empty string. So we can call rl_message("some const string") only if that const string is not empty.

I'm not sure what line is for anyway? bluealsa-rfcomm seems to work fine when I just comment out that call to rl_message("").

[arkq]

I'm not sure what line is for anyway? bluealsa-rfcomm seems to work fine when I just comment out that call to rl_message("").

There is small difference (maybe it can be achieved in a different way, though) where the "disconnected" message looks like a user command:

with rl_message("")

$ bluealsa-rfcomm /org/bluealsa/hci0/dev_04_5D_4B_ED_D7_00 
> AT+IPHONEACCEV=1,1,6
04:5D:4B:ED:D7:00> RING
disconnected

without rl_message("")

$ bluealsa-rfcomm /org/bluealsa/hci0/dev_04_5D_4B_ED_D7_00 
> AT+XAPL=054C-0C75-0452,0
04:5D:4B:ED:D7:00> RING
04:5D:4B:ED:D7:00> disconnected

EDIT: How to reproduce:

1. Connect device with e.g. bluetoothctl
2. Run bluealsa-rfcomm
3. Disconnect device with e.g. bluetoothctl

[borine]

OK, thanks for the explanation, I had not spotted that difference. So rl_message("") is used only for its accidental side-effect of overwriting the prompt buffer (the docs say to save the prompt before using rl_message() and then restore it afterwards). I've pushed a new commit which explicitly clears the prompt, which I think is a more readable solution.

[arkq]

I've squashed all commits plus two small changes:

• removed check for stdarg.h - this is C11 feature and we are checking for C11 support
• removed PKG_CHECK_MODULES([SYSTEMD], [systemd >= 200]) since we are not linking with libsystemd and there is no systemd pkg-config on Debian 13 (it's called libsystemd)