[Megoldva] warning: Unsequenced modification and access to 'j'

>Ezt a warningot egyébként a Qt Creator zúdítja rám.

Nem a fordítóból veszi? Saját értelmezője és warningjai vannak? Nem hinném. Nézz utána, hogy milyen parancsot futtat, gondolom szigorúbb warningokat kér magától, mint ahogy te szoktad paraméterezni a fordítót.

IMHO ez a j++ indexben már önmagában is zavaró, én a falra mászok ezektől. Nálam ez így nézne ki: {buff[j] = p[j]; j++;} Minek terheljem az olvasót azzal, hogy akkor ez posztfix, tehát kiértékelés után lesz inkrementálva és satöbbi? Leírnám úgy ahogy történik sorban és kész. Ezeket már tényleg kibogozza a fordító optimálisra akárhogy is írod az ekvivalens kifejezéseket.

buff[j++] = p[j]

A derék fordító maga dönthet arról, hogy ebből mit generál:
#1:

char *tmp= &buff[j];
++j;
*tmp = p[j]

#2:

buff[j] = p[j];
++j;

https://en.cppreference.com/w/cpp/language/eval_order

"Order of evaluation of any part of any expression, including order of evaluation of function arguments is unspecified (with some exceptions listed below). The compiler can evaluate operands and other subexpressions in any order, and may choose another order when the same expression is evaluated again.

There is no concept of left-to-right or right-to-left evaluation in C++. This is not to be confused with left-to-right and right-to-left associativity of operators: the expression a() + b() + c() is parsed as (a() + b()) + c() due to left-to-right associativity of operator+, but c() may be evaluated first, last, or between a() or b() at runtime"

Eleg egyertelmu, nem kell ezt tulragozni.

Ez így elég átláthatatlan, ez az a fajta hekkes kódírás, amit nem kéne C-ben tolni, sokan az ilyen agymenések miatt utálják a C-t. Nekem az jön le, hogy egy átlag C fordító előbb megnöveli a j értékét, így a p[j]-ben a j már egyel meg lesz növelve a kifejezés végén. Semmit nem nyersz, ha ilyen tömör vagy, használj egy átmeneti változót, és írd úgy a kódot, hogy egyértelmű lépései legyenek a kiértékelésnek, így a kódod az összes fordítóval azonosan fog működni. Ezen így semmit nem nyersz, hogy megúszol ugyan egy átmeneti változót, de közben a kód kétértelműségbe, meg előre láthatatlan hibákba fut, ez inkább nekem szándékosan önszopatásnak tűnik.

TL;DR: a compiler warningok általában jogosak, de legalábbis érdemes kivizsgálni miért jönnek. (Na mondjuk a 'dereferencing type punned pointer' az fasság: azért warning-ol, mert különböző tipusú pointerek között type-cast-olsz. Igen, mert ha azonos típusúak lennének, akkor nem kellene a type-cast.)

buff[j++] = p[j];

Az eddig rögzített kommentek legjobb esetben is csak részben válaszolják meg azt a kérdést, hogy a fenti kifejezés miért Undefined Behavior (mert hát az). Az eddigi kommentekre csak felületesen pillantottam rá, viszont rákerestem, és senki sem idézte eddig a lényegi részt a C szabványból. A C99 6.5 Expressions p2-ben ugyanis ez szerepel:

Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.

A C17-ben (és feltehetően már a C11-ben is) egy jóval komplikáltabb megfogalmazás szerepel (6.5 Expressions p1, p2):

[...] The value computations of the operands of an operator are sequenced before the value computation of the result of the operator.

If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings.

Először arról írnék, hogy a C17-ben (ill. C11-ben) található szöveg miért sokkal bonyolultabb, mint ami a C99-ben van. Azért, mert C11 óta van a C-ben többszálúság, atomi hozzáférés, és memóriamodell; ezek pedig a szekventálást elbonyolítják. A C17-ben található leírás valójában a C99-ben található leírás általánosítása. C99-ben szekvenciapontokról és adatfüggőségről beszélünk (ld. lent), C11-től viszont olyan fogalmak vannak explicite definiálva, mint sequenced before, sequenced after, unsequenced, indeterminately sequenced stb.

A C17-ből idézett első paragrafus végén található mondat az adatfüggőségről kijelenti, hogy az szekventál (The value computations of the operands of an operator are sequenced before the value computation of the result of the operator), a második paragrafus pedig megköveteli, hogy skalár objektumon bármely mellékhatás szekventált legyen bármely (ugyanarra a skalár objektumra vonatkozó) másik mellékhatáshoz képest, illeve bármely (ugyanarra a skalár objektumra vonatkozó) értékszámításhoz képest. Ez a megfogalmazás a C99-es szöveg általánosítása.

A fenti kifejezésről mindkét szabványverzió szerint beláthatjuk, hogy Undefined Behavior.

