🚀 go-pugleaf

Dr.Ruud wrote:
> Wat Aquila schreef, bleek het
> begin  van iets moois; kijk zelf maar:
> 
> 
>>In een stukje logging code gebruik ik volgend commando:
>>sprintf(buffer, "%s %.9f _%i_ --- %i %i ------- [%i:%i] (%s) %s",
>>event, timeval2double(now), id, pid, length, nid, dst_i, message,
>>additional)
> 
> 

>>[...]
>>Kan %i een maximum lengte opleggen zonder daarvoor extra nullen te
>>printen? In beide gevallen mag er afgekapt worden, ik wil gewoon
>>beveiligingsfouten vermijden.
> 
> 
> Nee, maar je zou wel kunnen casten, bijvoorbeeld
>   (int32) id
> want op die manier weet je dat %i maximaal 10 tekens kan opleveren,
> zelfs als later 'id' een 64-bits integer zou worden.
> 

Is wel erg paranoide, IMO, om rekening te houden met andere sizes.
En onsmakelijk om daar een cast voor te gebruiken.
Een int is een int. een "%d" of "%i" verwijst naar een int in de 
arglist, ongeacht zijn/haar sizeof.

Het eenvoudigst, IMHO is om de buffer gewoon groot genoeg te maken:
een geformatteerde 32 bits int vergt 10 char +1 voor het teken.
<limits.h> vermeldt:

#  if __WORDSIZE == 64
#   define LONG_MAX     9223372036854775807L
#  else
...
Dat is 19 pos + teken voor een 64bits int, als ik goed geteld hebt.

Samenvattend:
* (over)Alloceren op de stack ("auto") kost vrijwel niks. (je moet het
    natuurlijk niet in ieder functie doen, en dan duizenden lagen diep.
* voor strings is "%20s" nodig om maximaal 20 chars af te beelden.
* voor ints (en floats, in mindere mate) ligt het maximaal benodigde
   min-of-meer vast.

* Als levensverzekering zijn vsprintf(), en vsnprintf() uiterst
   bruikbaar. Problematisch is wel dat ze nog steeds niet op alle
   platformen beschikbaar zijn. (meestal zijn ze er wel, ergens diep
   in het hart van de library, maar alleen niet publiek zichtbaar)

HTH,
AvK