Forum: Compiler & IDEs Fehlerhafter RETURN bei Optimierung


von Tommy (Gast)


Lesenswert?

Hallo,

könnt Ihr mit Tips geben woran folgendes liegen könnte:

Eine Funktion ruft eine andere auf -  diese ist relativ aufwändig und 
gibt dann mittels return etwas zurück  -  mit ausgeschalteter 
Optimierung geht das alles wunderbar  -  schalte ich die Optimierung 
ein, so springt das nach return Programm an eine beliebige ( immer 
gleiche) Stelle im Programm

Simulation in AVR-Studio
 Chip:  ATMEGA 8

ich würde mich sehr freuen  -  vielleicht ist es ein bekanntes Problem


Danke !

von Karl H. (kbuchegg)


Lesenswert?

Tommy wrote:
> Hallo,
>
> könnt Ihr mit Tips geben woran folgendes liegen könnte:
>
> Eine Funktion ruft eine andere auf -  diese ist relativ aufwändig und
> gibt dann mittels return etwas zurück  -  mit ausgeschalteter
> Optimierung geht das alles wunderbar  -  schalte ich die Optimierung
> ein, so springt das nach return Programm an eine beliebige ( immer
> gleiche) Stelle im Programm
>
> Simulation in AVR-Studio
>  Chip:  ATMEGA 8
>
> ich würde mich sehr freuen  -  vielleicht ist es ein bekanntes Problem
>

Welche Version willst du haben?
* Die Glaskugelvariante oder auch
  'Ich rate jetzt mal ins Blaue hinein' - Variante genannt:

  Wenn du Unordnung auf dem Stack erzeugst, dann kann sowas schon
  mal vorkommen. Immer noch beliebtes Werkzeug dazu, sind Array-
  Overflows. Diese können in Form von 'normalen' Arrays vorkommen
  oder aber, ganz beliebt, in Form von zu klein dimensionierten
  Arrays für Strings

* die vernünftige Variante:
  Es gibt tausend und einen Grund, wie sowas zustande kommen kann.
  Ohne Source Code kann man dazu gar nichts sagen.
  Deine Anfrage ist ungefähr so spezifisch wie:
  "Doktor, es tut weh! Was könnte das sein?"

von Tommy (Gast)


Lesenswert?

...ja ich suche ja auch nach meiner Kugel....

das einzige was der Compiler noch meldet :   Invalid opcode
0xffff at address 0x000f91

von Simon K. (simon) Benutzerseite


Lesenswert?

Tommy wrote:
> ...ja ich suche ja auch nach meiner Kugel....

Es reicht wenn du Sourcecode anhängst. Und zwar solchen, der möglichst 
klein ist, aber den Fehler reproduzierbar zeigt.

von Tommy (Gast)


Angehängte Dateien:

Lesenswert?

Hi,

vielen Dank für eure Hilfe  -  habe mal alles was nicht zum Fehler 
beiträgt gelöscht ....

daher macht das Programm jetzt nix sinnvolles mehr  -  aber bei dem 
Return kommt genau der Fehler vor  -  allerdings nur bei der Optimierung 
( also bei 00 nicht)

...die Funktion bla() wird nie erreicht ...

vielen Dank für eure Mühe !

Gruß

T.

von Chris (Gast)


Lesenswert?

Mal eine grobe Abschaetzung machen: Du hast zwei verschachtelte 
Schleifen, die aeussere mit 7, die innere mit 8 Durchlaeufen. Macht 
insgesamt 56 Durchlaeufe der inneren Schleife. n_shift wird jedesmal 
inkrementiert, ausser in genau drei Faellen. Macht 53 Inkrementierungen. 
n_pack wird demnach 6 Mal inkrementiert. Also nimmt n_pack die Werte 0, 
1, ..., 6 an. Problem: Das array paket hat keine 7 Elemente, aber du 
greifst auf paket[6] zu. Das zerstoert dir den Stack und damit die 
Ruecksprungadresse.

Btw, ich wuerde den Operatoren ein paar Leerzeichen spendieren. 
Langsamer wird es dadurch nicht, aber sowas wie
for(n_Hshift = 0; n_Hshift < 8; n_Hshift++)
ist IMHO einfach lesbarer als
for(n_Hshift=0;n_Hshift<8;n_Hshift++).

