🚀 go-pugleaf

Dr.Ruud wrote:
> Wat moi schreef, bleek het
> begin  van iets moois; kijk zelf maar:
> 
>>Dr.Ruud:
>>
>
>>>Het had ons allemaal heel wat exploits kunnen schelen.
> 
> 
>>Exploits wegens 32->64 bits "migratie" ?
> 
> 
> Er waren ooit al andere problemen, zoals
>   printf("value of 32768 is %d\n", 32768);
> 

Je bedoelt: op een platform waar een int 16 bits is ?

(trouwens ook hier bewijst casten naar int zijn zinloosheid)
BTW speelt nog wat anders mee: "silent promotion to int" van
functieargumenten.



> OK, maar OP vroeg om een oplossing bij %d, en er mocht afgekapt worden.
> 
Ja, maar we zijn nu toch al bijna off-topic.

> Er zijn, zoals gemeld, genoeg manieren om de buffer lang genoeg te laten
> zijn, dus dan heb je die cast helemaal niet nodig, en hoef/mag/moet je
> 'm dus ook niet gebruiken.
> 
> En printf() is meer iets van de vorige eeuw. Die slechte relatie
> tussen wat er op de stack wordt gezet (de argumenten) en wat er
> weer wordt afgehaald (afhankelijk van de tekst die in de format-
> string staat) gaat tegen alle elegantie in. Zelfs late-binding
> is minder onfris.
> 

Het is idd een vunzige functie. (en hij wordt er niet mooier op)
Heel lastig, hoe de mapping van binaire naar humaan-leesbare 
reprensentatie in een formaat-string wordt samengeperst, en tussen de 
bedrijven door ook nog even assumpties over types en sizes worden 
gedaan. Aan de andere kant is het weer prakties om alles in een
compacte representatie (de formatstring) te hebben. Jammer alleen, dat 
die toch wel een beetje samenhangt met de de functie-argumenten.
Als het goed is, dan. Trouwens: de hele varargs construktie is, in al 
zijn lelijkheid, uiterst gewenst.

Dat fprintf() cs van de vorige eeuw zijn, zou ik niet willen zeggen.
(kwa ontstaansdatum wel, uiteraard ...)
De functionaliteit blijft toch nodig; bij een grondige redesign zouden 
er ook weer keuzes gemaakt worden. Die later weer verkeerd kunnen uitpakken.

AvK