GCC Compiler Warnungen

[Phillip H. (philharmony)]

Ich habe noch einige Warnungen beim Compilieren deren Ursache ich noch 
ausmerzen möchte.

1. An mehreren Stellen die "...discards qualifiers from pointer target 
type"

Zb benutze ich strchr und strlen in einem volatile char array. Wie 
kriege ich diese Warnung weg?

An anderer Stelle verweise ich auch auf volatile arrays und er meckert 
bei der initialisierung von structs in denen Zeiger auf Elemente dieser 
Arrays sind. Wie teile ich ihm mit daß das so sein soll? Die Arrays 
werden nunmal in interrupts geschrieben und in der main ausgelesen...

2.
Als nächstes benutze ich
sscanf(string, "%d-%d", &s1, &s2)
s2 soll aber jetzt vom typ unsigned long sein, was benutze ist da 
anstatt %d?

3.
"array subscript is above array bounds"
ich habe ein array mit 18 Elementen und rufe hier

while((figure[i] == ZERO) && (i>0))
{
  figure[i] = BLANC;  //bis dahin alle anführenden nullen durch BLANC ersetzen
 i--;  //i decrement
}

Elemente davon auf. Wo liegt das problem?

[Stefan E. (sternst)]

Phillip Hommel schrieb:

> 1. An mehreren Stellen die "...discards qualifiers from pointer target
> type"
>
> Zb benutze ich strchr und strlen in einem volatile char array. Wie
> kriege ich diese Warnung weg?

Dann musst du einen Cast verwenden.

> An anderer Stelle verweise ich auch auf volatile arrays und er meckert
> bei der initialisierung von structs in denen Zeiger auf Elemente dieser
> Arrays sind. Wie teile ich ihm mit daß das so sein soll? Die Arrays
> werden nunmal in interrupts geschrieben und in der main ausgelesen...

Auch einen Cast verwenden. Aber Vorsicht wenn du über die Zeiger in den 
Structs darauf zugreifst. Statt überall die Warnungen mit Casts zu 
beseitigen, wäre hier wohl auch noch mal ein Nachdenken bezüglich des 
Designs nötig (also z.B. ob in den Struct-Definitionen nicht noch ein 
paar volatiles nachzutragen sind).

> 3.
> "array subscript is above array bounds"
> ich habe ein array mit 18 Elementen und rufe hier
>

> while((figure[i] == ZERO) && (i>0))
> {
>   figure[i] = BLANC;  //bis dahin alle anführenden nullen durch BLANC
> ersetzen
>  i--;  //i decrement
> }
>

> Elemente davon auf. Wo liegt das problem?

Wie sieht der Code davor aus? Wie wird i initialisiert?

[Phillip H. (philharmony)]

Ich muß gesetehen daß ich mir da bisher nie Gedanken drum gemacht habe 
und daher die Problematik nicht ganz durchschaue. Warum interessiert es 
denn die funktion ob die variable nun volatile (also ständig 
aktualisiert und gelesen/geschrieben) wird oder nicht?
Wie würde bei der strlen/strchr-geschichte denn der cast gehen?

In den struct-definitionen habe ich jetzt auf den bemängelten Zeigern 
auf int/unsigned char Zeiger auf volatile int/ unsigned char gemacht. 
Warnungen sind weg, aber auch hier war mir nicht bewußt daß das für die 
entsprechenden Funktionen überhaupt wichtig ist.

Die Sache mit den Array Bounds:
i wird mit
unsigned char i;
initialisiert und danach von ein paar schleifen benutzt (die i jedes mal 
mit 0 initialisieren)
Dann setze ich
i=5 und danach kommt o.g. code

[(prx) A. K. (prx)]

Phillip Hommel schrieb:

> Ich muß gesetehen daß ich mir da bisher nie Gedanken drum gemacht habe
> und daher die Problematik nicht ganz durchschaue. Warum interessiert es
> denn die funktion ob die variable nun volatile (also ständig
> aktualisiert und gelesen/geschrieben) wird oder nicht?

Der Funktion ist das relativ egal. Dem Compiler nicht. Der überprüft 
Typen und mosert wenn deklarierter Parameter und übergebenes Argument 
nicht zusammen passen.

> Wie würde bei der strlen/strchr-geschichte denn der cast gehen?

Das übergebe Argument so casten, dass es zum Parameter von strlen passt. 
Das ist üblicherweise (char *).

[Phillip H. (philharmony)]

Ok, soweit verstanden. Die Meisten Warnung sind damit weg, danke dafür 
erstmal!
Es bleibt noch die Array Bounds Warnung

Edit: und noch ne Frage zu casts:
Wenn ich ein unsigned long nach int caste, nimmt er dann high-part oder 
den low part?

[(prx) A. K. (prx)]

Phillip Hommel schrieb:

> Es bleibt noch die Array Bounds Warnung

Siehe Frage von Stefan.

> Wenn ich ein unsigned long nach int caste, nimmt er dann high-part oder
> den low part?

Was würdest du machen, wenn du eine solche Programmiersprache definieren 
würdest?

Ok, wer immer PL/1 erfunden hat war da anderer Ansicht, aber halbwegs 
vernünftige Menschen kommen dabei m.E. immer zum gleichen Ergebnis.

[Stefan E. (sternst)]

Phillip Hommel schrieb:

> In den struct-definitionen habe ich jetzt auf den bemängelten Zeigern
> auf int/unsigned char Zeiger auf volatile int/ unsigned char gemacht.
> Warnungen sind weg, aber auch hier war mir nicht bewußt daß das für die
> entsprechenden Funktionen überhaupt wichtig ist.

Wo und ob das volatile wichtig ist, kann dir hier ohne den Code auch 
niemand beantworten.

> Die Sache mit den Array Bounds:
> i wird mit
> unsigned char i;
> initialisiert und danach von ein paar schleifen benutzt (die i jedes mal
> mit 0 initialisieren)
> Dann setze ich
> i=5 und danach kommt o.g. code

Vor der Schleife steht explizit ein "i = 5;"?
Du kannst mal versuchen, die beiden Bedingungen im while zu vertauschen.

[Phillip H. (philharmony)]

>Siehe Frage von Stefan.
Hab sie doch oben beantwortet

>Was würdest du machen, wenn du eine solche Programmiersprache definieren
>würdest? (..)halbwegs
>vernünftige Menschen kommen dabei m.E. immer zum gleichen Ergebnis.
Die Frage is fies, aber ich setz mich jetzt mal in die Nesseln und sage 
Low Part ;)

Ok, und eine neue ist jetzt noch aufgetaucht:

char* p_devider = strchr((char*)rx_data, '-'); //pointer auf Trennzeichen

Warnung: initialisation discards...
Warum das nun? strchr gibt doch char* zurück und den Zeiger auf volatile 
char rx_data habe ich zu (*char) um(?)-gecastet.

>Vor der Schleife steht explizit ein "i = 5;"?
>Du kannst mal versuchen, die beiden Bedingungen im while zu vertauschen.

Habs gefunden, ich hatte 2 Arrays und hatte noch ein paar alte defines 
drin bei denen ich noch aufs alte array verwiesen hatte.

[Phillip H. (philharmony)]

So, alle gelöst...warum auch immer die letzte jetzt plötzlich weg ist.
Danke an alle!