von Karl H. (kbuchegg)


Lesenswert?

Chris wrote:
> Mal eine grobe Abschaetzung machen: Du hast zwei verschachtelte
> Schleifen, die aeussere mit 7, die innere mit 8 Durchlaeufen. Macht
> insgesamt 56 Durchlaeufe der inneren Schleife. n_shift wird jedesmal
> inkrementiert, ausser in genau drei Faellen. Macht 53 Inkrementierungen.
> n_pack wird demnach 6 Mal inkrementiert. Also nimmt n_pack die Werte 0,
> 1, ..., 6 an. Problem: Das array paket hat keine 7 Elemente, aber du
> greifst auf paket[6] zu. Das zerstoert dir den Stack und damit die
> Ruecksprungadresse.

Ich bin immer noch fasziniert von deiner Analyse. Saubere
Arbeit!

Ach ja: Ein simples Durchsteppen durch den Code bestätigt:
n_pack wird tatsächlich zu 6. Da danach zumindest noch
ein paket[n_pack] = 0 erfolgt, sind alle Zutaten beisammen
um den Stack zu zerstören.

D.h. die Glaskugelvariante war doch nicht so schlecht :-)

von Simon K. (simon) Benutzerseite


Lesenswert?

Karl heinz Buchegger wrote:
> Chris wrote:
>> Mal eine grobe Abschaetzung machen: Du hast zwei verschachtelte
>> Schleifen, die aeussere mit 7, die innere mit 8 Durchlaeufen. Macht
>> insgesamt 56 Durchlaeufe der inneren Schleife. n_shift wird jedesmal
>> inkrementiert, ausser in genau drei Faellen. Macht 53 Inkrementierungen.
>> n_pack wird demnach 6 Mal inkrementiert. Also nimmt n_pack die Werte 0,
>> 1, ..., 6 an. Problem: Das array paket hat keine 7 Elemente, aber du
>> greifst auf paket[6] zu. Das zerstoert dir den Stack und damit die
>> Ruecksprungadresse.
>
> Ich bin immer noch fasziniert von deiner Analyse. Saubere
> Arbeit!

Echt nicht übel! ;)

Zum Problem: Jaja, der Klassiker, wie schon von Karl Heinz vermutet ;)

von die ??? (Gast)


Lesenswert?

Ich wundere mich nur über diese Zeilen:

1
// ...
2
3
  !(n_Hpack | n_Hshift)
4
5
// ...
6
7
  if(!((position==8) | (position==16) | (position==32)))
8
9
// ...

und frage mich, ob der Verfasser sicher ist, dass dort das passiert was 
passieren soll? Komisch dass der Compiler nicht wenigstens bei der 
if-Abfrage eine Warnung schmeisst (habe es nicht getestet).

von Karl H. (kbuchegg)


Lesenswert?

die ??? wrote:
> Ich wundere mich nur über diese Zeilen:
>
>
>
1
> // ...
2
> 
3
>   !(n_Hpack | n_Hshift)
4
> 
5
> // ...
6
> 
7
>   if(!((position==8) | (position==16) | (position==32)))
8
> 
9
> // ...
10
>
>
> und frage mich, ob der Verfasser sicher ist, dass dort das passiert was
> passieren soll?

Der erste Asudruck
   !(n_Hpack | n_Hshift)

ist equivalent zu

   n_Hpack != 0  &&  n_Hshift != 0

zusammen mit dem Kommentar in dieser Zeile, sieht das
durchaus so gewollt aus.

  n_Hpack | n_Hshift   liefert als bitweises Oder nur dann eine
0, wenn sowohl n_Hpack als auch n_Hshift 0 sind. Dieses Ergebnis
dann logisch umgedreht, liefert TRUE, wenn beide 0 sind.


> Komisch dass der Compiler nicht wenigstens bei der
> if-Abfrage eine Warnung schmeisst (habe es nicht getestet).

Warum sollte er?
Das sind ganze normale Ausdrücke. Entweder der Ausdruck evaluiert
zu 0 oder er tut es nicht.

>   if(!((position==8) | (position==16) | (position==32)))

