Gilt __attribute__ für alle Variablen in einer Deklaration?
Lesezeit: 5 Minuten
jbl
Tut das __attribute__ Richtlinie für alle in einer Zeile deklarierten Mitglieder gelten?
int a, b, c;
Deklariert drei int-Variablen.
int *a, b, c;
Deklariert die Variable “a” als Zeiger auf int und b und c als int.
int __attribute__((used)) a, b, c;
Tut das used Attribute gelten für alle Variablen oder nur für a?
Das könntest du wahrscheinlich testen. Attribute sind nicht Teil des C-Standards, also kann jeder Compiler machen, was er will. Erstellen Sie einfach ein einfaches Programm wie Sie es haben, verknüpfen Sie es und erstellen Sie einen Dump der Symbole.
– Mark Lakata
26. Juni 2015 um 7:26 Uhr
Aus dem gleichen Grund ist die Pointer-Deklaration vage (dh int* a,b; deklariert b nicht als Zeiger), wird generell empfohlen, NIE mehr als eine Variable pro Zeile zu deklarieren. Dann gibt es keine Zweideutigkeit. Gleiches gilt für __attributes__
– Mark Lakata
26. Juni 2015 um 7:28 Uhr
Nun, die Frage ist, ob die __attribute__ beeinflusst den Typ (linke Seite) oder die Variable (rechte Seite). Seit used ist ein variables Attribut [gcc.gnu.org/onlinedocs/gcc/… and not a type attribute [gcc.gnu.org/onlinedocs/gcc/… it should affect only the variable a.
– harper
Jun 26, 2015 at 7:33
@MarkLakata For virtually any of my colleagues it is obvious that b is not a pointer. I know it was discussed too many times and what arguments are, but I think it has to be something with local education, not “common sense”. That’s why no one except minor monkeys around would write ambiguous int* a, b.
– user3125367
Jun 26, 2015 at 7:54
In any case it needs to be said that source lines are irrelevant; what could have been relevant was not “on one line” but “up to the next semicolon”.
An attribute specifier list may appear immediately before a declarator (other than the first) in a comma-separated list of declarators in a declaration of more than one identifier using a single list of specifiers and qualifiers. Such attribute specifiers apply only to the identifier before whose declarator they appear. For example, in
the noreturn attribute applies to all the functions declared; the format attribute only applies to d1.
Correction: As the comment points out, my previous conclusion is incorrect. I didn’t notice the other than the first part.
Modified conclusion:
In both
int __attribute__((used)) a, b, c;
and
__attribute__((used)) int a, b, c;
The attribute applies to all a, b, and c.
But if it were:
int a, __attribute__((used)) b, c;
The attribute would apply to b only.
the conclusion is wrong; there is no difference between __attribute__ int var and int __attribute__ var because “var” is not an “other than the first” .
– ensc
Aug 4, 2020 at 13:28
I’m somewhat shocked to realize how quickly legit questions are closed in SO, while accepted answers which are incorrect (like this one) are not detected, and even upvoted. For the correct answer, which shows why this one is wrong, read: stackoverflow.com/questions/63245625/…
– cesss
Feb 20, 2021 at 10:56
ouah
gcc documentation (6.36 Attribute Syntax) says it only applies to the identifier before whose declarator they appear:
An attribute specifier list may appear immediately before a declarator (other than the first) in a comma-separated list of declarators in a declaration of more than one identifier using a single list of specifiers and qualifiers. Such attribute specifiers apply only to the identifier before whose declarator they appear. For example, in
As with Yu Hao’s answer, since a is the first declarator in the list, and this paragraph only applies when the attribute specifier list applies immediately before a declarator other than the first, it does not apply here, and this logic is incorrect. See stackoverflow.com/questions/63245625/….
The keyword __attribute__ allows you to specify special attributes when making a declaration. This keyword is followed by an attribute specification inside double parentheses. Nine attributes, noreturn, const, format, no_instrument_function, section, constructor, destructor, unused and weak are currently defined for functions. Other attributes, including section are supported for variables declarations (see section 4.29 Specifying Attributes of Variables) and for types (see section 4.30 Specifying Attributes of Types).
unused:
This attribute, attached to a variable, means that the variable is meant to be possibly unused. GNU CC will not produce a warning for this variable.
unused:
When attached to a type (including a union or a struct), this attribute means that variables of that type are meant to appear possibly unused. GNU CC will not produce a warning for any variables of that type, even if the variable appears to do nothing. This is often the case with lock or thread classes, which are usually defined and then not referenced, but contain constructors and destructors that have nontrivial bookkeeping functions
The answer is that the attribute probably doesn’t do anything.
$ cat f.c
int foo_f1;
int __attribute__((used)) foo_f2;
main()
{
}
and
$ cat g.c
int foo_g1;
int __attribute__((used)) foo_g2;
Das könntest du wahrscheinlich testen. Attribute sind nicht Teil des C-Standards, also kann jeder Compiler machen, was er will. Erstellen Sie einfach ein einfaches Programm wie Sie es haben, verknüpfen Sie es und erstellen Sie einen Dump der Symbole.
– Mark Lakata
26. Juni 2015 um 7:26 Uhr
Aus dem gleichen Grund ist die Pointer-Deklaration vage (dh
int* a,b;
deklariert b nicht als Zeiger), wird generell empfohlen, NIE mehr als eine Variable pro Zeile zu deklarieren. Dann gibt es keine Zweideutigkeit. Gleiches gilt für__attributes__
– Mark Lakata
26. Juni 2015 um 7:28 Uhr
Nun, die Frage ist, ob die
__attribute__
beeinflusst den Typ (linke Seite) oder die Variable (rechte Seite). Seitused
ist ein variables Attribut [gcc.gnu.org/onlinedocs/gcc/… and not a type attribute [gcc.gnu.org/onlinedocs/gcc/… it should affect only the variablea
.Jun 26, 2015 at 7:33
@MarkLakata For virtually any of my colleagues it is obvious that b is not a pointer. I know it was discussed too many times and what arguments are, but I think it has to be something with local education, not “common sense”. That’s why no one except minor monkeys around would write ambiguous
int* a, b
.Jun 26, 2015 at 7:54
In any case it needs to be said that source lines are irrelevant; what could have been relevant was not “on one line” but “up to the next semicolon”.
Jun 26, 2015 at 10:22