Mark-Oliver Wolter wrote:
> Bodo Eggert <7eggert@nurfuerspam.de> wrote:
>> Mark-Oliver Wolter wrote:
>>> Wenn die language lawyer sagen, daß C99 das Verhalten des Optimierers
>>> erlaubt, dann ist das sehr wohl ein Argument gegen C, dann ist nämlich
>>> nicht der Optimierer kaputt, sondern C selbst.
>> C sagt, daß das Verhalten der Programmierer nicht erlaubt ist. Der
>> Programmierer hat bei (foo *) p + (int) i sicherzustellen, daß die
>> Rechnung den Datenbereich + ein Feld nicht verläßt.
>
> Das Dumme daran ist nur, daß eben der wegoptimierte Vergleich der Versuch
^^^^^^^
> eben dieser Sicherstellung war.
Ja. Und wenn vorher sichergestellt wäre, daß kein Überlauf stattfindet,
könnte man so auch sicherstellen, daß kein Überlauf stattfindet.
>> Je nach Speichermodell
>> kann so eine Rechnung einige tausend male überlaufen, das Ergebnis hat mit
>> einem korrekten Indexbereich dann recht wenig zu tun.
>
> Ist halt blöd, wenn man erst weiß, ob eine Rechnung gültig ist, wenn man
> sie ausführt, das Sprachmodell aber die Überprüfung dessen sabotiert ...
Ob die Rechnung richtig ist, weiß man, wenn man den aktuellen Index von *p
im Datenbereich sowie den interessanten Gültigkeitsbereich kennt. Eine
Rechnung á la "i=65536; if (p+i < p || p+i > sizeof(*p)) ..." erzählt einem
nicht zuverlässig, daß man den Indexbereich verlassen hat.
(32-Bit Integer, 16-Bit Segment + Offset, Offset = (Offset + n*i) %% 65536)
> Wie würdest Du es denn machen? Spielereien mit sizeof und hoffen, daß die
> Architektur keine, ähm, Besonderheiten hat? Workaround mit typecasts und
> hoffen, daß im gcc-Team keiner auf die Idee kommt, mit demselben Argument
> die Wegoptimierung auch bei diesen durchzuführen? C verfluchen und wegwerfen?
if (i < 0 || i > maxindex) ...
Anders kann man es nicht machen.
