Merkwürdiges Array mit 32-Bit GCC (Linux)

fängt der Index nixht bei 0 an ?

leo schrieb:
> Ralph S. schrieb:
>> scanf("%d", &wahl);
>
> ASCII '0' .. '9' ist nicht gleich Zahl 0 .. 9.
>
> leo

Das ist Humbug, %d liest eine Zahl und keinen ASCII ein (allerdings - 
und logischerweise - wie wir am Beitrag von foobar sehen, einen 4-Byte 
Wert, der fälschlicherweise einem unsigned char zugeordnet wurde).

foobar schrieb:
> Hier hapert es: uint8_t wahl, ...;
>  ...
>  scanf("%d", &wahl);
>
> Der scanf erwartet einen int-Pointer und schreibt auch ein int (4
> Bytes).

Das hier ist die richtige Antwort (und mir auf den Kopf haue)

Joachim D. schrieb:
> fängt der Index nixht bei 0 an ?

schon, deswegen steht dort ja auch:

1

    dat= rflags[wahl-1];

denn: 1 - 1 = 0

--------------------------------------------------

Vielen Dank an foobar

Was foobar schreibt.

Da sollte der Compiler aber eine Warnung raus hauen.

Er muss so eingestellt werden, dass er das macht.

In stdint.h sind auch die Formatspecifier der Typen für scanf mit 
definiert.

Dirk B. schrieb:
> Da sollte der Compiler aber eine Warnung raus hauen.

Das tut er mit -Wall oder -Wformat auch, sogar sehr ausführlich:

1

test.c:33:37: warning: format ‘%d’ expects argument of type ‘int *’, but argument 2 has type ‘uint8_t *’ {aka ‘unsigned char *’} [-Wformat=]

2

   33 |     printf("\n\nEingabe: ");scanf("%d", &wahl);

3

      |                                    ~^   ~~~~~

4

      |                                     |   |

5

      |                                     |   uint8_t * {aka unsigned char *}

6

      |                                     int *

7

      |                                    %hhd

Yalu X. schrieb:
> Das tut er mit -Wall oder -Wformat auch, sogar sehr ausführlich:

Das war der Hinweis, die Warnungen zu aktivieren und dann auch zu 
beachten.

"Sind ja nur Warnungen. Egal, die EXE hat er ja gemacht."

Smile, die Warnungen hat er auch ausgegeben... allerdings (Asche auf 
mein Haupt) waren die Warnungen weit oberhalb der nachfolgenden 
Compilermeldungen anderer eingebundener Sourcen und nicht zu sehen und 
ich habs bei der Durchsicht auf dem Ausbildungsrechner nicht bemerkt.

Im übrigen gebe ich der Einfachkeit wegen die Programmierübungen auf 
einem Linuxsystem aus und vin daher wird keine .exe erzeugt.

Aaaber, foobar hats gefunden (und der Compiler auch)... und wer lesen 
kann ist klar im Vorteil

Ralph S. schrieb:
> daher wird keine .exe erzeugt.

Das EXE ist als Kurzform für Executable gemeint.

DOS (und auch Windows) benötigen das .exe als Dateinamenerweiterung.

 *ix Systeme benötigen diese Kennzeichnung nicht. Dennoch bleibt es eine 
EXE ?


Wird am Ende keine Erfolgsmeldung (1 Warnung, 0 Fehler) mehr ausgegeben?

Dirk B. schrieb:
> *ix Systeme benötigen diese Kennzeichnung nicht. Dennoch bleibt es eine
> EXE ?

das stand aber im Kontext zu "... die 'EXE' hat er(der gcc) ja 
gemacht..." -
und das ist zumindest missverständlich, denn executables entstehen durch 
das das setzen des X-Bits ... und sind keine Aufgaben des `Compilers 
oder Linkers

Walter K. schrieb:
> und das ist zumindest missverständlich, denn executables entstehen durch
> das das setzen des X-Bits ...

Das gibt nur das Recht zur Ausführung.
Kann ich einem Bild (jpg) auch geben, bringt aber nichts.

> ... und sind keine Aufgaben des `Compilers
> oder Linkers

Die machen die technische Seite (für Binaries)

... unglaublich....

Ich kenne kein anderes Forum als das hier (egal welches Fachgebiet), wo 
es so extrem pingelig ist wie hier

Ralph S. schrieb:
> so extrem pingelig

sind Computer/Compiler doch auch.

Und man redet sonst aneinander vorbei.

Ralph S. schrieb:
> Ich kenne kein anderes Forum als das hier (egal welches Fachgebiet), wo
> es so extrem pingelig ist wie hier

Aber du hast das doch selbst durch eigene Pingeligkeit angestoßen:

Dirk B. schrieb:
> "Sind ja nur Warnungen. Egal, die EXE hat er ja gemacht."

Ralph S. schrieb:
> Im übrigen gebe ich der Einfachkeit wegen die Programmierübungen auf
> einem Linuxsystem aus und vin daher wird keine .exe erzeugt.

Ob das jetzt eine .exe-Datei ist oder nicht, spielt doch gar keine 
Rolle. Es ging lediglich darum, dass man Warnungen nicht ignorieren 
sollte.

Rolf M. schrieb:
> Ob das jetzt eine .exe-Datei ist oder nicht, spielt doch gar keine
> Rolle. Es ging lediglich darum, dass man Warnungen nicht ignorieren
> sollte.

Warnungen sollte man nie ignorieren, deswegen ja auch "Asche über mein 
Haupt". Zudem war das ja "nur" ein Code bei dem ich den Fehler gesucht 
habe und der nicht von mir war (der mir aber hätte auch passieren 
können).

Schlicht weil in Verbindung mit 8-Bit Controllern eine Variable 
(zumindest bei mir) häufiger uint8_t ist.

Wobei: Selbst auf einem 8-Bit System (jetzt aus dem hohlen Bauch heraus) 
würde ein

scanf("%d", &wahl);

einen Zeiger auf einen 16-Bit Integer zurück liefern.

Schmunzeln muss: Mit "pingelig" meinte ich, was für eine 
Threadverlängerung hier eintritt nachdem die Erklärung bereits geliefert 
worden ist.

Ich arbeite mit einem eigenen Konsoleneditor und bin jetzt am überlegen, 
wie ich eventuell einen Browser für Compilerwarnungen realisieren 
könnte.

Im Moment sieht es so aus, dass es am unteren Bildschirmrand einen 
Ausgabe der Compilermeldungen gibt und, wenn dieses zu klein eingestellt 
ist man nicht sieht, dass es Warnungen gegeben hat. Ich hätte schlicht 
dieses Fenster scrollen sollen und dann wäre mir das wahrscheinlich 
(sagen wir zu 90%) aufgefallen.

Allerdings muß ich auch sagen, dass ich beeindruckt bin, wie schnell 
manche (hier war es foobar) Programmcodes analysieren und das Falsche 
sehen (und ich dachte schon, ich wäre darin gut).

Dass eine Variable den falschen Typ hat habe ich in diesem Fall schlicht 
übersehen (und schlichtweg deshalb, weil ich ansonsten mit eigenen 
Eingaberoutinen und nicht mit scanf arbeite).

Ralph S. schrieb:
> Ich arbeite mit einem eigenen Konsoleneditor und bin jetzt am überlegen,
> wie ich eventuell einen Browser für Compilerwarnungen realisieren
> könnte.

Selbsterfundene Räder rollen einfach besser…