Dich stört wahrscheinlich, dass hier bitweise Oder benutzt werden.
Macht aber in diesem konkreten Fall keinen Unterschied.

von Simon K. (simon) Benutzerseite


Lesenswert?

Karl heinz Buchegger wrote:
> Der erste Asudruck
>    !(n_Hpack | n_Hshift)
>
> ist equivalent zu
>
>    n_Hpack != 0  &&  n_Hshift != 0
>
> zusammen mit dem Kommentar in dieser Zeile, sieht das
> durchaus so gewollt aus.
>
>   n_Hpack | n_Hshift   liefert als bitweises Oder nur dann eine
> 0, wenn sowohl n_Hpack als auch n_Hshift 0 sind. Dieses Ergebnis
> dann logisch umgedreht, liefert TRUE, wenn beide 0 sind.

Jau, als Stichwort: DeMorgansches Gesetze
http://de.wikipedia.org/wiki/De_Morgansche_Gesetze

von Tommy B. (tommy1960)


Lesenswert?

DANKE !!!!!!!!!!!!!!!!!!!! Chris

.... au Mann  -  das darf nicht wahr sein  ....   SUPER DANKE an alle  - 
sorry, dass es so ein dummer Fehler war !!!!!!

schönen Abend !

von Tommy B. (tommy1960)


Lesenswert?

hey super, prima funzt  -  hehe !


D A N K E ! ! ! ! !

von die ??? (Gast)


Lesenswert?

Karl heinz Buchegger wrote:
> Dich stört wahrscheinlich, dass hier bitweise Oder benutzt werden.
> Macht aber in diesem konkreten Fall keinen Unterschied.

Macht es nicht? Für mich scheint das etwas inkonsistent:

1
if(!((position==8) | (position==16) | (position==32)))

Hier werden Ergebnisse aus einer logischen Operation mit Hilfe einer 
bitweisen Operation verknüpft. Wie gesagt, es wundert mich nur, dass 
nicht wenigstens eine Warnung kommt (nach dem Motto "ob der Anwender 
sich sicher sei dass es so gewollt ist") - kann sein dass C dort nicht 
so strikt ist wie mancher C++ Compiler ob des expliziten 
bool-Datentypes.
Die andere Zeile war soweit passabel, ich habe den Kommentar nicht 
gelesen - das muss ich mir endlich mal angewöhnen  ;-)  .

von Karl H. (kbuchegg)


Lesenswert?

die ??? wrote:

> Macht es nicht? Für mich scheint das etwas inkonsistent:

Erinnere dich:
In C gibt es erst mal keinen eignen bool Datentyp.

Alles was ein arithmetischer Ausdruck ist, kann auch
als logischer Ausdruck verwendet werden und umgekehrt.
0 wird zu false, alles ungleich 0 wird zu true


> if(!((position==8) | (position==16) | (position==32)))

> Hier werden Ergebnisse aus einer logischen Operation mit Hilfe einer
> bitweisen Operation verknüpft.

Ist kein Problem. Das Ergebnis einer logischen Operation ist auch
erst mal nur eine Zahl. Und mit der kann man auch rechnen :-)

  if( ( (position==8) + (position==16) + (position==32)) == 0)

würde genau dasselbe bewirken.

> Wie gesagt, es wundert mich nur, dass
> nicht wenigstens eine Warnung kommt (nach dem Motto "ob der Anwender
> sich sicher sei dass es so gewollt ist") - kann sein dass C dort nicht
> so strikt ist wie mancher C++ Compiler ob des expliziten
> bool-Datentypes.

Yep.

von let (Gast)


Lesenswert?

>  if( ( (position==8) + (position==16) + (position==32)) == 0)
>würde genau dasselbe bewirken.

Nur in C++. Dort ist das Ergebnis einer logischen Operation mit
0 oder 1 definiert. In C kann 'logisch 1' alles außer 0 bedeuten.
Das Ergebnis der Addition kann also zufällig 0 ergeben (Überlauf).

Durch solche Trickprogrammierungen stürzen Flugzeuge ab ;).

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


Lesenswert?

let wrote:

>>  if( ( (position==8) + (position==16) + (position==32)) == 0)
>>würde genau dasselbe bewirken.

