What is replacement of __attribute__ in ISO C standard? - c

What is the replacement of __attribute__ in ISO C standard?
I want to port my software which is compiler independent.

There isn't one.
One solution is to abstract the attributes behind macros. e.g.:
#ifdef __GNUC__
#define UNUSED __attribute((unused))__
#else
#define UNUSED
#endif
...
void function(void) UNUSED;

There is no general replacement for the wide range of facilities that this gcc extension offers. Most other compilers that are not gcc compatible use #pragma to achieve similar goals. Since C99, C has the _Pragma operator that allows you to spew pragmas in the middle of your code (not only on proper lines) and to compose the contents of a pragma with macros. But then you still have to do specific "translations" of individual features to the corresponding pragma syntax of your target compiler.

Related

How to check the state of #pragma STDC?

Consider this code:
/* t0.c */
#pragma STDC FENV_ACCESS ON
#include "t0.h"
Then in t0.h how to check the state of STDC FENV_ACCESS?
/* t0.h */
/* how to check the state of STDC FENV_ACCESS? */
/* something like: #if STDC FENV_ACCESS == ON */
If not possible, then:
Why not possible?
Will it be useful to add this feature to the C standard?
(1) Why not possible?
It is possible with a custom cpp as rryker's answer mentioned. Otherwise, I would have said "no" because the compiler uses the pragmas and that comes after the cpp pass/stage.
(2) Will it be useful to add this feature to the C standard?
No, probably not. For the above mentioned reason.
And, because, drawing a leaf from what is already common (e.g. autoconf), we can reverse the problem to get the desired results without changing existing compilers.
Define (e.g.) a features.h:
#ifdef STDC_FENV_ACCESS_ON
#if STDC_FENV_ACCESS_ON
#pragma STDC FENV_ACCESS ON
#else
#pragma STDC FENV_ACCESS OFF
#endif
#endif
UPDATE:
Re: "custom cpp as rryker's answer mentioned": hm, where is the rryker's answer? I don't see it. –
pmor
I wrote that before rryker deleted his answer [partly] because of critique/comments from HolyBlackCat that couldn't be addressed immediately. My inference was rryker would be able to improve his answer and undelete it, so I left up the reference.
The link rryker based his answer on was specific extensions provided by clang: https://clang.llvm.org/docs/LanguageExtensions.html The features that rryker's answer referred to were: the __has_feature and __has_extension macros [since version 10].
That's the reference. However, with a bit of conjecture on my part, I'll try to summarize.
IIRC, clang's cpp is not a separate program that is only loosely connected to the compiler [e.g. like it is with gcc].
With clang, the preprocessor is a [more] tightly integrated stage within the compiler itself. My presumption is that this was [initially] done for speed and code reuse.
But, as a "side effect" of that:
clang's cpp can have much more intimate knowledge of the compiler's inner workings.
And, if it's more efficient/desirable, clang's cpp stage could also do more of the early (e.g.) pragma processing.
And, cpp could have access to (e.g.) all the -f* arguments/options the compiler sees.
So, it has all of the tools that make #if/#ifdef on the above __has_* macros feasible.
In addition to the other answers, and if t0.c is actually under your control, you may define appropriate macros whenever a #pragma is used.
/* t0.c */
#pragma STDC FENV_ACCESS ON
#define PRAG_FENV_ACCESS_ON
#include "t0.h"
This works independently of toolchain vendor. It's a variation of the same theme used to check the presence of typedefs in the preprocessor.

Enabling HANDLE_PRAGMA_PACK_WITH_EXPANSION

I'd like gcc to process pack pragmas such as the following:
#define _CTR_PACKING 4
#pragma pack(push, _CRT_PACKING)
MSVC allows this kind of construction by default.
Clang enabled this behavior via -fms-extensions.
Searching for a gcc equivalent, I found references to macros HANDLE_PRAGMA_PACK_PUSH_POP and HANDLE_PRAGMA_PACK_WITH_EXPANSION, but even after adding them via -DHANDLE_PRAGMA_PACK_WITH_EXPANSION=1 or as environment variables, gcc still does nothing.
How can I make gcc behave as MSVC and Clang with -fms-extensions?
The gcc macro HANDLE_PRAGMA_PACK_WITH_EXPANSION is a macro used by gcc target to indicate whether it supports expansion of macros in pragma directive, it's not a switch to enable on the fly.
Instead, you can use standard C's _Pragma operator, it translate into the compiler's pragma directives, and it supports macro expansion since it's part of the language. This is an example:
#define STR(s) #s
#define _CTR_PACKING 1
#define PACKSTR(x) STR(pack(x))
_Pragma(PACKSTR(_CTR_PACKING))

