Forum: Compiler & IDEs Größe von "enums" im AVR GCC


von Enumerator (Gast)


Lesenswert?

Hallo zusammen,

ich hoffe ihr könnt mir helfen.
Ich habe ein sehr kurioses Verhalten meiner Software auf meinem 
Controller.
Bin schon sehr lange am Suchen.

Ich benutze Enumeratoren für die Indizierung verschiedener Dinge. Und 
ich denke, dass mein Problem auf meinen Enumerator zurück zu führen ist.

Wenn ich einen Enumerator anlege, wie groß ist der. 8- bit, 16- bit?
Ich glaube nämlich, dass ich irgendwo einen Überlauf habe.

Oder kann ich das im GCC beeinflussen, gibts da einen Compiler- 
Schalter.

Danke für eure Hilfe!

Gruß

P.S. Benutze den XMega128A1 und Eclipse mit GCC

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Enumerator schrieb:

> Wenn ich einen Enumerator anlege, wie groß ist der. 8- bit, 16- bit?

Standardmäßig so groß wie der Typ "int".

> Ich glaube nämlich, dass ich irgendwo einen Überlauf habe.

Wie kann man bei einem enum einen Überlauf haben?  Die einzelnen
Elemente sind doch explizit benannt, wenn man wirklich so viele
hat, dass die nicht mehr in den Datentyp passen, müsste der
Compiler meckern.

> Oder kann ich das im GCC beeinflussen, gibts da einen Compiler-
> Schalter.

Man kann den Standard durch __attribute__((packed)) (alternativ durch
den Compilerschalter -fshort-enums) dahingehend abändern, dass er nur
die minimal notwendige Größe benutzt, die sich aus der Anzahl der
aufgezählten Elemente ergibt.

von Enumerator (Gast)


Lesenswert?

>Wie kann man bei einem enum einen Überlauf haben?  Die einzelnen
>Elemente sind doch explizit benannt, wenn man wirklich so viele
>hat, dass die nicht mehr in den Datentyp passen, müsste der
>Compiler meckern.

Du hast schon recht, so war es gemeint. Der Compiler meckert, du hast 
recht. Ich hab es probiert.

>Man kann den Standard durch __attribute__((packed)) (alternativ durch
>den Compilerschalter -fshort-enums) dahingehend abändern, dass er nur
>die minimal notwendige Größe benutzt, die sich aus der Anzahl der
>aufgezählten Elemente ergibt.

Das hab ich mittlerweile auch gefunden, dass die Erweiterung 
-fshort-enums eingebunden ist. Kann das Probleme machen?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Enumerator schrieb:

> Das hab ich mittlerweile auch gefunden, dass die Erweiterung
> -fshort-enums eingebunden ist. Kann das Probleme machen?

Es kann Kompatibilitätsprobleme machen, wenn du gegen Bibliotheken
linkst, die nicht auf diese Weise compiliert worden sind.  (Die
avr-libc selbst enthält keine Funktionen, die irgendwo mit enums
arbeiten, ist insofern also unkritisch.)

Generell halte ich von dieser Art "tuning" per Compilerschaltern
wenig.  In einer anderen Umgebung compiliert, und nichts geht mehr.
Das __attribute__((packed)) ist dagegen eindeutig im Code und
unabhängig von den Optionen.

Allerdings sollte auch bei -fshort-enums (oder dem entsprechenden
Attribut) automatisch die nächstgrößere Wahl getroffen werden, wenn
die Anzahl der Elemente nicht mehr in den kleinsten möglichen Typ
passt.

Was jedoch nicht möglich ist ist, einen enum mit mehr als der Größe
von "int" anzulegen.  Da man in der Regel die negativen Werte nicht
mit benutzen wird (die Nummerierung fängt ja bei 0 an), limitiert
das die Zahl der Elemente auf 32767 (beim AVR-GCC).

von Enumerator (Gast)


Lesenswert?

Du hast schon recht, ich weiß aber nicht wie ich es sonst lösen soll. 
Ich möchte auch nicht mein ganzes Projekt umschreiben. Ich habe 
natürlich Funktionen, die einen Enumerator erwarten, mache ich oft.

Die 32767 reichen mir ja dicke aus, jedoch 255 halt nicht. Und wenn der 
Compiler den enum nur 8-bit breit anlegt, dann reicht es eben nicht. 
Aber wenn ich es richtig verstanden habe, passt er es mit der 
Erweiterung -fshort sowieso immer an.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.