[M.....3]

Mircy, zgłupiałem całkowicie. Ten program https://pastebin.com/ns0wnLxr raz zwraca, że nieistniejący katalog istnieje, a raz że nie. Póki co zaobserwowałem to na dwóch maszynach wyposażonych w system debian8 i kompilator gcc w wersji gcc (Debian 4.9.2-10) 4.9.2
Dzieje się to nie tylko z jednym katalogiem. Inny mój program losowo identyfikuje typ danego pliku na komputerze, czasem nawet identyfikując go jako żaden z możliwych, to znaczy ani jako folder, ani plik zwykły, nie socket co jest przecież niemożliwe.

Nie wiem o co tu chodzi, więc mam prośbę do użytkowników #debian czy też osób posiadających wersję kompilatora gcc (Debian 4.9.2-10) 4.9.2
1. Pobrać program https://pastebin.com/ns0wnLxr
2. Skompilować gcc wtf.c -o wtf
3. Odpalić kilkanaście razy: for i in {1..100}; do ./wtf; done
4. Sprawdzić czy odpowiedź wypisana na ekran jest za każdym razem taka sama.

Ja sprawdzałem na dwóch maszynach z tą wersją kompilatora i wynik jest raz jedne raz drugi. Co przecież jest niemożliwe. Na dwóch innych wersjach kompilatora działa prawidłowo.

#linux #jezykc #wtf

[kawazaki]

@Matt23: ale S_ISDIR zwraca Ci czy to jest katalog czy plik.

https://www.gnu.org/software/libc/manual/html_node/Testing-File-Type.html

This macro returns non-zero if the file is a directory.

raz zwraca, że nieistniejący katalog istnieje, a raz

[grlux]

@Matt23: faktycznie na debian gcc 4.9.2 program daje losowe wyniki. Ale jak zmienię zmienną path na istniejący plik / katalog, to wyniki są prawidłowe

[vytah]

@Matt23: jeśli plik nie istnieje, to stat/fstat/lstat nie zapisuje nic do struktury i zwraca błąd ENOENT, który tutaj pięknie ignorujesz

[M.....3]

@kawazaki: @grlux: @vytah: No dobra, powoli zaczynam rozumieć co się dzieje. Podany przykład jest jedynie wstępem do większego problemu z którym się mierzę.

Dobrze rozumiem, że slash "/" na końcu ścieżki nie jest opcjonalny? To znaczy, odwołując się do /bin/bash/ program nie jest w stanie zidentyfikować pliku, ale po usunięciu slasha /bin/bash już jest.
Z katalogami to nie działa. Oba /bin i /bin/ są prawidłowo rozpoznawane.

[kawazaki]

@Matt23: różne aplikacje linuxowe różnie traktują slasha na końcu. Ale też nie znalazłem potwierdzenia na jakim poziomie to przeszkadza. Podejrzewam, że jednak na poziomie systemu patrząc na komentarz:

Working on some old versions of SunOS, I developed the habit of appending /., because the system actually ignored a trailing / on a file name; for example, /etc/motd/ would refer to the file rather than being an error. Later versions of