How to #ifdef by CompilerType ? GCC or VC++

I used #ifdef Win32 for safe calls alike sprintf_s but now I want to build project with MinGW and it's just wrong now. I need to use #ifdef VC++ or somehow like that. Is it possible?
#ifdef __clang__
/*code specific to clang compiler*/
#elif __GNUC__
/*code for GNU C compiler */
#elif _MSC_VER
/*usually has the version number in _MSC_VER*/
/*code specific to MSVC compiler*/
#elif __BORLANDC__
/*code specific to borland compilers*/
#elif __MINGW32__
/*code specific to mingw compilers*/
#endif
See the "Microsoft-Specific Predefined Macros" table of Visual C predefined macros
You could check for _MSC_VER.
Preferably, you should resort to using portable symbols. I understand sometimes those symbols may not be defined, so you can see the Predef project for an extensive list of preprocessor macros regarding standards, compilers, libraries, operating systems and architectures that aren't portable.
However, the function you specifically mention in this question has been included within the C11 standard as a part of Annex K.3, the bounds-checking interfaces (library).
K.3.1.1p2 states:
The functions, macros, and types declared or defined in K.3 and its subclauses are declared and defined by their respective headers if __STDC_WANT_LIB_EXT1__ is defined as a macro which expands to the integer constant 1 at the point in the source file where the appropriate header is first included
Thus, you should place preference upon checking __STDC_WANT_LIB_EXT1__, and only use compiler-specific symbols when that doesn't exist.

Why does GCC's __attribute__((...)) syntax use double parentheses?

The documentation for GCC's __attribute__((...)) syntax indicates that attributes must be surrounded by double parentheses, but does not give a rationale for this design decision.
What practical reason would have caused GCC's designers to require this? Does it have anything to do with the preprocessor's handling of double parentheses?
To make it easier to eliminate it for different compiler. If you have portable code, you have to remove them for other compilers, so you do
#ifndef __GNUC__
#define __attribute__(x)
#endif
The problem is that attributes have various number of arguments and you can combine multiple attributes in one __attribute__ declaration, but C only introduced variadic macros in C99. With double parenthesis the above definition does not need variadic macros.
probably the idea is that you can declare a simple macro that helps to ignore all this in any other C and C++ compiler. If you wouldn't have the second pair of parenthesis that macro would be necessarily one with .... So for compilers that don't support that you would be screwed.
Edit: With this syntax it can simply look like
#ifdef __GNUC__
# define attribute(X) __attribute__(X)
#else
# define attribute(X)
#endif
and then you would use attribute for your function declarations, e.g.

What's difference between #pragma and #ifndef? [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
#pragma once vs include guards?
When should I use #pragma once?
When should I use #ifndef HEADER_H_INCLUDED?
The #ifndef/#define/#endif trick works on any C compiler, and on some of them it speeds up the compilation process. The #pragma trick is non-standards, and only works on few C compilers, and may result in different semantics in those that do not support it.
The difference is that the latter is C and the former is not. Never use #pragma once; always use #ifndef.
One other thing to note when using the #ifndef method is that any preprocessor symbol beginning with two underscores or an underscore followed by a capital letter is reserved and cannot be used. You should use things like #ifndef MYHEADER_H and not #ifndef _MYHEADER_H.
The construct
myfoo.h
#ifndef MYFOO_H
#define MYFOO_H
/* header information for myfoo.h */
#endif
belongs in every header-file. The trick is: you can include a header file (accidentally) more than once without thinking abaout double declarations. so this is for the preprocessor.
The #pragma is for the compiler, and a preprocessor should ignore pragmas it does not understand.
Use #pragma when you are addressing a specific compiler (or set of compatible compilers) to guide its code generation or if you are using a standardized #pragma like FP_CONTRACT or -CX_LIMITED_RANGE- that any standards-compliant compiler is going to support.
Use #ifndef and ilk if you are addressing the standard C (or C++) pre-processor and wish to have your code rendered portable across all standards-compliant compilers.
Use of any #pragma that is not defined in the C (or C++) standard renders your code non-portable. #pragma once is a bit of an exception in that it is one of the most commonly-implemented of the non-standard #pragma constructs. Its implementation, however, is not universal across standards-compliant compilers. #ifndef is.

Resources