> Nur in C++. Dort ist das Ergebnis einer logischen Operation mit
> 0 oder 1 definiert. In C kann 'logisch 1' alles außer 0 bedeuten.

Das ist Quatsch, sorry.

In C ist das Ergebnis einer logischen Operation genauso definiert
wie in C++.  Wenn ein Compiler für 0 == 0 etwas anderes als den
Wert 1 generiert, dann hat er nicht das Recht, sich C-Compiler zu
nennen.

Wenn du's nicht glaubst, grabe ich dir auch die passende Stelle des
Standards raus, bin aber gerade zu faul dazu.

von Karl H. (kbuchegg)


Lesenswert?

let wrote:

Jörg hat sich ja zum Rest schon geäußert.

> Durch solche Trickprogrammierungen stürzen Flugzeuge ab ;).

Meine absolute, 100%-ige, aus tiefstem Herzen kommende,
durch nichts zu beirrende, absolute (sagte ich das schon?)
                Z U S T I M M U N G.


Ich hab das Beispiel nicht gebracht, damit jemand so programmiert,
sondern nur um zu zeigen, dass:

  Compiler gibt keine Warnung oder Fehler

nicht notwendigerweise irgendetwas heißen will. Oder wie
jemand anderer in grauer Vorzeit sagte:
Ein guter Programmierer kann in jeder Sprache Fortran programmieren.

von let (Gast)


Lesenswert?

>Wenn du's nicht glaubst, grabe ich dir auch die passende Stelle des
>Standards raus, bin aber gerade zu faul dazu.
Wenn du das sagst wird es wohl stimmen. Aber war das schon zu ANSI
Zeiten so? Irgendwo habe ich nämlich vor langer Zeit in einer
Gegenüberstellung (Stroustrup?) zwischen C/C++ gelesen das besagtes
Ergebnis jetzt (c++ - das ja C ersetzen sollte) genau definiert ist.
Obwohl die meisten Compiler das ohnehin so tun würden.

von let (Gast)


Lesenswert?

Habs gerade in der Bibel nachgeschlagen: Die Regel kannte ANSI
auch schon. Da habe ich mir wohl etwas zurechtgesponnen.

von die ??? (Gast)


Lesenswert?

1
  if( ( (position==8) + (position==16) + (position==32)) == 0)

Ok, welcher Datentypen wird hier für die logischen Ergebnisse 
angenommen? Signed 16Bit? Ich gehe davon aus. Lasst mich etwas spinnen: 
Angenommen diese Abfrage enthält genau soviele Vergleiche, dass es zu 
einem Überlauf kommen kann der das Ergebnis 0 liefert wenn alle 
Vergleiche wahr/'true' sind.

1
  (0) == 0

Blöd.

Ist nicht das gleiche wie

1
  if( ( (position==8) | (position==16) | (position==32)) == 0)

da es hier niemals zu einem Überlauf kommt wenn der Compiler auf

  (0 == 0) := 1

besteht. Karl, du hast den Kopf aus der Schlinge gezogen weil du 
geschrieben hast "genau dasselbe bewirken". Trotzdem bestehe ich auf

1
#ifndef FALSE
2
  #define FALSE (1 == 0)
3
#endif
4
5
  if( ((position==8) || (position==16) || (position==32)) == FALSE )

um unnötige Diskusionen wie diese hier zu vermeiden  ;-)

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


Lesenswert?

die ??? wrote:

> Ok, welcher Datentypen wird hier für die logischen Ergebnisse
> angenommen? Signed 16Bit?

