Page MenuHomeFreeBSD

cdefs: Add __deprecated(message) function attribute macro
ClosedPublic

Authored by cem on Dec 14 2019, 9:33 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Dec 2, 9:47 AM
Unknown Object (File)
Mon, Dec 2, 9:47 AM
Unknown Object (File)
Mon, Dec 2, 9:47 AM
Unknown Object (File)
Mon, Dec 2, 12:49 AM
Unknown Object (File)
Fri, Nov 29, 5:08 AM
Unknown Object (File)
Oct 22 2024, 7:11 PM
Unknown Object (File)
Oct 17 2024, 9:26 PM
Unknown Object (File)
Sep 15 2024, 11:34 PM
Subscribers
None

Details

Summary

The legacy version of GCC4 currently in base does not support the
parameterized form of this function attribute, as recent introduced in
stdlib.h (r355747).

As we have done for other function attributes with similar compatibility
problems, add a version-compatibile definition in sys/cdefs.h. Note that
Clang defines itself to be GCC 4, so one must check for clang in
addition to GNUC version. On legacy GCC 4, the macro expands to just
the deprecated attribute; on modern GCC or Clang, the macro expands to
the parameterized variant with the message.

Ignoring legacy or unsupported compilers, the macro is also beneficial in
that it is a bit more ergonomic than the full
attribute((deprecated())) boilerplate.

Test Plan

amd64 tinderbox built.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Minor possible improvement, but either way this good...

sys/sys/cdefs.h
471 ↗(On Diff #65666)

Is GNUC_PREREQ better here?

This revision is now accepted and ready to land.Dec 14 2019, 9:36 PM
sys/sys/cdefs.h
471 ↗(On Diff #65666)

I did consider that. I would say it's a valid option, but not better in any real sense.

Here's my thinking: we basically have three compilers in use today: modern Clang, somewhat modern GCC xtoolchains (6.4.0 or newer), and extremely old GCC toolchains (4.2.1). For all intents, no one uses a GCC version between 4.2.1 and 6.4.0.

Anyway, if I were to use __GNUC_PREREQ__, I'd just use the equivalent (4, 0) expression, because it cleanly separates the two GCC compiler versions used in practice and also because I'm not going to go dig up the exact GCC 4.x version that adds the message support. But inevitably someone would quibble with the imprecise minor version. So I figured I'd just use the major version directly. If someone really wants a pedantically correct version they can make the expression more precise.

However, I'd discourage doing so. When we de-support GCC4.2.1, I think we should broadly advertise that we no longer support exceptionally old versions of GCC in general, which includes all 4.x minor versions and 5.x. We still have a 6.4.0 xtoolchains, so I don't think killing 6.4+ support makes sense — but we also realize that 6 is getting quite old.

I would like to simplify the ifdef logic in cdefs.h after GCC4 is dropped from the tree. Already, there are a lot of GCC 2.96 era checks that should go.