Блог

Правда ли, что:

• Нет указателя на данные больше, чем sizeof(void *) ?
• Нет указателя на данные больше, чем sizeof(char *) ?
• Никакое целое число не больше, чем sizeof(intmax_t) ?
• Ни float то, ни double другое не больше, чем sizeof(long double) ?

Я знаю, что intmax_t может хранить любое значение, которое может хранить любое другое целое число со знаком, но требуется ли, чтобы размер также был наибольшим размером любого целого числа? Или возможно, что какое-то другое целое число использует так много битов заполнения intmax_t , что размер этого целого числа становится больше, чем intmax_t даже тогда, когда это целое число не может содержать какое-либо значение, которое intmax_t не может содержать?

Аналогично указателям, я знаю, что любой другой указатель данных может быть преобразован в char * void * и обратно без потери информации, но означает ли это, что размер char * и void * должен быть максимально возможным размером всех указателей данных?

Я задаю этот вопрос, потому что у меня есть функция в библиотеке, которая преобразует строку в другой тип, который обозначается целым числом. Чтобы проверить, можно ли выполнить этот диалог для данной строки (формат правильный), существует функция, которая проверяет это для разных типов данных, функция должна зарезервировать достаточно памяти для всех возможных типов, выполнить диалог, проверить наличие ошибок и снова освободить эту память. Достаточно ли этого, чтобы убедиться, что он достаточно велик intmax_t , чтобы охватить все целочисленные типы?

Есть intptr_t сейчас, которое гарантированно работает; однако платформы прошлых лет, на которых intptr_t нужно было бы быть больше, чем ptrdiff_t нет intptr_t , потому что они заморожены во времени, а собственные компиляторы для целевых платформ просто не имеют этого. Если у вас есть современный компилятор, такой как OpenWatcom, ориентированный на старые архитектуры, он будет работать.

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

• Значение NULL не равно 0. Это означает, что memset() это не инициализирует указатели в структурах на NULL и не делает calloc() этого ; и они не являются нулевыми, когда объявлены как статические, если явно не инициализированы на NULL .
• sizeof(char *) < sizeof(const char *) и sizeof(void *) < sizeof(const void *) ; этот конкретный компилятор не давал intptr_t и ptrdiff_t не мог содержать результат произвольного вычитания двух указателей в одном и том же массиве символов (но этого можно было избежать, сделав массив символов не больше PTRDIFF_T_MAX).
• Компилятор не реализовал C99 и не имел intptr_t и ptrdiff_t был слишком мал, чтобы содержать указатель.
• free() ничего не сделал
• Компилятор статически удалил тесты с нулевым указателем, где он мог доказать, что указатель указывает на структуру, но NULL был возможным адресом глобальной переменной.

Я никогда не пытался заставить нетривиальную библиотеку работать во встроенном мире и, конечно, никогда не сталкивался с такими указателями, как этот.

TL;DR Все ваши четыре утверждения должны быть верными, но когда их подвергают испытанию огнем, где это имеет значение, вы в конечном итоге сталкиваетесь с уродством.

Мне приходит в голову, что вы конвертируете между указателем и строкой sprintf и sscanf у вас есть спецификаторы формата, которые могут это сделать.