`int', per definitionem.

> Angenommen diese Abfrage enthält genau soviele Vergleiche, dass es
> zu einem Überlauf kommen kann der das Ergebnis 0 liefert wenn alle
> Vergleiche wahr/'true' sind.

Hmm, das wären dann wenigsten 65536 Vergleiche (die alle wahr sein
müssen), die Zeile möchte ich mal sehen. :-)

> Trotzdem bestehe ich auf
1
#ifndef FALSE
2
  #define FALSE (1 == 0)
3
#endif

Was kompletter Unsinn ist.  Die Argumentation dafür spare ich mir, die
kannst du dir in der comp.lang.c-FAQ (bzw. in der de.comp.lang.c-FAQ)
durchlesen.

Bei C99 ist es sowieso sinnvoller, gleich
1
#include <stdbool.h>

zu nehmen, dann sind true und false (in dieser Schreibweise)
vordefiniert, und bool ein eigener Datentyp.

von die ??? (Gast)


Lesenswert?

Naja, so drastisch wie du drücken sich die FAQ's nicht aus, aber egal. 
Ich wusste nicht, dass bool mittlerweile dazu gehört. Danke für den 
Tip - wieder was gelernt!

Dann bestehe ich halt hierauf:

1
#include <stdbool.h>
2
3
// ...
4
5
  if( ((position==8) || (position==16) || (position==32)) == false )

;-)

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


Lesenswert?

Selbst das ist nicht sinnvoll.  Das Teil ist schon bool, und damit
hervorragend als Steuerausdruck eines if geeignet:
1
if( !((position==8) || (position==16) || (position==32)))
2
...

Kann man nach Boole's Regeln auch umschreiben als
1
if(position != 8 && position != 16 && position != 32)
2
...

von die ??? (Gast)


Lesenswert?

Jörg Wunsch wrote:
> Selbst das ist nicht sinnvoll.

Warum verallgemeinerst du so strikt?

1
 == false

Was ist daran "nicht sinnvoll" den Code lesbar zu gestalten?

  http://www.gnu.org/prep/standards/standards.html
  http://www.phaedsys.demon.co.uk/chris/papers/qa2tilehill.pdf

Solche Vereinfachungen darf dann der Compiler übernehmen.

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


Lesenswert?

die ??? wrote:

> Was ist daran "nicht sinnvoll" den Code lesbar zu gestalten?

Ein Boolescher Ausdruck wird nicht ,,noch Boolescher'', indem man
einen Vergleich auf true oder false einbaut.  Er ist bereits
ein Wahrheitswert, ,,noch wahrer'' kann er nicht werden.  Dabei
ist der Vergleich
1
==false
 noch relativ harmlos, während
der analoge Vergleich
1
==true
 komplett hinkt und voll nach
hinten losgehen kann, falls nicht alle Teilausdrücke (so wie hier)
tatsächlich bereits Booleschen Charakter haben (also wirklich nur
true oder false als mögliche Werte).

Lesbarer wird er, indem man die Booleschen Regeln anwendet und
die zweite Form statt der ersten nimmt.  Das ist nicht nur eine
Vereinfachung (im Sinne der Optimierung), sondern einfach eine
Form, in der der mitlesende Mensch den gleichen Ausdruck besser
versteht: statt erst eine Liste von Gleichheiten aufzuzählen und
diese dann zu negieren, lieber gleich eine Liste von Ungleichheiten
aufzählen.

von die ??? (Gast)


Lesenswert?

Jörg Wunsch wrote:
> komplett hinkt und voll nach hinten losgehen kann

Wir schweifen ab, wie so oft hier. Am Anfang ging es um | vs ||. Jetzt 
werden wieder Phrasen gedroschen ohne Beispiele zu bringen.

von Rolf Magnus (Gast)


Lesenswert?

>> Was ist daran "nicht sinnvoll" den Code lesbar zu gestalten?
>
> Ein Boolescher Ausdruck wird nicht ,,noch Boolescher'', indem man
> einen Vergleich auf true oder false einbaut.

Man könnte ja auch schreiben:
1
  if (((true == ((position==8) || (position==16) || (position==32))) != false)

Schließlich will man ja wissen, ob es nicht falsch ist, daß es wahr ist, 
daß position == 8 oder == 16 oder == 32 ist. Oder will man wissen ob es 
wahr ist, daß es nicht falsch ist, daß es war ist, daß ...

von Karl H. (kbuchegg)


Lesenswert?

Du willst ein Beispiel.

Zunächst mal sei gesagt, dass bei sorgfältiger Programmierung
solche Vergleiche zwar oft unnötig aber auch nicht gefährlich
sind. Erst dann, wenn der Schlendrian zuschlägt, wirds gefährlich.

das

  if( a > b )

dasselbe ist wie

  if( ( a > b ) == true )

dürfte einleuchten.

Das aber

  if( a )

nicht dasselbe ist wie

  if( ( a ) == true )

dürfte auch klar sein. Man kann also nicht einfach nur einen
Ausdruck hernehmen, ein '== true' dahinterschreiben und denken,
dass sich dadurch schon nichts ändert.
Interessanterweise geht das aber in die umgekehrte Richtung
meistens aber gut


  if( !b )

und

  if( ( b ) == false )

sind tatsächlich in den meisten Fällen austauschbar. Zumindest fällt
mir jetzt auf die Schnelle kein Gegenbeispiel ein.

Die Kunst beim Programmieren besteht nicht darin,
 * alles so kurz wie nur irgendmöglich zu schreiben
 * alles so langatmig wie nur irgendmöglich zu schreiben
Die Kunst besteht darin, den richtigen Spagat zwischen den
beiden Extremen zu finden.

von die ??? (Gast)


Lesenswert?

So ist es Karl.

Wenn man jedoch einen Datentyp ungleich bool mit expliziten boolschen 
Abfragen attackiert wird es ohnehin inkonsitent. Oder irre ich? Warum 
wirft der GCC eigentlich keine Warnung (auch nicht mit -pedantic) wenn 
man

1
  #include <inttypes.h>
2
  #include <stdbool.h>
3
4
  / ...
5
6
  uint8_t x = 0;
7
8
  if( x == true )
9
10
  / ...

anführt? Ich gebe zu, dass ich mich darüber bisher nicht weiter 
informiert habe.

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


Lesenswert?

Es ist einfach gültiges C, und absolut nichts, was es zu warnen gäbe.
bool ist als enum implementiert, und in C ist ein enum nichts anderes
als ein int.

In C++ sieht die Sache sehr viel anders aus.

von Karl H. (kbuchegg)


Lesenswert?

Jörg Wunsch wrote:
> Es ist einfach gültiges C, und absolut nichts, was es zu warnen gäbe.
> bool ist als enum implementiert, und in C ist ein enum nichts anderes
> als ein int.

Yep.
Das fällt für mich in die selbe Kategorie, wie dieses unselige
1
void foo( int bar[] )
2
{
3
 ...
4
}

Hier wird (in meinen Augen) etwas vorgetäuscht, was so einfach nicht
stimmt, nämlich die Übergabe eines Arrays. Erfahrene Programmierer
wissen was wirklich dahinter steckt, aber Neulinge fallen da
reihenweise hinein.

Da diese Schreibweise absolut identisch ist zu
1
void foo( int * bar )
2
{
3
 ...
4
}

frage ich mich ehrlich, wozu diese alternative Syntax gut sein soll.

Selbiges mit bool. Das ist doch reine Augenauswischerei. Ein bool
ist in C ein int. Mit etwas abweichender Schreibweise, aber
letztendlich ist das nur ein int. Und boolsche Ausdrücke funktionieren
für jemanden der neu zu C kommt nun mal nicht so wie er es erwarten
würde (vor allem wenn er bereits eine andere Sprache kennt).

  bool b = 5;

ist absolut legales, korrektes C. Das liegt sicherlich zunächst mal
daran, wie C mit enums umgeht, die in C ja nun wirklich ein ziemlicher
Bastard sind. Ähnlich wie die Arraysntax da oben sind sie eigentlich
zu nichts gut. Sie haben höchstens einen dokumentarischen Wert.
Ein
  void SetColor( enum Color col );
Prototyp erzählt mir als Leser nunmal mehr als
  void SetColor( int col );

Auf der anderen Seite verhindert er aber nicht, dass ich einen
Aufruf ala
  SetColor( 5 );
mache. Sicherheitstechnisch gesehen also eine absolute Katastrophe.

von die ??? (Gast)


Lesenswert?

Danke Jungs! Dann werde ich die stdbool.h wieder schleunigst 
vergessen, das ist wirklich Käse und gaukelt tatsächlich falsche 
Tatsachen vor. Da mir das nicht klar war haben wir etwas aneinander 
vorbei geredet; Ich dachte, dass man sich an C++ orientiert hat - schade 
dass dem nicht so ist.




P.S.
1
void foo( int bar[] )
2
{
3
 ...
4
}

Finde ich manchmal der Übersicht halber angenehm wenn man daran erinnern 
will, dass das Ziel der Adresse ein Array ist. Natürlich gehört das 
ordentlich Kommentiert. Geschmacksfrage.

von Rolf Magnus (Gast)


Lesenswert?

> Selbiges mit bool. Das ist doch reine Augenauswischerei. Ein bool
> ist in C ein int.

Nein! Zumindest nicht der aus stdint.h. Der ist ein typedef für _Bool, 
und das ist zwar im Prinzip so wie ich das sehe ein Integer, der aber 
explizit nur die Werte 0 und 1 kennt.

>  bool b = 5;
>
> ist absolut legales, korrektes C.

Das wäre aber auch in C++ korrekt. Das Resultat ist auch dasselbe. Der 
Wert von b entspricht nachher true (welche in C einfach als 1 #definiert 
ist).

von Rolf Magnus (Gast)


Lesenswert?

> Zumindest nicht der aus stdint.h. Der

Sorry, meinte natürlich stdbool.h

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


Lesenswert?

Naja, einen Vorteil haben enums (und damit auch die aus stdbool.h):
der Debugger kann mit ihren Werten umgehen.  Statt 0 und 1 zeigt
er also brav false und true an.

Ein zweiter minimaler Vorteil ist, dass der GCC bei einem
switch mit einem enum als Steuerausdruck warnt, wenn bestimmte
im enum definierte Werte vom switch nicht abgedeckt werden.
(Ist natürlich für bool/true/false eher nicht der Fall.)

stdbool.h hat den zusätzlichen Vorteil, dass man zumindest all
diese privaten Definitionen von TRUE und FALSE damit in die Tonne
kloppen kann.  Wenn jemand die nicht haben will und sowieso schon
immer mit 0 und 1 dafür gearbeitet hat: fein.  Aber wer bisher
irgendwelche teilweise haarsträubend umständlich anmutende
Konstrukte für seine eigenen Definitionen von TRUE und FALSE
benutzt hat, der sollte stattdessen ernsthaft das standardisierte
true und false benutzen.

Ansonsten ist es wahr, enums sind in C ziemlich stiefmütterlich
behandelt.

von let (Gast)


Lesenswert?

_Bool ist kein enum. Ein enum hat normalerweise >= 16Bit, _Bool hat
gewöhnlich 8Bit. Außerdem wird bei einer Umwandlung nach _Bool
ein logischer Vergleich durchgeführt.

Im C99 Draft heißt es:

6.3.1.2 Boolean type
1 When any scalar value is converted to _Bool, the result is 0
if the value compares equal to 0; otherwise, the result is 1.

Der avr-gcc hält sich auch daran:
1
#include <stdbool.h>
2
#include <stdint.h>
3
4
extern bool bValue;
5
extern uint8_t u8Value;
6
7
int main()
8
{
9
  bValue = u8Value;
10
  u8Value = bValue;
11
12
  return 0;
13
}
1
00000092 <main>:
2
  92:  80 91 60 00   lds  r24, 0x0060
3
  96:  81 11         cpse  r24, r1
4
  98:  81 e0         ldi  r24, 0x01  ; 1
5
  9a:  80 93 61 00   sts  0x0061, r24
6
  9e:  80 93 60 00   sts  0x0060, r24

u8Value wird anschließend entweder 0 oder 1 enthalten.

von Rolf Magnus (Gast)


Lesenswert?

> Naja, einen Vorteil haben enums (und damit auch die aus stdbool.h):

Nochmals: stdbool.h hat NICHTS mit enums zu tun. Es definiert vier 
Makros:

#define bool _Bool
#define true 1
#define false 0
#define __bool_true_false_are_defined 1

(bei gcc fehlt der letzte Eintrag). Und _Bool ist ebenfalls kein enum, 
sondern ein eingebauter Typ, der nur die Werte 0 und 1 annehmen kann.

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


Lesenswert?

Rolf Magnus wrote:

> Und _Bool ist ebenfalls kein enum,
> sondern ein eingebauter Typ, der nur die Werte 0 und 1 annehmen kann.

OK, wieder was gelernt.  Der Debugger stellt es als enum dar, daher
hatte ich mich nie näher um die Details gekümmert.

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.