0

I want to make sure my program works on either. Currently, I compile as such:

CFLAGS := -std=c99 -Wall -Wextra -Wshadow -Wpedantic

and want to make sure it works on either Linux/macOS.

I use __attribute__((unused)) and __attribute__((noreturn)). I'm having trouble finding if these are always supported within both gcc and clang

For example, clang here specifies the [[noreturn]] syntax only, but here states that __attribute__((unused)) is also acceptable.

8
  • Never assume or accept what the docs say - ALWAYS TEST! Commented Aug 5, 2023 at 18:13
  • I did @Bib. And it compiles, but just because it compiles, doesn't mean it's correct. Commented Aug 5, 2023 at 18:16
  • Unless part of the specification, nothing beginning with an underscore should be considered portable. It's often used for implementation- and compiler-specific things. Clang modeled lots of their non-portable things after GCC, that's why both have __attribute__. Always check the compiler documentation whenever you see anything beginning with an underscore. Commented Aug 5, 2023 at 18:18
  • If all you are doing is compiling, then you are not testing. Testing means running and throwing test data at it. Commented Aug 5, 2023 at 18:19
  • So both do have __attribute__ in all cases? @Someprogrammerdude. I specifically meant portable across gcc and clang. Commented Aug 5, 2023 at 18:31

1 Answer 1

2

The unused and noreturn function attributes are listed in the section Common Function Attributes in the GCC manual. This means that they are supported by GCC on every platform, unless otherwise specified. (Or at least, the maintainers intend it to be supported; bugs are always possible.) Attributes that are specific to particular target platforms are listed instead in separate sections, e.g. AArch64 Function Attributes, MIPS Function Attributes.

Moreover, for unused and noreturn in particular, they are purely compile-time features, affecting only the warnings and/or optimizations done by the compiler. There is nothing about them that would seem platform-dependent, and they are presumably implemented in the generic portion of the compiler that is independent of platform. So it makes sense that they would work on all platforms.

clang's documentation is less complete, but generally, they aim to provide all of GCC's extensions, except where noted otherwise. And unused/noreturn are very mature features, supported at least as far back as GCC 2.6.3 circa 1994, several years before the LLVM project was even begun. So I think it's safe to assume that clang supports them. And it presumably supports them across all platforms, because there is no reason for it not to. If you found an instance where it wasn't, I'd consider it a clang bug that should be reported.

Of course, you would want to actually test on each platform that your program is advertised as supporting.

It probably goes without saying, but I don't know of any compilers other than GCC and clang that support the __attribute__ syntax at all. It is not part of ISO standard C.


However, ISO C from C23 onward specifies the [[..]] syntax for attributes, and includes standard attributes [[noreturn]] and [[maybe_unused]]. As GCC and clang both aim for ISO C compliance, they should support this standard syntax as well (you might have to use --std=c2x or --std=c23), and so will every other C23 compilant compiler. So moving forward, you will probably want to switch your code to use the ISO syntax.

2
  • I actually looked into it and switched over to the new syntax. Am I correct to say that __attribute__((noreturn)) == [[noreturn]] and __attribute__((unused)) == [[maybe_unused]]? The “maybe” is throwing me off Commented Aug 6, 2023 at 3:58
  • @user129393192: GCC's documentation for __attribute__((unused)) says: "means that the function is meant to be possibly unused". So IMHO just calling the attribute unused was always misleading, and ISO clarified it by adding the maybe. I would presume that GCC handles them identically, but you'd have to check the GCC source code to be certain. Commented Aug 6, 2023 at 6:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.