Vlákno názorů k článku
Curl zakazuje ve svém kódu funkci strcpy(), použije vlastní bezpečnější náhradu od Ink - A zde, přátelé, vidíme v praxi, proč už...

A zde, přátelé, vidíme v praxi, proč už v C takové věci nepsat...

…pobavilo, ale vážně.

Spíš proč nepoužívat některé funkce ze standardní knihovny C.

Nicméně někteří lidé, co píší v C, si už napsali vlastní knihovny, kde je tohle a mnoho dalších věcí vyřešených lépe.

Podívejte se třeba jak píše v C Ryan Fleury případně Eskil Steenberg. Ten první je mi bližší, ale oba mají blogy nebo přednášky, kde ukazují, jak v C psát funkční a efektivní kód.

Takže standardní knihovna céčka vlastně stačí tak k tomu, aby si každý programátor/projekt implementoval vlastní nadstandardní knihovnu. Rozumím té motivaci - programátor ví nejlíp, jakou implementaci pro ten který problém zvolit a jaké okrajové podmínky musí dodržet... ale.

Umět s céčkem ale znamená umět nejenom syntax, ale i všechny nadsyntaktické možnosti a pasti preprocesoru; schopnosti standardní knihovny a také její neschopnosti - protože jazyk a standardní knihovna mají dost omezené schopnosti bezpečného selhání a konkrétní implementace mají možnost udělat eval(UB) místo panic(UB); a k tomu veškerý tooling a konvence toho kterého projektu - nadstandardní knihovnou počínaje a specifickými instrukcemi pro formátování kódu konče.

To není zrovna dobrá vizitka - i přes všechny výhody, které přístup "každý sám za sebe" přináší stran stability, nezávislosti a údržby.

naštěstí to neplatí pro c++. A pokud si v C++ píše vlastní std::string, tak nejspíš neumí C++ ale C a C++ prolistoval při jízdě rychlíkem

Navyše sa niekedy vtipne hovorí, že každý pokročilý programátor v C má napísané svoje vlastné C++. Zatiaľ čo programátori v C++ používajú štandardné C++. Ale to len tak medzi rečou.

Dokážu si představit pár situací, kdy by dávalo smysl psát vlastní std::string. Ale řekl bych, že se do nich v tomhle životě nedostanu :)

Ve starších projektech např. ~20 let je vlastní std:.string zcela běžný a pochopitelný.

No já jsem právě viděl tu diskusi pod původním blog postem a tam navrhovali používat nějakou funkci ze specifikace C11. Co je teda teď best practice ve standardní knihovně C (používají prý C98)?

ISO C11 (Annex K) podporuje vlastně jen Microsoft.
BSD/macOS má vlastní strlcpy().
Jinak: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm

Dík za odkaz a odpověď. Znamená to teda ale, že obecné řešení mezi platformami neexistuje?

Pořád jsou to jen pojídači koláčů. Skutečný programátor nepíše v C, píše ve FORTRANu a používá GOTO.

Treba MS v C mam tyhle funkce s osetrenim delky bufferu v ramci standardni knihovny snad uz 20 let...

portuj takový kód na linux/z linuxu

No nevim, tenhle hate kdyz tu mame https://linux.die.net/man/3/strlcpy ale proc si nekopnout...

Protože strlcpy se sice na rozdíl od dá použít bezpečně, ale furt to není nic jistého. Vždyť i vámi odkazovaný manuál zmiňuje, že se jeho autoři na první pokus sekli.
A tohle je jenom kopie. Nic specificky stringového. Jen něco, co umí vlastně všechny normální datové typy. A navrch je někde strlcpy a jinde zas strcpy_s.

V normálním jazyce by strlcpy a spol byla ostuda a dobrý důvod pro hate. Ale tohle je C.