Dotaz: std::ofstream::open a string s nulovými znaky

[Franta]

Mám následující kód, kde chci vytvořit soubor s názvem, ve kterém je nulový byte:

#include <fstream>

int main()
{
    std::string filename("myfilename\0.txt", 15); // embedded null character
    std::ofstream myfile(filename);
    myfile.close();
}

Je mi známo, že v linuxu název souboru nemůže obsahovat nulový byte. Otázkou je, proč operace neselže, ale vytvoří se soubor se špatným názvem "myfilename"? std::ofstream od C++11 má parametr std::string a std::string může obsahovat nulové znaky, proč se s tím nepočítá a operace, která by měla selhat neselže a ještě má potenciál zničit soubor s jiným názvem? V c++17 má být std::filesystem, budou jeho operace taky takhle "fungovat" s řetězci obsahujícími nulový byte a vytvářet/mazat/otevírat úplně jiné soubory a adresáře? Existuje k těm fcím néjaká dokumentace, kde se říká, že pokud předám řetězec, co obsahuje nulový byte, bude to nedefinované chování?

---

---

Odpovědi

[Bedňa]

Pretože k Linuxu sa ten nulový reťazec ani nedotane? Nebude mať niečo s prekladačom?

[Tommy Angelo]

našiel som podobne ladenú otázku na so.

Operácia vytvárania súboru nemá prečo zlyhať, lebo v parametri mu bol dodaný názov súboru (ako std::string), ktorý bol vytvorený správne bez ohľadu na to, či bol vytvorený s ukončením c-stringu, alebo bez.

Viac v referencií k std::string.

[Franta]

Operácia vytvárania súboru nemá prečo zlyhať, lebo v parametri mu bol dodaný názov súboru (ako std::string), ktorý bol vytvorený správne bez ohľadu na to, či bol vytvorený s ukončením c-stringu, alebo bez.

Právě že ne. Já chtěl vytvořit soubor "myfilename\0.txt", jenže místo toho, aby to selhalo, tak mi to vytvořilo soubor "myfilename". Nikde se mi nedaří najít, že takový název funkci předat nemůžu, jinak dojde k UB, proto předpokládám, že dojde k situaci, že vytvoření souboru selže (protože systém takový název souboru nepodporuje), nikoliv, že bude tiše vytvořen úplně jiný soubor a tvářit se, že je vše ok.

[Dušan Kreheľ]

Vytvoriš jedine (na unix-like), že použiješ bínarnu úpravu suborového systému, a aj to Ti môže byť nanič na praktické použitie (jedine, že realizuješ vlastny FS s vlastným API). Nakoľko dnes je C viac menej jediným rozhraním pre komunikáciu s OS, tak v C-čkovskej (i v assamblery) je definícia reťazca ako súvisle pole znakov (adresy znakov v pamäte musia rásť) ukončené bytom 0. (Znak pre ISO-*/UTF-8 ma jeden bajt. Pre UTF-16 2-8 bajtov.). I keď použíješ ukončovací znak v Tvojej definicií kodu, tak sa bude pri spracovaní spracúvavať len po prvý výskyť bajtu 0 v pamäte, a nebudú sa riešiť dalšie xy nulových bajtov za tým...

[Franta]

Ano, tomu všemu rozumím a chápu, C funkce i Linuxový syscall požaduje "Céčkový" řetězec, kde nula znamená konec řetězce. Ale o tom není můj dotaz. To C++ API je definované tak, že má parametr std::string, tedy by mělo očekávat (pokud někde v dokumentaci či standardu není dáno žádné omezení na vstupní parametr), že mu můžu předat vše, co mi dovolí std::string, tedy včetně nulových znaků uprostřed řetězce. Nemyslím si, že by prostě mělo vzít pointer na první znak a předat ho systému a tvářit se, jako že je všechno vpořádku, když není. Podle mě by prostě otevření souboru mělo selhat a být nastaven příslušný flag streamu, popř. vyhozena výjimka, pokud jsou pro stream zapnuty. To se však neděje. Hledám tedy nějakou část standardu, nebo dokumentaci, nebo prostě něco, kde je napsáno něco jako že dochází k UB, pokud jsou v řetězci obsaženy nulové znaky, nebo pokud nic takového neexistuje, tak jestli se jedná o chybu v implementaci standardní knihovny.

[Dušan Kreheľ]

