Re: FreeBSD aflusning

2012/10/4 Erik Cederstrand <none_at_erik--cederstrand.dk.lh.bsd-dk.dk>:

> Jeg tager det som en lejlighed til at bidrage lidt til FreeBSD og lære noget nyt hver dag. Her er et eksempel: http://scan.freebsd.your.org/freebsd-head/usr.sbin.mtree/2012-09-30-amd64/report-KuXNHJ.html#EndPath

Ideen med koden er oplagt at Linie 177 parser keywordet i
konfigurationsfilen. Hvis dette keyword kræver en værdi, så bliver
value sat gennem en reference. Et fint eksempel på hvorfor C ikke er
moderne og ikke bør bruges mere: Man skal hoppe gennem
pass-by-reference for at sætte flere værdier.

Om value er sat afhænger af keywordet. Det er ikke sikkert at clang
kan se det umiddelbart, men det afhænger af hvad parsekey gør.

> I linje 178 tror jeg, at 'val = strtok(NULL, " \t\n"' kun bliver kørt hvis "value" er sand. Derfor får "val" ikke altid en værdi og kan faktisk forblive en null pointer.

Dette er korrekt. Du har A && B og siden operatoren && er
short-circuiting så vil B kun blive udført hvis A går igennem.

> Mht en rettelse, så kunne man bytte om på de to statements, så 'val' altid får en værdi. Desuden tror jeg, at parenteserne er sat forkert. "(a && B) == NULL" giver ikke mening i mit hoved:

Det tror jeg ikke er en god ide. Ideen er netop at checke 'value'
først og så skippe den anden halvdel hvis value ikke er sat. Hvis du
bytter rundt på dem, så udfører du altid strtok og strtok bliver kaldt
med et førsteargument som er NULL og dermed fortsætter den med at
parse i sin string. Sideeffekten er derfor at du kommer til at skippe
dele af dit parse.

Bemærk også at i C, der binder == stærkere end && så A && B == C
binder som A && (B == C). Hvis vi misbruger et andet parentessæt som
eksempelvis visse Scheme og Clojure tillader:

value && (val = strtok(NULL, " \t\n")) == NULL

binder som

value && [ (val = strtok(NULL, " \t\n") ) == NULL ]

Hvilket ser rigtigt nok ud i min bog.

> Hvad mener I? Jeg kunne poste en opgave til listen hver dag, og så kan vi forsøge at finde løsningen sammen.

Det kræver formentlig noget omskrivning for at gøre clang glad. Et
hurtigt hack kunne være at checke for NULL i F_FLAGS case'en på 'val'
og så panic'e programmet hvis det sker fordi det er en assertion. Det
vil formentlig hinte clang om at den corner-case er håndteret.

Alternativt, så skal man finde ud af hvad clang synes om parsekey(...,
&value). Min umiddelbare intuition er at det er her clang ikke er i
stand til at regne ud hvad der sker, så den skyder på at value er
false, men type er F_FLAGS. Men jeg vædder med at slår du op hvad
parse-key gør, så kan den kombination ikke forekomme :)

-- 
J.