sprintf

[Jaroslav Buchta]

Ja to resim tak, ze si naprogramuju moznost zobrazit uroven max. 
pouziteho zasobniku (pro jednotliva vlakna u MT, treba FreeRTOS to umi 
hlidat), max adresu alokovanou na halde a subjektivne posoudim, kdy je 
to jeste OK. Je fakt, ze radsi nechavam velke rezervy, kdyz se to 
priblizi pod 10 kB tak zacnu optimalizovat.
Dne 03.11.2016 v 18:05 Pavel Hudecek napsal(a):
> Takže pokud to dobře chápu, kdybych si psal vlastního správce paměti, 
> tak jí nesmí jen tak celou přidělovat, musí si ji alokovat přes 
> malloc, ale ne celou, aby zbyl kousek na režiji sprintf, případně 
> jiných funkcí.
>
> PH
>
> -----Původní zpráva----- From: Jiří Nesvačil
> Funkce typu printf potrebuji buffer na formatovaci hodnoty napriklad " 
> cislo je %ld". Uvnitr je to vetsinou implementovano, ze se to %ld 
> propere pres nejaky buffer a universalni funkci na prevod na cislo. 
> Ten buffer je ta zajimavost.
>
>
> Dne 3. 11. 2016 v 17:10 Pavel Hudecek napsal(a):
>> včera jsem se tu dozvěděl o "nebezpečnosti" sprintf. Abych si to 
>> ujasnil, tak doplňující otázky:
>>
>> 1. Ta nebezpečnost spočívá jen v možnosti přetečení výsledku mimo 
>> buffer, pokud byla jeho velikost programátorem podceněna, či 
>> formátovací string nebyl ukončen? Tzn. nejedná se o žádnou speciální 
>> nebezpečnost této fn a je prostě třeba si dávat stejný pozor, jako 
>> při jakékoli jiné práci s poli?
>>
>> 2. Nebo je nebezpečnost o něco větší a hrozí, že se ta fn někdy nějak 
>> zblázní a vyprodukuje nesmyslně více dat? Tzn. řešením je jedině 
>> nahrazení verzí s N?
>>
>> 3. Nebo je nebezpečná nějak jinak a ani N to nezachrání? Pokud ano, 
>> týká se to i printf?
>>
>> 4. Co je za problém s sprintf a thready? Týká se to i printf (kromě 
>> očekávatelného problému, že by se mohl pohádat o výstupní zařízení s 
>> jiným threadem)? 
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list