Skapade en htoi()

[lillahuset]

Man kan ALDRIG räkna med att variabler hamnar på vissa ställen.

[X-IL]

Visst är det så lillahuset, men det var ju inte riktigt det som någon gjorde heller.

[lillahuset]

Nej det har du rätt i...

[sodjan]

> Om man konverterar ETT tecken ska det bli 0

Varför det? Ett värde uttryckt i HEX kan ju vara både
ett tecken (som i detta fall) eller tre tecken eller vilket
antal tecken som helst. "0xF" är detsamma som "0x0F" (15).

Och "0x1FD" är samma värde som "0x01FD" (509).

Men det kanske förutsattes att det alltid var jämna bytes
som var kodade i HEX i just Icecap's rutin...

[johano]

Buggen var att koden inte respekterade den inskickade buffertlängden (argumentet Chars)
när den kollade mot eventuell "0x" i början av strängen (som då skulle hoppas över) och då kunde
den råka läsa utanför bufferten.

Men, nog om det: funktionen är bra och välbehövlig och behöver inte länka in nåt från C-runtime e.dyl.

/j

[Wedge]

"Varför det?"
Därför att när du skickar med 1 som antalsargument till funktionen betyder det inte tre.
"0" är inte samma sak som "0xF".

Att indexera utanför en sträng har aldrig varit rätt, det blir inte rätt den här gången heller. Om nu inte "specen" säger att koden SKA göra så. Visa mig.
Johanos kod visar att Icecaps kod indexerar utanför sina befogenheter.
Du mörkar för det genom att sätta ihop de felaktig lästa delarna till en garanterat sammanhängande och korrekt sträng, men vägrar se att antalsangivelsen inte respekteras.

Buggen kvarstår. Den "rättade" koden gör precis samma fel och använder sig av data som pekas ut "två bytes framåt" även om antalsbegränsningen eventuellt anger annat.
Rättelsen verkar vara att loopen bryter om man stöter på nollbyten i en nullterminerad sträng. Vilket är bra, men det var inte det som felet handlade om.

[sodjan]

Nej visst har den flera av de vanliga "C-felen".
Men OK, jag är helt med på att Icecaps rutin hade (har?) en del fel.
Men hur var johanos testrutin tänkt att fungera?

[johano]

Den skickade in en pekare till ett tecken '0' (a) och buffertlängden 1 (Chars).

Förväntat var att funktionen skulle returnera 0.

Att det sedan "råkade" ligga andra tecken direkt efter (b och c) belyste bara problemet att
funktionen kör över buffertlängdargumentet och läser in dessa tecken också, men har ingen
egentlig betydelse för buggen som sådan.

Att det "fungerade" beror ju hur kompilatorn lägger ut variablerna i minnet, det kunde ju lika gärna
"kraschat" också, vilket förmodligen varit troligare under riktiga förhållanden.

/j

[Icecap]

Det föreligger nog ett par missuppfattningar.

Antal tecken som ska omvandlas ("Chars") är inte ett uttryck för HEX-strängens längd men om att jag vill omvandla bara ett visst antal av dom för att det är vad jag vill ha.

Exempel:
Strängen ("Datas") är "AF438977B"
Jag vill ha värdet på de två första tecken, alltså 1 byte, alltså ges parametern som 2.

Resultat = htolln(Datas, 2); // Läser och omvandlar "AF"

Som all annan programmering finns det villkor att uppfylla och att peka på en byte som inte är en del av en sträng är dels inte avkänningsbart i C om man inte kollar varningerna som kompilern ger och dels dömd att misslyckats, det är ju inte en sådan parameter man ska ge.

Sedan kan rutinen inte stega förbi EOL i strängen, inte ens när den plockar bort inledande "0x".

Och att den stegar förbi EOL i omvandlingen (t.ex. om strängen bara består av "0x") sker inte heller, inte ens innan modifieringen.

[Mr Andersson]

Jag tror någonting har fallit bort av misstag vid redigeringen. Du flyttar aldrig datapekaren efter en loopiteration så med Chars == 0 får man en oändlig loop, större än 0 och man får (Chars) antal av första tecknet.

Två synpunkter; Data bör vara const char* då fungerar koden med c++ literals också, och du tappar ingen funktion för du ändrar ju ingenting i strängen. Och det andra är väl mest en smaksak, men du bör nog kolla om Data == NULL innan deref.

[Icecap]

Mr Andersson: done. Håller helt med.