Nezlíha, lebo na to potrebuje try/catch alebo overovanie chyby. (Aj s tým nevýhody výnimku.

Oficiálne znenie štandartu nie je prístupné.

Zrejme kvôli univerzálnosti, zrejme povoľuje a spolieha sa na identifikáciu OS, či je chyba alebo nie. Lebo niekde môže byť a niekde nie. Ak by to prepisovalo cez (char *name, int lenght) cez API OS, tak by chyba nebola. Sťažuj sa Tvorcom prekladačom. Alebo, že to štandard neošetril, keď z char dovolil prejsť na string.

[Michal Kubeček]

Tohle vůbec není o jménech souborů a omezeních operačního systému. Máte tam std::string inicializovaný pomocí string literal a ten je null terminated. Např.

#include <iostream>
#include <string>

int main()
{
        std::string s("abc\0def");

        std::cout << s << std::endl;

        return 0;
}

To vám taky vypíše jen "abc".

[MadCatX]

Jenže tazatel ten string inicializuje takto:

std::string s("myfilename\0.txt", 15);

[Michal Kubeček]

Pravda. Na věci to ale stejně nic nemění, protože třída std::basic_fstream dlouhou dobu měla pouze konstruktor s prvním parametrem typu "const char*" a i když C++11 přidává i konstruktor s prvním parametrem typu "const std::string&", je u něj napsáno

Effects: the same as basic_fstream(s.c_str(), mode);

Takže se tak jako tak cokoli za prvním nulovým znakem musí ignorovat. A i kdyby ne tady, pak u std::basic_filebuf je výslovně uvedeno, že jméno souboru je null terminated byte string.

[Tommy Angelo]

u std::basic_filebuf je výslovně uvedeno, že jméno souboru je null terminated byte string.

u metody open()

[Franta]

Dobře, to byl právě účel mého dotazu, dostat nějakou takovou konkrétní odpověď. Děkuji. A jak to bude s novým std::filesystem API, je tam něco takového taky, nebo tam se bude předpokládat, že tam nula být může a bude to vracet např. chybu?

[Michal Kubeček]

Nevím - a i kdyby snad ano, nevidím v tom žádný praktický smysl.

[Franta]

Tak aby jeden věděl, jestli je třeba ošetřovat uživatelův vstup, aby program nedělal kraviny a nepřepisoval jiná data, než má.

[Bedňa]

Užívateľský vstup treba ošetriť vždy, to vieš keď sa niekto bude voľať

Robert'); DROP TABLE students;--

[Dušan Kreheľ]

Je rozdiel, ci použiješ, keď je definované nejak takto:

typedef struct {
  char *c_string;
  int c_lenght;
} String;

String string;

toto

printf(string.c_string);

alebo

frite(string.c_string, string.c_lenght, 1, stdout);

Ináč, aj tak sa do kernelu sa neprenáša dĺžka názvu súboru. To by si musel vytvoriť nové systémové volanie.

fs/open.c (riadok 1066)
príklad použitia systémového volania

[Franta]

Jak říká MadCatX, v proměnné filename opravdu bude nulový byte před příponou.

[MadCatX]

Existuje k těm fcím néjaká dokumentace, kde se říká, že pokud předám řetězec, co obsahuje nulový byte, bude to nedefinované chování?

Existuje, přímo dokumentace konstruktoru std::ofstream říká:

filename
    A string representing the name of the file to be opened.
    Specifics about its format and validity depend on the library implementation and running environment.

[Franta]

Dobře, tak řekněme, že mám špatný formát a jméno není validní. Proč tedy nedojde k chybě a je vytvořen soubor s nechtěným názvem?

[Bedňa]

Ukončil si reťazec, to je všetko, od koho chceš chybu?

[MadCatX]

Obsah řetězce ale přece lze interpretovat jako validní název. Kdybych udělal např. klasické céčkové

const char filename[] = { 'm', 'y', 'd', 'a', 't', 'a', 'f', 'i', 'l', 'e', '\0', '.', 't', 'x', 't' };
FILE *f = fopen(filename, "w");

dostanu minimálně na Linuxu úplně stejný výsledek jako s std::string a std::ofstream v C++.

[Franta]

Tady to chápu, tam se nepředává délka (která je součástí std::string), takže se nějak musí určit konec, tou nulou. Ale std::string má velikost, tak může obsahovat nuly. Odpověď pana Kubečka asi postačí.

[MadCatX]

Problém je v tom, že přímo std::string i s informací o skutečné délce pole znaků se rozhraní příslušného OS nedá předat - aspoň Linuxu určitě ne. Kdybychom měli v podobném duchu pokračovat, dalo by se např. argumentovat, že i

std::ofstream s1("FILE.DAT");
s1 << "Hello\n";
s1.close();

std::ofstream s2("file.dat");
s2 << "bitches\n";
s2.close()

má nedefinované chování, protože zda se vytvoří jeden či dva soubory záleží minimálně na použitém OS a souborovém systému. Tyto rozdíly v chování různých platforem a konfigurací je něco, co C++ová STL rozhodně nemůže řešit za programátora. Rozhodne-li se někdo páchat kovbojoviny jako cpát terminátory doprostřed řetězců, je IMHO jen jeho odpovědnost zkontrolovat si, jestli se tím někde nemůže střelit do nohy...

[fi]

Nerika std::ofstream ze interpretace filename zavisi na filesystemu? Ruzne filesystemy a platformy maji ruzna specifika, napr. ignorovani nasobnych '/', ignorovani velikosti pismen, ukoncovani jmen '\0' atd.