fwrite не ведет себя так, как должно быть

Question

У меня есть программа на языке С, которая записывает в файл с помощью команды fwrite (..), и результат не согласуется с аргументами функции, которые я предоставляю.

uint32_t x = 1009716161; 
    FILE * file = fopen("helloop.txt", "wb+"); 
    rewind(file); 
    fwrite(&x, sizeof(uint32_t), 1, file); 
    fclose(file); 

Когда я проверяю файл позже, кажется, содержит символы, которые не транслируют на что-нибудь

>cat helloop.txt 
>Á/< 

, как я должен получать этот

>cat helloop.txt 
>000000003C2F0BC1 

Я проверил разрешения файла и Я chmodded это

chmod 777 helloop.txt 

Как я вижу, у меня есть 1 элемент размером 32 бит, который я хочу записать в файл, Что я делаю неправильно?

Answer 1

кошка helloop.txt A/<

cat печатает символьные данные. Он не печатает 4-байтовое значение в файле как 32-битное целое число.

, как я должен получать этот

кошка helloop.txt 000000003C2F0BC1

Нет, вы не должны, а не с cat. Вам придется записать в файл символьную строку «000000003C2F0BC1», если вы этого хотите. Файл, вероятно, будет содержать 16 символов. Я бы поставил прямо сейчас, если вы запустите ls -l helloop.txt, вы увидите размер 4, потому что вы написали двоичное целое число uint32_t в файл.

что я делаю неправильно?

Насколько я могу судить, единственное, что вы сделали неправильно ожидает cat, чтобы распечатать свой uint32_t как шестнадцатеричное представление. (Хотя я не проверял ваше шестнадцатеричное значение, так что это может быть и неправильным)

Посмотрите, есть ли у вас hexdump на вашем компьютере Linux, это может дать вам лучшие результаты.

EDIT: Если вы на самом деле хотите, чтобы напечатать uint32_t как шестнадцатеричной строки, вы можете использовать fprintf(..., "%x", x) с x или X спецификатор формата, но имейте в виду, что это не совместимо с FWRITE/FREAD, поэтому читать его обратно вам нужно будет прочитать строку и преобразовать обратно из hex в int.

Answer 2

Ваша программа сделала именно то, что вы сказали ей.

В общем случае, если программа, которую вы написали, кажется неправильной, вам не следует переходить к выводу, что операционная система, компилятор или библиотека времени выполнения находятся под сбоем. Скорее всего, в вашей программе есть ошибка, или что вы что-то неправильно поняли. Это остается верным независимо от того, сколько лет опыта у вас есть.

Значение 1009716161, выраженное в шестнадцатеричном выражении, равно 0x3c2f0bc1. Когда вы записываете это значение в двоичный файл, вы пишете 4 8-битных байта со значениями 0x3c, 0x2f, 0x0b и 0xc1. В ASCII это '<', '/' и два символа вне диапазона ASCII для печати. Порядок, в котором они написаны, зависит от вашей системы, но содержимое, о котором вы сообщаете, похоже на это.

Я не уверен, почему вы ожидаете увидеть 000000003C2F0BC1. Это 16 байт, когда вы только написали 4 байта в файл. Кроме того, двоичные файлы не содержат ASCII-рендеринга шестнадцатеричного представления данных, которые вы написали - они содержат только данные

Если изучить файл пути преобразования его из необработанных двоичных шестнадцатеричного (с помощью hexdumpod -x или команды, если ваша система имеет его), вы должны увидеть что-то узнаваемое

.. И если вы откроете файл в двоичном режиме и используйте fread, чтобы прочитать данные обратно в объект uint32_t, вы должен получить первоначальное значение 1009716161 назад - вот и все.