Можно ли передавать адрес int для scanf ("% x", ...)?
Определил ли следующий код поведение:
#include <stdio.h>
int main() {
int x;
if (scanf("%x", &x) == 1) {
printf("decimal: %d\n", x);
}
return 0;
}
clang компилирует его без каких-либо предупреждений даже со всеми включенными предупреждениями, включая -pedantic. Стандарт C кажется недвусмысленным по этому поводу:
C17 7.21.6.2 The
fscanffunction...
... the result of the conversion is placed in the object pointed to by the first argument following the format argument that has not already received a conversion result. If this object does not have an appropriate type, or if the result of the conversion cannot be represented in the object, the behavior is undefined.
...
The conversion specifiers and their meanings are:
...
xMatches an optionally signed hexadecimal integer, whose format is the same as expected for the subject sequence of thestrtoulfunction with the value16for thebaseargument. The corresponding argument shall be a pointer to unsigned integer.
В двух комплементарных архитектурах преобразование -1 в %x, похоже, работает, но не в древних системах знак / величина или системах дополнения.
Есть ли какое-либо положение, чтобы определить это поведение или, по крайней мере, определить реализацию?
@mch: хороший момент, я не знал о -fwrapv, который, вероятно, является хорошим способом предотвратить некоторую недружелюбную оптимизацию компилятора. Как я уже писал, дополнение 2 должно работать, но 2147483648 unsigned == -1 int неверен, 4294967295 uint32_t - это -1 int32_t
Ответы 1
Это подпадает под категорию поведения, которое качественные реализации должны поддерживать, если они не документируют вескую причину поступить иначе, но которое Стандарт не требует. Авторы Стандарта, похоже, воздерживаются от попытки перечислить все такое поведение, и для этого есть как минимум три веские причины:
Это сделало бы Стандарт длиннее, а трата чернил на описание очевидного поведения, которого читатели в любом случае ожидали бы, отвлекла бы от тех мест, где Стандарту нужно было привлечь внимание читателей к вещам, которых они в противном случае не могли бы ожидать.
Авторы Стандарта, возможно, не хотели исключать возможность того, что реализация может иметь вескую причину для выполнения чего-то необычного. Я не знаю, было ли это соображением в вашем конкретном случае, но могло быть.
Рассмотрим, например, (вероятно, теоретическую) среду, соглашение о вызовах которой требует передачи информации о типах аргументов, передаваемых в вариативные функции, и которая предоставляет функцию scanf, которая проверяет эти типы аргументов и выдает сигнал, если
int*передается аргументу%X. Авторы Стандарта почти наверняка не знали о какой-либо такой среде [я сомневаюсь, что она когда-либо существовала], и поэтому не могли бы сопоставить преимущества использования подпрограммы scanf среды с преимуществами поддержки общего поведения. Таким образом, было бы разумно оставить такое суждение на усмотрение людей, которые могли бы лучше оценить затраты и выгоды каждого подхода.Авторам Стандарта было бы чрезвычайно сложно гарантировать, что они исчерпывающе перечислили все такие случаи, не пропустив ни одного, и чем более исчерпывающе они попытаются перечислить такие случаи, тем более вероятно, что случайные упущения будут неверно истолкованы как преднамеренный.
На практике некоторые разработчики компиляторов, кажется, рассматривают большинство ситуаций, когда Стандарт не может предписать поведение какого-либо действия, как приглашение предположить, что код никогда не попытается его выполнить, даже если все реализации до Стандарта вели себя согласованно, и маловероятно, что когда-либо это произойдет. быть какой-либо веской причиной для того, чтобы реализация поступила иначе. Следовательно, использование %X для чтения int попадает в категорию поведения, которое будет надежным в реализациях, которые прилагают какие-либо усилия для обеспечения совместимости с распространенными идиомами, но может потерпеть неудачу в реализациях, разработчики которых придают большее значение способности обрабатывать бесполезные программы. эффективно, или на реализациях, которые спроектированы так, чтобы кричать при задании программ, которые могут быть подорваны такими реализациями.
Ваш результат зависит от поведения дополнения 2 (
2147483648unsigned ==-1int). Вы можете использовать флаг компилятора-fwrapv, чтобы определить знаковое целочисленное переполнение как поведение дополнения до 2.