Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

curl-compilers.m4: for gcc + want warnings, set gnu89 standard #9542

wants to merge 3 commits into from


Copy link

@bagder bagder commented Sep 20, 2022

To better verify that the code is C89

@bagder bagder added the build label Sep 20, 2022
Copy link

This will be a problem with third-party libraries using features from later standards, like C++ comments, in their public headers. Maybe add it to some CI builds instead?

Copy link
Member Author

bagder commented Sep 20, 2022

yeah, but more importantly this identifies numerous places within libcurl itself that are not proper C89. That was my primary thought with this, to try it out. It might not make sense to land in the short term.

The question also comes down to: are those nits worth fixing if nobody has suffered from any problems with them while we are slowly considering bumping to C99 in a future...

@bagder bagder force-pushed the bagder/gcc-gnu89 branch 2 times, most recently from f51f81a to a4ae62d Compare September 21, 2022 08:00
Copy link
Member Author

bagder commented Sep 21, 2022

I decided they are probably worth fixing because:

If (and this has not been decided yet) we change the requirement to C99 at some point, then whatever is in git before that switch will be the last C89 compliant curl code and it could be worth having that in a fine shape. Compliance wise.

Copy link

monnerat commented Sep 21, 2022

I did the same kind of test locally with:

CFLAGS="... -std=C89 ..."

This exhibited problems fixed (sucessfully) in 6fbf7d3, 9eec754 and c3e634d: no compiler message for the current master.
Of course, not everything was enabled in my local test.

I had to define _XOPEN_SOURCE to enable definition of some library functions. There are configure tests for most of the latter (i.e.: HAVE_FCHMOD), but it seems AC_CHECK_FUNCS does not use our predefined CFLAGS while checking.
A partular case is function kill(): it is used unconditionally by curl but its definition is disabled by -std=C89. There are probably a lot of other external definitions hidden by -std=C89 but re-enabled by -D_XOPEN_SOURCE=700.

As a consequence we might question ourselves if curl's C89 requirement only targets the language or also the libraries.

Copy link

dfandrich commented Sep 21, 2022 via email

Copy link

-D_XOPEN_SOURCE=600 was not enough for me: strndup requires 700.

Copy link

C89 doesn't provide nearly enough of an API to build curl (e.g. sockets)

Agreed: see the comment about kill() above. There might be others.
But the sockets declarations are not conditioned on POSIX/XOPEN, although not in the standard C library. In fact, they were already present in 4.2BSD (1983).

Copy link
Member Author

bagder commented Sep 22, 2022

it's safe to assume that we're talking about language features only.

Yes exactly: language features only. Everything else we can detect and adapt to.

@bagder bagder closed this in b23ce2c Sep 23, 2022
@bagder bagder deleted the bagder/gcc-gnu89 branch September 23, 2022 06:28
vszakats added a commit to vszakats/curl that referenced this pull request Nov 19, 2023
Use `-Wc99-extensions` to warn for non-C89 syntax.

Follow-up to b23ce2c curl#9542

Closes #xxxxx
vszakats added a commit that referenced this pull request Nov 20, 2023
Do not alter the C standard when building with `--enable-warnings` when
building with gcc.

On one hand this alters warning results compared to a default build.
On the other, it may produce different binaries, which is unexpected.

Also fix new warnings that appeared after removing `-std=gnu89`:

- include: fix public curl headers to use the correct printf mask for
  and Visual Studio 2013 and newer. This fixes the printf mask warnings
  in examples and tests. E.g. [1]

- conncache: fix printf format string [2].

- http2: fix potential null pointer dereference [3].
  (seen on Slackware with gcc 11.)

- libssh: fix printf format string in SFTP code [4].
  Also make MSVC builds compatible with old CRT versions.

- libssh2: fix printf format string in SFTP code for MSVC.
  Applying the same fix as for libssh above.

- unit1395: fix `argument is null` and related issues [5]:
  - stop calling `strcmp()` with NULL to avoid undefined behaviour.
  - fix checking results if some of them were NULL.
  - do not pass NULL to printf `%s`.

- ci: keep a build job with `-std=gnu89` to continue testing for
  C89-compliance. We can apply this to other gcc jobs as needed.
  Ref: b23ce2c (2022-09-23) #9542


Closes #12346
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Successfully merging this pull request may close these issues.

None yet

4 participants