Poll
Reacties (34)
15-08-2016, 13:38 door
Briolet
Zal niet anders zijn voor Algol 60, Pascal of JS. Dus waarom specifiek voor C ?
Door Briolet: Zal niet anders zijn voor Algol 60, Pascal of JS. Dus waarom specifiek voor C ?
Integer Overflows!
maakt niet uit...IS ALTIJD WAAR
en als iemand zegt: "stommeling, dat is fout!". Dan geef ik hem volkomen gelijk!
en als iemand zegt: "stommeling, dat is fout!". Dan geef ik hem volkomen gelijk!
a = 1
b = 1
niet waar
a = -1
b = -1
waar
a = -1
b = 1
niet waar
a = 1
b = -1
waar
b = 1
niet waar
a = -1
b = -1
waar
a = -1
b = 1
niet waar
a = 1
b = -1
waar
Voor de leesbaarheid (in de zin van begrijpelijkheid) en dus betrouwbaarheid van source code is het verstandig om niet te vertrouwen op de kennis van operator precedence van de initiële programmeur, reviewer, latere wijziger etc. en eventueel leed bij voorbaat uit te sluiten met precies voldoende ronde haken. Dan wordt het statement, volgens [1]:
Aangezien je niet weet van welk types a en b zijn (het kunnen zelfs macro's zijn) noch hun waardes kent, zijn overflows, underflows en zelfs NaN's niet uit te sluiten (@Briolet: dus niet alleen integer overflows) en is "x86" overbodige informatie.
Stel:
dan zal het antwoord vermoedelijk in veel gevallen "niet waar" opleveren ;-)
maar volgens [2] moet je dit niet willen.
Ik hou het op antwoord 5: mogelijk een compile time of een run time error en zo niet: geen flauw idee van de uitkomst.
[1] http://en.cppreference.com/w/c/language/operator_precedence
[2] https://www.securecoding.cert.org/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+not+refer+to+the+same+array
if ((a + b) < a)
Stel:
char* a = "1";
char* b = "-1";
if ((a + b) < a)
char* b = "-1";
if ((a + b) < a)
maar volgens [2] moet je dit niet willen.
Ik hou het op antwoord 5: mogelijk een compile time of een run time error en zo niet: geen flauw idee van de uitkomst.
[1] http://en.cppreference.com/w/c/language/operator_precedence
[2] https://www.securecoding.cert.org/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+not+refer+to+the+same+array
15-08-2016, 17:27 door
Skizmo
Door Erik van Straten:
Stel:
Stel:
char* a = "1";
char* b = "-1";
if ((a + b) < a)
char* b = "-1";
if ((a + b) < a)
"Cannot add 2 pointers" ;)
Volgens mij zijn het wiskundige variabelen:
Als a=1 EN b=-1, dan is a<a+b, want 1-1=0, dus is a<a waar.
Etc, etc...
Als a=1 EN b=-1, dan is a<a+b, want 1-1=0, dus is a<a waar.
Etc, etc...
Door Erik van Straten:
char* a = "1";
char* b = "-1";
if ((a + b) < a)
char* b = "-1";
if ((a + b) < a)
Neem a een integer en b een array van integers ... dan kan er veel boeiends gebeuren.
16-08-2016, 09:49 door
john west
b = altijd een negatief getal.
Als a negatief is dan is b nog negatiever.
Als a negatief is dan is b nog negatiever.
16-08-2016, 09:51 door
yobi
Waar als b een negatief getal is en niet waar als b nul of een positief getal is.
Door Skizmo:
"Cannot add 2 pointers" ;)
Welke gammele C compiler geeft die error? Pointer arithmic is juist een van de krachten van C. Als je daartegen "beschermd" wil zijn ga je maar in Java of C# programmeren."Cannot add 2 pointers" ;)
16-08-2016, 11:46 door
Briolet
Door Erik van Straten: Voor de leesbaarheid (in de zin van begrijpelijkheid)
In zijn algemeenheid heb je gelijk, maar in dit specifieke geval moeten de haken wegblijven omdat de kennis van de lezer gevraagd wordt hoe C dit interpreteert: ((a + b) < a) of (a + (b < a))
Door Erik van Straten: Aangezien je niet weet van welk types a en b zijn (het kunnen zelfs macro's zijn)…
De types maken ook niets uit, ook niet of C in sommige gevallen een integer overflow genegeerd. Zolang je maar één combinatie kunt vinden die waar is en één combinatie die niet waar is, dan moet het antwoord al 'is soms waar' zijn.
Ik ben misschien wat te streng in de leer maar op zichzelf is de vraag of if(a + b < a) altijd waar is vreemd. Een "If" beinvloed namelijk de programming flow.
Of "a + b < a" altijd waar is een andere vraag....
Ha ha...
Of "a + b < a" altijd waar is een andere vraag....
Ha ha...
16-08-2016, 11:46 door Briolet:
De types maken ook niets uit, ook niet of C in sommige gevallen een integer overflow genegeerd. Zolang je maar één combinatie kunt vinden die waar is en één combinatie die niet waar is, dan moet het antwoord al 'is soms waar' zijn.
Nee, want zoals Skizmo gisteren al aangaf:Door Erik van Straten: Aangezien je niet weet van welk types a en b zijn (het kunnen zelfs macro's zijn)…
De types maken ook niets uit, ook niet of C in sommige gevallen een integer overflow genegeerd. Zolang je maar één combinatie kunt vinden die waar is en één combinatie die niet waar is, dan moet het antwoord al 'is soms waar' zijn.
15-08-2016, 17:27 door Skizmo:
"Cannot add 2 pointers" ;)
Door Erik van Straten:
Stel:
Stel:
char* a = "1";
char* b = "-1";
if ((a + b) < a)
char* b = "-1";
if ((a + b) < a)
"Cannot add 2 pointers" ;)
En dat klopt, want de source "test1.c":
#include <stdio.h>
void main() {
char* a="1";
char* b="-1";
if (a + b < a) {
printf("waar\n");
}
else {
printf("niet waar\n");
}
}
void main() {
char* a="1";
char* b="-1";
if (a + b < a) {
printf("waar\n");
}
else {
printf("niet waar\n");
}
}
Error E2085 test1.c 5: Invalid pointer addition in function main
De volgende code "test2.c" compileert wel:
#include <stdio.h>
void main() {
char* a="1";
char* b="-1";
if (a + (unsigned long)b < a) {
printf("waar\n");
}
else {
printf("niet waar\n");
}
}
void main() {
char* a="1";
char* b="-1";
if (a + (unsigned long)b < a) {
printf("waar\n");
}
else {
printf("niet waar\n");
}
}
niet waar
Om aan te tonen dat, naast compile time errors, ook run time errors mogelijk zijn, test3.c:
#include <stdio.h>
#include <float.h>
void main() {
float a=DBL_MAX;
float b=DBL_MAX;
if (a + b < a) {
printf("waar\n");
}
else {
printf("niet waar\n");
}
}
#include <float.h>
void main() {
float a=DBL_MAX;
float b=DBL_MAX;
if (a + b < a) {
printf("waar\n");
}
else {
printf("niet waar\n");
}
}
Wellicht is test4.c nodig om je te overtuigen:
#include <stdio.h>
#define a printf("nog een mogelijkheid\n")
#define b exit(1)
void main() {
if (a + b < a) {
printf("waar\n");
}
else {
printf("niet waar\n");
}
}
#define a printf("nog een mogelijkheid\n")
#define b exit(1)
void main() {
if (a + b < a) {
printf("waar\n");
}
else {
printf("niet waar\n");
}
}
nog een mogelijkheid
En dat is ook de reden dat ik, bij gebrek aan een optie 5 (zie mijn eerdere bijdrage) maar voor optie 4 gekozen heb: "Snap ik niets van" ;-)
16-08-2016, 17:08 door
Erik van Straten
OK Briolet, het kwartje viel zojuist en ik geef me gewonnen: "is soms niet waar" was ook een correct antwoord geweest....
Zucht, you win :-(
Zucht, you win :-(
Met lichte twijfel neig ik naar: "Snap ik niets van."
De boolean vergelijking (a + b < a) kan waar zijn of niet waar zijn. Echter dat was hier niet de vraag.
In de vraag ging het om "if(a + b < a)".
En dat is strikt genomen toch wat anders.
if(a + b < a) is een conditioneel statement die het programmaverloop bepaald op grond van of (a + b < a) waar is of niet.
Je vraagt bijv. ook niet: "Als mijn hond groter is dan de hond van de buren, is dat waar of niet waar?"
Het zou nergens op slaan.
Maar je kan bijv. wel vragen: "Mijn hond is groter dan de hond van de buren, is dat waar of niet waar", of:
"Is mijn hond groter dan de hond van de buren?" (dus zonder "als")
Echter als "if(if(a + b < a))" legaal is, en bovendien altijd precies dezelfde werking heeft als "if(a + b < a)" ben ik wel bereid
om toe te geven dat zoiets raars in de wereld van programmeertaal C toch mogelijk is.
Goeroehoedjes
De boolean vergelijking (a + b < a) kan waar zijn of niet waar zijn. Echter dat was hier niet de vraag.
In de vraag ging het om "if(a + b < a)".
En dat is strikt genomen toch wat anders.
if(a + b < a) is een conditioneel statement die het programmaverloop bepaald op grond van of (a + b < a) waar is of niet.
Je vraagt bijv. ook niet: "Als mijn hond groter is dan de hond van de buren, is dat waar of niet waar?"
Het zou nergens op slaan.
Maar je kan bijv. wel vragen: "Mijn hond is groter dan de hond van de buren, is dat waar of niet waar", of:
"Is mijn hond groter dan de hond van de buren?" (dus zonder "als")
Echter als "if(if(a + b < a))" legaal is, en bovendien altijd precies dezelfde werking heeft als "if(a + b < a)" ben ik wel bereid
om toe te geven dat zoiets raars in de wereld van programmeertaal C toch mogelijk is.
Goeroehoedjes
17-08-2016, 11:59 door
Erik van Straten
@Goeroehoedjes: je hebt gelijk. In C is if een conditionele goto en levert geen resultaat op:
levert dan ook een compile time error op.
Ter illustratie, op (imaginair) CPU niveau gebeurt het volgende (X is een "gewoon" CPU register, en S is het CPU statusregister), ervan uitgaande dat a en b signed integers zijn met een bitlengte <= de lengte van het X register:
1) Laad in X de waarde van a en overschrijf de S bits IsNul en IsNegatief met de juiste waarde
2) Tel op bij X de waarde van b en overschrijf de S bits Overflow, IsNul en IsNegatief met de juiste waarde
3) Optioneel (C compilers genereren deze instructie niet): spring naar foutcode bij Overflow
4) Trek af van X de waarde van a en overschrijf de S bits Overflow, IsNul en IsNegatief met de juiste waarde
5) Optioneel (C compilers genereren deze instructie niet): spring naar foutcode bij Overflow
6) Spring over de volgende (conditionele) code heen als in S ofwel IsNul gezet is, ofwel IsNegatief niet gezet is
...
De if uit C vertaalt naar regel 6, en in die regel wordt het statusregister niet gewijzigd. Anders dan dat er wel of niet gesprongen wordt, is er dus geen sprake van "waar" of "niet waar".
De eerste 3 antwoorden zijn dus toch fout. De vraag was beter te beantwoorden geweest indien deze als volgt was gesteld:
A) De conditionele code na if wordt altijd uitgevoerd
B) De conditionele code na if wordt nooit uitgevoerd
C) De conditionele code na if wordt soms uitgevoerd
D) Snap ik niets van
if (if (1))
Ter illustratie, op (imaginair) CPU niveau gebeurt het volgende (X is een "gewoon" CPU register, en S is het CPU statusregister), ervan uitgaande dat a en b signed integers zijn met een bitlengte <= de lengte van het X register:
1) Laad in X de waarde van a en overschrijf de S bits IsNul en IsNegatief met de juiste waarde
2) Tel op bij X de waarde van b en overschrijf de S bits Overflow, IsNul en IsNegatief met de juiste waarde
3) Optioneel (C compilers genereren deze instructie niet): spring naar foutcode bij Overflow
4) Trek af van X de waarde van a en overschrijf de S bits Overflow, IsNul en IsNegatief met de juiste waarde
5) Optioneel (C compilers genereren deze instructie niet): spring naar foutcode bij Overflow
6) Spring over de volgende (conditionele) code heen als in S ofwel IsNul gezet is, ofwel IsNegatief niet gezet is
...
De if uit C vertaalt naar regel 6, en in die regel wordt het statusregister niet gewijzigd. Anders dan dat er wel of niet gesprongen wordt, is er dus geen sprake van "waar" of "niet waar".
Terzijde, omdat dit security.nl is: doordat in door de C compiler gegenereerde CPU instructies niet op overflows gecheckt wordt, leiden (in een 32bits C compiler waarbij een int 32bits is en gebruik gemaakt wordt van 32bits registers) de volgende waarden van a en b in (a + b < a) tot true:
a = 2^31 - 1 = 2147483648-1 = 2147483647 (hexadecimaal: 0x7FFFFFFF)
b = 2147483647
Reden: a + b = -2 (hexadecimaal: 0xFFFFFFFE) en dat is duidelijk een kleiner getal dan 2147483647.
Door het overslaan van overflow checks is gecompileerde C code heel snel. Probleem: het is de verantwoordelijkheid van de programmeur om op uitzonderingssituaties te checken als dat relevant is, bijv. omdat 1 of meer van die waarden "user-supplied" zijn. De kans dat programmeurs zoiets over het hoofd zien als extreme waarden in de normale (niet-aanvals) praktijk niet voorkomen, is levensgroot en ondertussen voldoende aangetoond.
Overigens hoeft de hierboven geschetste fout weer niet op te treden, namelijk als een optimizer de code (a + b < a) wijzigt in (b < 0) voordat er gecompileerd wordt.
a = 2^31 - 1 = 2147483648-1 = 2147483647 (hexadecimaal: 0x7FFFFFFF)
b = 2147483647
Reden: a + b = -2 (hexadecimaal: 0xFFFFFFFE) en dat is duidelijk een kleiner getal dan 2147483647.
Door het overslaan van overflow checks is gecompileerde C code heel snel. Probleem: het is de verantwoordelijkheid van de programmeur om op uitzonderingssituaties te checken als dat relevant is, bijv. omdat 1 of meer van die waarden "user-supplied" zijn. De kans dat programmeurs zoiets over het hoofd zien als extreme waarden in de normale (niet-aanvals) praktijk niet voorkomen, is levensgroot en ondertussen voldoende aangetoond.
Overigens hoeft de hierboven geschetste fout weer niet op te treden, namelijk als een optimizer de code (a + b < a) wijzigt in (b < 0) voordat er gecompileerd wordt.
De eerste 3 antwoorden zijn dus toch fout. De vraag was beter te beantwoorden geweest indien deze als volgt was gesteld:
A) De conditionele code na if wordt altijd uitgevoerd
B) De conditionele code na if wordt nooit uitgevoerd
C) De conditionele code na if wordt soms uitgevoerd
D) Snap ik niets van
17-08-2016, 12:49 door
johanw
Door Anoniem: Met lichte twijfel neig ik naar: "Snap ik niets van."
Je vergeet dat er bij stond dat het C code is. En C is een taal waarin veel mag, ook dingen die niet altijd even duidelijk voorkomen. Als je liever "beschermd" bent tegen dat soort dingen moet je niet in C programmeren, daar zijn andere talen voor.Ik snap niets van de vraag. Het is niet duidelijk wanneer het stukje code waar niet waar of soms waar is.
Een stukje c code is wat het is. Ik zou dus voor waar gaan.
Of wordt bedoeld wat de uitkomst van a + b < a is?
Een stukje c code is wat het is. Ik zou dus voor waar gaan.
Of wordt bedoeld wat de uitkomst van a + b < a is?
@ Erik van straten 11:59: bedankt voor de bevestiging! Dit neemt een groot deel van de laatste twijfels weg. :-)
@ johanw 12:49: "snap ik niets van"... :-?
Nog een paar wetenswaardigheden die ik vind pleiten voor de optie "snap ik niets van":
Standaard bestaan er in programmeertaal C geen waarden "TRUE" en "FALSE" (of "WAAR" en "NIET WAAR"),
tenzij je ze zelf van tevoren hebt gedefinieerd (bijv. #define TRUE 1 en #define FALSE 0).
Dit wordt echter vaak beschouwd als "bad practice", omdat het niet altijd op gaat.
In de volgende weblink wordt een voorbeeld gegeven waarbij het niet opgaat als je vooraf "TRUE" als "1" en "FALSE" als "0" hebt gedefinieerd:https://en.wikibooks.org/wiki/C_Programming/Control
(opmerking: in een programmeertaal als Pascal zijn "TRUE" en "FALSE" bijv. wél voorgedefinieerd)
Verder staat het je in C vrij om bijv. i.g.v. "negatieve logica" de waarde "0" als "TRUE" en "1" als "FALSE" te definiëren.
Of "0" als "ENABLED" en "1" als "DISABLED", etc. etc. etc. whatever you like.
Hooguit kan je zeggen dat het gebruikelijk is om in geval het de uitkomst van een conditie betreft
"1" te beschouwen als "WAAR" en "0" als "NIET WAAR".
Het IF-statement zélf controleert in de programmeertaal C de uitkomst van een conditie echter niet op "0" en "1",
maar controleert of het resultaat van de conditie "0" is, of "ongelijk aan 0".
"If 5 { }" is bijvoorbeeld valide en heeft dezelfde uitwerking als "If -3 { }" : ze voeren allebei net als "If 1 { }"
het programmablok tussen de accolades uit. Alleen "If 0 { }" slaat de programma flow tusen de accolades over.
Verder lijkt mij "If (a + b < a)" nogal omslachtig.
Waarom hier niet meteen "If b < 0" geprogrammeerd?...
Of zit er misschien toch nog ergens een addertje onder het gras dat niemand van ons nog heeft opgemerkt?
Goeroehoedjes
@ johanw 12:49: "snap ik niets van"... :-?
Nog een paar wetenswaardigheden die ik vind pleiten voor de optie "snap ik niets van":
Standaard bestaan er in programmeertaal C geen waarden "TRUE" en "FALSE" (of "WAAR" en "NIET WAAR"),
tenzij je ze zelf van tevoren hebt gedefinieerd (bijv. #define TRUE 1 en #define FALSE 0).
Dit wordt echter vaak beschouwd als "bad practice", omdat het niet altijd op gaat.
In de volgende weblink wordt een voorbeeld gegeven waarbij het niet opgaat als je vooraf "TRUE" als "1" en "FALSE" als "0" hebt gedefinieerd:https://en.wikibooks.org/wiki/C_Programming/Control
(opmerking: in een programmeertaal als Pascal zijn "TRUE" en "FALSE" bijv. wél voorgedefinieerd)
Verder staat het je in C vrij om bijv. i.g.v. "negatieve logica" de waarde "0" als "TRUE" en "1" als "FALSE" te definiëren.
Of "0" als "ENABLED" en "1" als "DISABLED", etc. etc. etc. whatever you like.
Hooguit kan je zeggen dat het gebruikelijk is om in geval het de uitkomst van een conditie betreft
"1" te beschouwen als "WAAR" en "0" als "NIET WAAR".
Het IF-statement zélf controleert in de programmeertaal C de uitkomst van een conditie echter niet op "0" en "1",
maar controleert of het resultaat van de conditie "0" is, of "ongelijk aan 0".
"If 5 { }" is bijvoorbeeld valide en heeft dezelfde uitwerking als "If -3 { }" : ze voeren allebei net als "If 1 { }"
het programmablok tussen de accolades uit. Alleen "If 0 { }" slaat de programma flow tusen de accolades over.
Verder lijkt mij "If (a + b < a)" nogal omslachtig.
Waarom hier niet meteen "If b < 0" geprogrammeerd?...
Of zit er misschien toch nog ergens een addertje onder het gras dat niemand van ons nog heeft opgemerkt?
Goeroehoedjes
17-08-2016, 21:02 door
MathFox
Verder lijkt mij "If (a + b < a)" nogal omslachtig.
Waarom hier niet meteen "If b < 0" geprogrammeerd?...
Of zit er misschien toch nog ergens een addertje onder het gras dat niemand van ons nog heeft opgemerkt?
Waarom hier niet meteen "If b < 0" geprogrammeerd?...
Of zit er misschien toch nog ergens een addertje onder het gras dat niemand van ons nog heeft opgemerkt?
neem 32 bits (signed) integer rekenkunde aan:
a=0x40000000; b=0x40000000;
a+b levert het bitpatroon 0x80000000 op, oftewel INT_MIN ;)
Natuurlijk niemand die het durft toe te geven, maar bij deze: Ik heb het even gegoogled!.. ;-)
Daarvoor wel de poll-vraag in factoren ontbonden, & dan volgt onderstaande string:
https://www.google.nl/search?hl=nl&source=hp&q=C+code+(X86)+%22if(a+%2B+b+%3C+a)%22&meta=&aq=f&oq=&gws_rd=ssl
N.B: Let eens op, de geduldigen onder ons, van wat de ongeveer overblijvende 159.000 resultaten zijn, na zoekpagina 1 met natuurlijk Security.nl als eerste bovenaan, & klik dan eens verder tot zoekpagina 6...
Daarvoor wel de poll-vraag in factoren ontbonden, & dan volgt onderstaande string:
https://www.google.nl/search?hl=nl&source=hp&q=C+code+(X86)+%22if(a+%2B+b+%3C+a)%22&meta=&aq=f&oq=&gws_rd=ssl
N.B: Let eens op, de geduldigen onder ons, van wat de ongeveer overblijvende 159.000 resultaten zijn, na zoekpagina 1 met natuurlijk Security.nl als eerste bovenaan, & klik dan eens verder tot zoekpagina 6...
Ah natuurlijk. Test tegen overflow-perikelen, en het probleem dat soms optimaliserende compilers deze test weer ongedaan maken. Is me duidelijk nu waarom die formule zo opgerekt was. Thanks.
Maar omdat niets is gegeven over a en b is het moeilijk te zeggen of dit hier wel speelt. De context ontbreekt.
En onder bepaalde omstandigheden kan dit verschijnsel ook bij andere processors dan X86 spelen.
Conclusie: een dumpvraag met onduidelijke of te weinig gegevens kun je alle kanten mee op. ;-)
Goeroehoedjes
Maar omdat niets is gegeven over a en b is het moeilijk te zeggen of dit hier wel speelt. De context ontbreekt.
En onder bepaalde omstandigheden kan dit verschijnsel ook bij andere processors dan X86 spelen.
Conclusie: een dumpvraag met onduidelijke of te weinig gegevens kun je alle kanten mee op. ;-)
Goeroehoedjes
@15:42 door Anoniem
Inderdaad de context ontbreekt, maar het is sowieso geen code die je moet schrijven, ongeacht optimalisatie door de compiler. Als je wilt testen op buffer overflows moet je of een secure integer library gebruiken die dat automatisch doet, of je volgt de security guidelines. Voor C is dat de CERT C Coding standard.
https://www.securecoding.cert.org/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow
Verder ben ik positief verrast door het verstand van zaken van het merendeel van de posters hierboven. Er is toch nog kennis van C aanwezig in ons land. Je moet het wel met een lantaarntje zoeken tegenwoordig.
Inderdaad de context ontbreekt, maar het is sowieso geen code die je moet schrijven, ongeacht optimalisatie door de compiler. Als je wilt testen op buffer overflows moet je of een secure integer library gebruiken die dat automatisch doet, of je volgt de security guidelines. Voor C is dat de CERT C Coding standard.
https://www.securecoding.cert.org/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow
Verder ben ik positief verrast door het verstand van zaken van het merendeel van de posters hierboven. Er is toch nog kennis van C aanwezig in ons land. Je moet het wel met een lantaarntje zoeken tegenwoordig.
19-08-2016, 00:55 door
johanw
Door Anoniem:Standaard bestaan er in programmeertaal C geen waarden "TRUE" en "FALSE" (of "WAAR" en "NIET WAAR"),
Dat is hier ook niet aan de orde. bij if (x) { y; } wordt y uitgevoerd als x <> 0 is; als x == 0 wordt het niet uitgevoerd. Veel C programmeurs testen pointervalues ook zo:char* c;
...
if (c) {
do_something;
}
in plaats van het omslachtiger:
if (c != NULL) {
do_something;
}
19-08-2016, 09:28 door
Erik van Straten
@Goeroehoedjes en @johanw: wat jullie vermoedelijk wel weten maar niet expliciet schrijven is dat er in C geen expliciete waarde bestaat voor "TRUE", maar wel voor "FALSE": dat is 0. Alle denkbare waarden anders dan 0 zijn TRUE.
Doe dus nooit:
want als expressie bijv. de waarde 42 oplevert, zal de conditionele code achter if niet worden uitgevoerd.
Doe in plaats daarvan (zoals johanw schreef):
of doe:
of desgewenst, als je duidelijker wilt maken dat je een true/false check doet:
Doe dus nooit:
#define TRUE 1
...
if (expressie == TRUE)
...
if (expressie == TRUE)
Doe in plaats daarvan (zoals johanw schreef):
if (expressie)
if (expressie != 0)
#define FALSE 0
...
if (expressie != FALSE)
...
if (expressie != FALSE)
@ 00:02 door anoniem: beschikken alle C-compilers dan over een secure integer library?
Nadeel kan ook zijn dat sommige optimalisaties niet meer plaatsvinden?
@ 00:55 door johan w: volgens mij is het wel aan de orde. Lees nog maar eens goed de 3 eerst keuzes op de oorspronkelijke vraag... (daarbij ben ik zo vrij om "TRUE" te vertalen naar "waar", en "FALSE" naar "niet waar")
@ 09:28 Erik van Straten: Zo is het, behalve dat ik het gebruik van "TRUE" en "FALSE" hekel zoals je al hebt gemerkt.
Het gaat er in programmeertaal C om of de uitkomst van een conditie gelijk is aan 0 of ongelijk aan 0,
waarbij de uitkomst 0 betekent: "de gestelde conditie voldoet niet",
en alle andere uitkomsten (dus ongelijk aan 0) betekenen: "de gestelde conditie voldoet".
In plaats van if(a + b < a) vond ik deze oplossing duidelijk en completer:
Goeroehoedjes
Nadeel kan ook zijn dat sommige optimalisaties niet meer plaatsvinden?
@ 00:55 door johan w: volgens mij is het wel aan de orde. Lees nog maar eens goed de 3 eerst keuzes op de oorspronkelijke vraag... (daarbij ben ik zo vrij om "TRUE" te vertalen naar "waar", en "FALSE" naar "niet waar")
@ 09:28 Erik van Straten: Zo is het, behalve dat ik het gebruik van "TRUE" en "FALSE" hekel zoals je al hebt gemerkt.
Het gaat er in programmeertaal C om of de uitkomst van een conditie gelijk is aan 0 of ongelijk aan 0,
waarbij de uitkomst 0 betekent: "de gestelde conditie voldoet niet",
en alle andere uitkomsten (dus ongelijk aan 0) betekenen: "de gestelde conditie voldoet".
In plaats van if(a + b < a) vond ik deze oplossing duidelijk en completer:
#include <limits.h>
int safe_add(int a, int b) {
if (a > 0 && b > INT_MAX - a) {
/* handle overflow */
} else if (a < 0 && b < INT_MIN - a) {
/* handle underflow */
}
return a + b;
}
( http://codereview.stackexchange.com/questions/37177/simpler-method-to-detect-int-overflow )int safe_add(int a, int b) {
if (a > 0 && b > INT_MAX - a) {
/* handle overflow */
} else if (a < 0 && b < INT_MIN - a) {
/* handle underflow */
}
return a + b;
}
Goeroehoedjes
20-08-2016, 21:36 door
Erik van Straten
@Goeroehoedjes: je kunt natuurlijk jezelf voor de gek houden door C te blijven gebruiken en het product veiliger te maken door overal constructies zoals "safe_add()" te gebruiken.
Mijn advies: kies dan een andere programmeertaal. Of gebruik C slechts op die plaatsen waar het voor bedoeld is: tijd-kritische code en zorg dat security risico's daarbuiten worden afgedekt.
Voorbeeld: als je heel vaak een tijdkritische functie met een pointer als parameter aanroept is het onverstandig om in die functie te checken of de pointer niet nul is (simpel, maar kost tijd) en/of die pointer naar een geldig geheugengebied wijst (lastig, hoe bepaal je dat) en/of die pointer naar een verwacht datatype of functie wijst (uuk uuk barbatruc).
De kunst is te zorgen voor een goede balans waarbij alle input wordt gevalideerd terwijl de performance zo hoog mogelijk is. De praktijk heeft bewezen dat maar heel weinig mensen over deze gave beschikken en voldoende tijd krijgen om hun vaardigheden in praktijk te brengen. Als je een copy/paste programmeur C laten schrijven is er 1 ding zeker.
Mijn advies: kies dan een andere programmeertaal. Of gebruik C slechts op die plaatsen waar het voor bedoeld is: tijd-kritische code en zorg dat security risico's daarbuiten worden afgedekt.
Voorbeeld: als je heel vaak een tijdkritische functie met een pointer als parameter aanroept is het onverstandig om in die functie te checken of de pointer niet nul is (simpel, maar kost tijd) en/of die pointer naar een geldig geheugengebied wijst (lastig, hoe bepaal je dat) en/of die pointer naar een verwacht datatype of functie wijst (uuk uuk barbatruc).
De kunst is te zorgen voor een goede balans waarbij alle input wordt gevalideerd terwijl de performance zo hoog mogelijk is. De praktijk heeft bewezen dat maar heel weinig mensen over deze gave beschikken en voldoende tijd krijgen om hun vaardigheden in praktijk te brengen. Als je een copy/paste programmeur C laten schrijven is er 1 ding zeker.
@ Erik van Straten 21:36:
Whatever... Soms is "goed gekopieerd" beter dan "slecht nagemaakt", of het kan je minstens op ideeën brengen.
Heb wel eens een idee van een beginner op internet gevonden en dat voor mijn toepassing verder geoptimaliseerd en geperfectioneerd.
De hele context bepaalt wat het beste is, en dan bedoel ik ook echt de hele context.
Daarbij inbegrepen: in de praktijk heeft men (helaas) vaak ook nog met te optimistische deadlines te maken om een perfect product af te kunnen leveren. Een gevolg van ons decadente commerciële systeem misschien?...
Goeroehoedjes
Whatever... Soms is "goed gekopieerd" beter dan "slecht nagemaakt", of het kan je minstens op ideeën brengen.
Heb wel eens een idee van een beginner op internet gevonden en dat voor mijn toepassing verder geoptimaliseerd en geperfectioneerd.
De hele context bepaalt wat het beste is, en dan bedoel ik ook echt de hele context.
Daarbij inbegrepen: in de praktijk heeft men (helaas) vaak ook nog met te optimistische deadlines te maken om een perfect product af te kunnen leveren. Een gevolg van ons decadente commerciële systeem misschien?...
Goeroehoedjes
Door Anoniem 22:24: wannneer int b=0, bewering is false
Inderdaad. Als b=0 wordt niet aan de conditie voldaan, want dan wordt de conditie achter "if" in feite: (a < a)Maar a kan natuurlijk nooit kleiner dan zichzelf zijn, dus de uitkomst van de conditie is 0. ("false" zo je wil)
Het eerstvolgende codeblok dat bijv. overflows verwerkt wordt dus overgeslagen, want er is geen sprake van een overflow.
Dit geldt ook voor bijv. a=1 en b=1. Want dan is (a + b) = 2, en de conditie (a + b < a) wordt dus: 2 < 1.
Maar 2 is niet kleiner dan 1. Dus weer wordt niet aan de conditie voldaan => codeblok voor overflows wordt overgeslagen.
Voor nog enkele voorbeeldwaarden zie het rijtje van 15-08-2016, 14:19 door Anoniem.
Je ziet dat als b < 0 er meestal aan de conditie wordt voldaan, en voor b >= 0 er meestal niet aan de conditie wordt voldaan. Maar er geldt dus een uitzondering voor overflow / underflow situaties.
Conclusie> je zult voorkennis moeten hebben van welke range van waarden a en b in de praktijk zouden kunnen aannemen om met if(a + b < c) op de juiste manier een overflow (of underflow) te kunnen vaststellen.
Anders gezegd: je moet meer van de context weten!
Juist daarom vond ik de op internet gevonden code genoemd in de post van 17:16 (die duidelijk is bestemd voor willekeurige integer variabelen) wel interessant.
Zonder voldoende voorkennis over a en b kun je bij if(a + b < a) géén uitspraak doen over de uitkomst van de conditie.
Maar voordat we ons daar blind op staren: we zijn allang op een zijspoor beland.Mijn antwoord op de oorspronkelijke vraag van 17-08-2016, 02:53 met een bevestiging van 17-08-2016, 11:59 door Erik van Straten, terwijl 16-08-2016, 12:38 door Anoniem hier ook al kort op had gewezen vind ik strikt genomen altijd nog het meest correcte antwoord op de oorspronkelijke vraag. Het was echter de vraag of de "quizmaster" van security.nl de vraag wel zo had bedoeld,
vandaar dit zijspoor. Maar als de bedoeling was een discussie uitlokken en kennis van C op het forum te testen, dan is dat aardig gelukt geloof ik. ;-)
Goeroehoedjes
b kan een negatief getal zijn, en dan is het dus niet waar. Het statement is dus soms waar. Toch?
13:31 door Anoniem: b kan een negatief getal zijn, en dan is het dus niet waar. Het statement is dus soms waar. Toch?
Als je het mij vraagt:Niet het if -statement is "soms waar", maar de conditionele expressie (a + b < a) die bij het if-statement hoort kan "soms waar" zijn. Er is verschil tussen if(a + b < a) en alleen maar (a + b < a)
1. "if(a + b < a) is soms waar" is onzin.
"if" is strikt genomen een control-statement waarmee je het programmaverloop kan wijzigen door middel van de conditionele expressie die er direct op volgt.
Je kan niet in termen van "waar" of "niet waar" spreken over het "if"-statement zélf.
Je kan wél in termen van "waar", "niet waar" of "soms waar" spreken over de conditionele expressie die bij het if statement hoort. Daarom zou ik kiezen voor "snap ik niets van".
2. (a + b < a) is hier de conditionele expressie die bij "if" hoort. Deze kan dus wél "soms waar" zijn.
Of de gegeven conditionele expressie (a + b < a) in een programma ook werkelijk "soms waar" is, hangt er nog maar helemaal van af welke waarden a en b op die plaats in het programma in de praktijk zouden kunnen aannemen,
waarbij ook rekening moet worden gehouden met de mogelijkheid van over/underflows. Daar kun je dus nog over twisten.
Echter iets als "if (a + b) < a)" is bij uitstek een controle of er eventueel een gevaarlijke overflow zou kunnen optreden als je a optelt bij b (a en b signed en positief, > 0 ), of anders had men beter kunnen programmeren: If(b < 0)
Maar okee: in alles overkoepelende algemeenheid zou je hier kunnen zeggen: (a + b < a) "is soms waar".
We hebben het dan puur over de conditionele expressie achter "if".
(opmerking: voor detectie van een underflow kun je om wille van programma-struktuur en snelheid beter een iets andere conditionele expressie gebruiken).
Wel kan het verwarrend zijn om te spreken over "waar" en "niet waar" als je negatieve logica gebruikt. (#define TRUE = 0 en #define FALSE = 1 in plaats van #define TRUE = 1 en #define FALSE = 0)
"TRUE" en "FALSE" zijn namelijk niet gedefineerd in C. Je kunt ze naar believen definiëren. Opletten dus bij negatieve logica. Of anders liever niet in termen van "true"(waar) en "false"(niet waar) spreken. Zie eerdere posts van mij.
Samengevat:
---------------------
Hoe if(a + b < a) "waar", "niet waar", of "soms waar", zou kunnen zijn "snap ik niets van".
Dat wil zeggen: ik snap het statement op zich wel, maar het is strikt genomen onzin dat het if -statement zélf "waar", "niet waar" of "soms waar" zou kunnen zijn.
Het is strikt genomen de conditionele expressie (a + b < a) die bij "if" hoort, die afhankelijk van de waarden die a en b op dat moment in het programma zouden kunnen aannemen wat bepaalt of deze expressie "waar", "niet waar" of "soms waar" is.
Ga je er vanuit dat de programmeur weet wat hij doet, dan bestaat er kennelijk risico op een gevaarlijke overflow. Dit kan gebeuren bij optellen van positieve signed integers. Meestal is de expressie dan "niet waar" , maar vanwege de kans op een bijzondere overflow is de expressie dan toch "soms waar".
Dit geldt dus voor de conditionele expressie in het if-statement. Niet voor het if-statement zelf.
Geniepig, maar zo is het volgens mij als je het nauw bekijkt.
Goeroehoedjes
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
