Разыменование указателя с символом типа нарушит строгие правила псевдонимов

Похоже, вы действительно хотите использовать fread:

int data;
fread(&data, sizeof(data), 1, stream);

Тем не менее, если вы действительно хотите пойти по пути чтения символов, а затем интерпретировать их как int, безопасный способ сделать это в C (но не в C++) — использовать объединение:

union
{
    char theChars[4];
    int theInt;
} myunion;

for(int i=0; i<4; i++)
    myunion.theChars[i] = fgetc(stream);
return myunion.theInt;

Я не уверен, почему длина data в вашем исходном коде равна 3. Я предполагаю, что вы хотели 4 байта; по крайней мере, я не знаю ни одной системы, где int составляет 3 байта.

Обратите внимание, что и ваш, и мой код крайне непереносимы.

Редактировать: если вы хотите читать целые числа различной длины из файла, переносимого, попробуйте что-то вроде этого:

unsigned result=0;
for(int i=0; i<4; i++)
    result = (result << 8) | fgetc(stream);

(Примечание: в реальной программе вам может понадобиться дополнительно проверить возвращаемое значение fgetc() на соответствие EOF.)

Это считывает 4 байта без знака из файла в формате с прямым порядком байтов, независимо от порядка следования байтов в системе. Он должен работать практически в любой системе, где без знака не менее 4 байтов.

Если вы хотите быть нейтральным к порядку байтов, не используйте указатели или объединения; вместо этого используйте битовые сдвиги.

Проблема возникает из-за того, что вы обращаетесь к массиву символов через double*:

char data[8];
...
return *(double*)data;

Но gcc предполагает, что ваша программа никогда не будет обращаться к переменным через указатели другого типа. Это предположение называется strict-aliasing и позволяет компилятору выполнять некоторые оптимизации:

Если компилятор знает, что ваш *(double*) никоим образом не может пересекаться с data[], ему разрешены всевозможные вещи, такие как переупорядочение вашего кода в:

return *(double*)data;
for(int i=7;i>=0;i--)
    data[i] = fgetc(stream);

Цикл, скорее всего, оптимизирован, и в итоге вы получите только:

return *(double*)data;

Что оставляет ваши данные [] неинициализированными. В этом конкретном случае компилятор может увидеть, что ваши указатели перекрываются, но если бы вы объявили его char* data, это могло привести к ошибкам.

Но строгое правило сглаживания говорит, что char* и void* могут указывать на любой тип. Таким образом, вы можете переписать его в:

double data;
...
*(((char*)&data) + i) = fgetc(stream);
...
return data;

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

Использование объединения здесь неправильно. Чтение из неписаного члена объединения не определено, т. е. компилятор может выполнять оптимизации, которые сломают ваш код (например, оптимизация записи).

Этот документ обобщает ситуацию: http://dbp-consulting.com/tutorials/StrictAliasing.html

return *(short*)data;

short temp;
memcpy(&temp, data, sizeof(temp));
return temp;

По сути, вы можете прочитать сообщение gcc как парень, вы ищете неприятностей, не говорите, что я вас не предупреждал.

Приведение трехбайтового массива символов к int — одна из худших вещей, которые я когда-либо видел. Обычно ваш int имеет как минимум 4 байта. Итак, для четвертого (а может быть и больше, если int шире) вы получаете случайные данные. А затем вы отбрасываете все это на double.

Просто не делай ничего из этого. Проблема псевдонимов, о которой предупреждает gcc, невинна по сравнению с тем, что вы делаете.

Авторы стандарта C хотели позволить разработчикам компиляторов генерировать эффективный код в обстоятельствах, когда теоретически возможно, но маловероятно, что глобальная переменная может получить доступ к своему значению с помощью, казалось бы, несвязанного указателя. Идея заключалась не в том, чтобы запретить каламбуры путем приведения и разыменования указателя в одном выражении, а в том, чтобы сказать, что при наличии чего-то вроде:

int x;
int foo(double *d)
{
  x++;
  *d=1234;
  return x;
}

компилятор вправе предположить, что запись в *d не повлияет на x. Авторы стандарта хотели перечислить ситуации, когда функция, подобная приведенной выше, которая получила указатель из неизвестного источника, должна была бы предположить, что она может быть псевдонимом, казалось бы, несвязанного глобального, не требуя, чтобы типы полностью совпадали. К сожалению, хотя логическое обоснование убедительно свидетельствует о том, что авторы Стандарта намеревались описать стандарт для минимального соответствия в случаях, когда у компилятора в противном случае не было бы оснований полагать, что вещи могут создавать псевдонимы, правило не требует, чтобы компиляторы распознают псевдонимы в тех случаях, когда это очевидно, и авторы gcc решили, что они скорее будут генерировать наименьшую программу, которую они могут, но при этом соответствовать плохо написанному языку Стандарта, чем генерировать код, который на самом деле полезно, и вместо того, чтобы распознавать псевдонимы в тех случаях, когда это очевидно (хотя при этом можно предположить, что вещи, которые не выглядят так, как будто они будут псевдонимами, не будут), они скорее требуют, чтобы программисты использовали memcpy, таким образом требуя компилятор, чтобы учесть возможность того, что указатели неизвестного происхождения могут быть псевдонимами практически чего угодно, что препятствует оптимизации.

По-видимому, стандарт позволяет sizeof(char*) отличаться от sizeof(int*), поэтому gcc жалуется, когда вы пытаетесь выполнить прямое приведение. void* немного отличается тем, что все можно преобразовать туда и обратно в void* и обратно. На практике я не знаю многих архитектур/компиляторов, где указатель не всегда одинаков для всех типов, но gcc правильно выдает предупреждение, даже если это раздражает.

Я думаю, что безопасный способ был бы

int i, *p = &i;
char *q = (char*)&p[0];

or

char *q = (char*)(void*)p;

Вы также можете попробовать это и посмотреть, что вы получите:

char *q = reinterpret_cast<char*>(p);