mein GCC bringt obenstehende Warnung, wenn bei einem Feld (bereits im statischen Quellcode) der Index zu groß wird. Dabei warnt er, wenn der Indexzahl größer als die Arraygröße wird. Eigentlich müsste er doch schon bei Indexzahl gleich Arraygröße warnen, weil das Nullte Element ja das erste im Array ist und somit Arraygröße -1 das letze Element angibt ?
Gast
#1511444
Da du keinen Quelltext lieferst, ist es schewr eine aussage zu machen. Es kann sein dass der Compiler sein eigneen Aliasing berücksichtigt und z.B. erkennt, dass, wenn du ein CharArray[5] anlegst, bei 32bit ausrichtung der Index CharArray[7] sogar noch gültig ist, auch wenn er über den Arraygrenzen liegt. (die nächste variable würde ja erst bei CharArray[8] beginnen) Ist aber nur vermutung. MFG
> Da du keinen Quelltext lieferst, ist es schewr eine aussage zu machen. So ist es. > Es kann sein dass der Compiler sein eigneen Aliasing ... Alignment ... >berücksichtigt und > z.B. erkennt, dass, wenn du ein CharArray[5] anlegst, bei 32bit > ausrichtung der Index CharArray[7] sogar noch gültig ist, Nein. Nach Standard verursacht das "Undefined behaviour". In realen Implementationen mag das meist hinhauen, aber "gültig" ist es deshalb noch lange nicht.
Gast
#1511932
Andere Idee: Nach Standard ist der Pointerwert a+8 bei einem als T a[8] definierten Array noch definiert (bedeutet, man kann ne for-Schleife übers Array machen und die Abbruchbedingung aus dem laufenden Pointer selbst ableiten). Man darf ihn nur nicht dereferenzieren. a+9 ist dagegen undefined (also auch das Ergebnis der Pointerarithmetik selbst; hier kann, je nach Lage von a im Speicher ein Wraparound über das Adressraumende oder ein Segmentende auf Plattformen mit segmentiertem Speicher stattgefunden haben, so dass ein Vergleich oder eine Pointerdifferenz nachher Unsinn liefert). Kann sein, dass gcc deswegen bei der Warnung genau so prüft, auch, wenn es hier nicht genau passt (da je dereferenziert wird).