Dziękuję za obszerną wypowiedź, daje mi dużo do myślenia i dużo zapału do jeszcze cięższej pracy.
Gooood, gooood... [zacieranie rąk z szyderczym uśmieszkiem na ustach]
Używałem exit() zamiast return, tak mnie nauczyły przykłady z książki (i tu się pewnie kłania to, że złą książkę czytam, bo nie jest nią "Język ANSI C").
Tę funkcję stosuje się raczej do zakończenia działania programu z funkcji innej niż main
. W pozostałym przypadku jej użycie jest uznawane za nieeleganckie. To tak, jakbyś wyskakiwał z wody zamiast z niej wyjść na brzeg... like a sir.
getch() ktoś raz polecał zamiast getchar() i użyłem jej po to, aby ktoś przeczytał komunikat o błędzie zanim zniknie,
Takie "wstrzymywanie terminala" robi się w przypadku stosowania IDE, które np. prezentuje wynik działania w oknie zamykanym automatycznie po zakończeniu działania programu. Teraz chyba tylko Dev ma taki "ficzer". Normalnie nie powinno się czegoś takiego robić, szczególnie w programach nieinteraktywnych.
chociaż te komunikaty nie są kompletne jak mówiłeś. Nie pisałem tego programiku pod innych userów tylko pod siebie, proszę o wyrozumiałość.
Po pierwsze, wyrabiaj sobie nawyki. Po drugie, Ty także jesteś użytkownikiem tego programu. Jeśli wystąpiłby ten błąd, to Ty musiałbyś kombinować którego pliku nie udało się otworzyć i dlaczego.
Użyłem trybu binarnego w Windowsie, nie w Linuxie co miało znaczenie gdyż chciałem przekopiować plik z wartościami binarnymi.
No widzisz, napisałeś że masz tę samą sytuację co autor wątku, ale nie poinformowałeś nas, że dotyczy ona innego systemu operacyjnego. W przypadku Windows użycie flagi "b" jest prawidłowe. Jednakże, robi ona co innego niż myślisz. Tryb tekstowy nie oznacza, że będziesz czytał tekst, a tryb binarny - liczby. Odczyt i zapis jest tego samego - bajtów. Nie ma znaczenia czy w danych są wartości z "dolnej" tablicy ASCII czy z całej. Tryb tekstowy pod Windows zamienia automatycznie znaki LF (line feed, 0x0A, '\n') na CR LF (carriage return i line feed, 0x0D 0x0A, "\r\n"), gdyż w tym systemie nową linię oznacza się kombinacją dwóch znaków. Tryb binarny takiej translacji przy odczycie/zapisie nie robi.
Funkcji stat() nie znałem do tej pory i wyszukałem koniec pliku na swój sposób.
Szalona inwencja twórcza jest i tak lepsza od braku inwencji jakiejkolwiek. Próbowałeś, zostałeś poprawiony, wzbogaciłeś się o nową wiedzę. Ciesz się.
Dalej to też tragedia, źle zrozumiałem fread() i fwrite().
Pytanie tylko czy zrozumiałeś co zrobiłeś źle. Inną kwestią jest czy wiesz jak to zrobić dobrze. Poczytaj, popróbuj, a jak nic nie wykombinujesz - pytaj.
Przepraszam za kłopot, po prostu brnę do przodu za szybko z tymi rozdziałami i się potykam.
Nie masz za co przepraszać zbytnio. I nie ucz się języka C "na szybko". Wymaga on skupienia i zrozumienia jak coś działa i dlaczego. Bez tego będzie tylko trudniej i więcej błędów trudnych do wykrycia. Przykładem jest chociażby ten Twój long *c
, który wynika z braku wiedzy o wskaźnikach (lub wiedzy niekompletnej).
Na zachętę podpowiem Ci, że nie musisz znać rozmiaru pliku kopiowanego, a tym samym używać pętli for
(aczkolwiek pętla będzie konieczna). Zobacz w dokumentacji co i w jakich przypadkach zwraca funkcja fread()
.