C99 szerint: az idézett kifejezésen belül nincs szekvenciapont, csak a végén van egy (van egy expression-statement-ünk, ami egy full expression; ez utóbbi végén van egy szekvenciapont). A "j" objektumot egyszer módosítjuk (ami kielégíti az "at most once" követelményt). Viszont a "j"-t kétszer olvassuk ki, és ebből nem az összes olvasás olyan, hogy szükség van rá a "j" új értékének meghatározásához. A p[j] kifejezésben a "j"-t úgy olvassuk ki, hogy a "j"-ben eltárolandó új érték nem függ ettől az olvasástól. Emiatt ez a teljes kifejezés Undefined Behavior. A lényeg az, hogy a fordító tetszőleges relatív sorrendben kiértékelhet bármely két alkifejezést, amennyiben azok között nincs sem szekvenciapont, sem adatfüggőség.

C17 szerint: a szabvány szövege bonyolultabb, viszont az alkalmazása egyszerűbb. Az adott kifejezésben nincs olyan ⓧ operátor, amelynek a "j" (akár közvetve) az operandusa lenne, és amely ⓧ operátor eredményétől a "j++" függene (és viszont). Tehát a p1-ben található "sequenced before" kitétel az adott kifejezésre alkalmazhatatlan. Ennélfogva a "j" és a "j++" kifejezések szekventálatlanok (másként: topologikusan rendezetlenek), ami a p2 szerint Undefined Behavior.

A topiknyitóban megoldásként megjelölt komment nem válasz a kérdésre. Egyrészt nem a szabványból idéz. Másrészt az ott (helyesen) hivatkozott Unspecified Behavior az adott kifejezésnél lényegtelen; nekünk itt Undefined Behavior-ünk van, nem Unspecified Behavior-ünk. Itt egy összefoglaló, a C99-ből (3. Terms, definitions, and symbols):

undefined behavior -- behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

unspecified behavior -- behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance

implementation-defined behavior -- unspecified behavior where each implementation documents how the choice is made

Magyarra ezt így lehet fordítani:

1. Undefined behavior: a szabvány nem mondja meg, hogy mi történik, és az adott konstrukció hibás. A konkrét nyelvi implementációra nem vonatkozik semmilyen megkötés.
2. Unspecified behavior: a szabvány nem mondja meg, hogy pontosan mi történik (több lehetőség közül), de az adott konstukció érvényes. A konkrét nyelvi implementációnak a megengedett alternatívák valamelyikét kell biztosítania (esetenként külön-külön); dokumentálnia nem kell a választást.
3. Implementation-defined behavior: a szabvány nem mondja meg, hogy pontosan mi történik (több lehetőség közül), de az adott konstukció érvényes. A konkrét nyelvi implementációnak dokumentálnia kell, hogy mi történik.

Az itt szereplő kifejezés Undefined Behavior, nem Unspecified Behavior. Ugyanis:

• az idézett C99 paragrafus a "shall" szót használja, méghozzá Constraint-en kívül -- így  a követelmény megszegése Undefined Behavior (C99 4. Conformance, p2);
• az idézett C17-es rész pedig explicite Undefined Behavior-t ír.

A hivatkozott komment alapját képező Unspecified Behavior létezik, de ennél a kérdésnél irreleváns. Viszont ha már beszélünk róla: így van leírva a C99-ben (6.5 Expressions, p3):

The grouping of operators and operands is indicated by the syntax. [...] Except as specified later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation of subexpressions and the order in which side effects take place are both unspecified.

illetve 6.5.2.2 Function calls, p10:

The order of evaluation of the function designator, the actual arguments, and subexpressions within the actual arguments is unspecified, but there is a sequence point before the actual call.

Erre egy példa:

#include <stdio.h>

static int
f(int i)
{
  printf("%d\n", i);
  return i;
}

int
main(void)
{
  printf("%d %d %d\n", f(1), f(2), f(3));
  return 0;
}

A program négy sort fog kiírni (IO hibáktól most eltekintve); az utolsó sorban "1 2 3" fog szerepelni. Az első három sorban viszont az (1, 2, 3)-nak tetszőleges permutációja megjelenhet, és ezek közül mind helyes, és a nyelvi implementációnak nem kell dokumentálnia / megígérnie a sorrendet (még azt sem kell megígérnie, hogy mindig ugyanabban a sorrendben történik az f() három meghívása -- lásd fentebb az in any instance kitételt). Ezt jelenti az Unspecified Behavior.

Az más kérdés, hogy a szabványban ez is szerepel (C99 4. Conformance, p5):

A strictly conforming program shall use only those features of the language and library specified in this International Standard. [...] It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit.

Tehát az helyes törekvés, hogy mindhárom jellegű viselkedést elkerüljük, de összemosni azokat nem jó.