функция qsort сравнить меня смутила

Я думаю это неправильно

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

return *(int*)a - *(int*)b;  // Potential undefined behavior.

Распространенная идиома - вычесть два целых числа сравнения. Различные компиляторы распознают это и создают эффективный, хорошо управляемый код. Сохранение const-сущности также является хорошим тоном.

const int *ca = a;
const int *cb = b;
return (*ca > *cb) - (*ca < *cb);

почему многие книги и веб-сайты пишут в такой вводящей в заблуждение манере.

return *a - *b; концептуально легко усвоить - даже если он дает неправильный ответ с экстремальными значениями - часто в коде учащегося опускаются граничные условия, чтобы донести идею - «зная», что значения будут никогда не быть большим.

Или рассмотрите сложности сравнения long doubles с NaN.

Ваше понимание абсолютно правильное. Эту общую идиому нельзя использовать для значений int.

Предлагаемое вами решение работает правильно, хотя было бы более читабельным с локальными переменными, чтобы избежать такого большого количества приведений:

int compare(const void *a, const void *b) {
    const int *aa = a;
    const int *bb = b;
    if (*aa < *bb)
        return -1;
    else if (*aa > *bb)
        return 1;
    else 
        return 0;
}

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

Обычно используется более компактное решение с таким же точным результатом, хотя его немного сложнее понять:

int compare(const void *a, const void *b) {
    const int *aa = a;
    const int *bb = b;
    return (*aa > *bb) - (*aa < *bb);
}

Обратите внимание, что этот подход работает для всех числовых типов, но вернет 0 для значений с плавающей запятой NaN.

Что касается вашего замечания: Я просто не могу понять, почему многие книги и веб-сайты пишут в такой вводящей в заблуждение манере:

• Многие книги и веб-сайты содержат ошибки, как и большинство программ. Многие программные ошибки обнаруживаются и устраняются еще до того, как они попадут в рабочую среду, если программа протестирована с умом. Фрагменты кода в книгах не тестируются, и хотя они никогда не достигают рабочей версии, содержащиеся в них ошибки вирусно распространяются через ничего не подозревающих читателей, которые изучают поддельные методы и идиомы. Очень плохой и продолжительный побочный эффект.

• Престижность вам за то, что вы это поймали! У вас есть редкий среди программистов навык: вы хороший читатель. Программистов, пишущих код, гораздо больше, чем тех, кто умеет правильно читать код и видеть ошибки. Оттачивайте этот навык, читая чужой код, при переполнении стека или из проектов с открытым исходным кодом ... И сообщайте об ошибках.

• Метод вычитания широко используется, я видел его во многих местах, как и вы, и он действительно работает для большинства пар значений. Эта ошибка может оставаться незамеченной на долгие годы. Подобная проблема была скрыта в zlib на протяжении десятилетий: int m = (a + b) / 2; вызывает роковое целочисленное переполнение для больших int значений a и b.

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

• Обратите внимание, однако, что ошибочная функция работает правильно для типов меньше, чем int: signed или unsigned char и short, если эти типы действительно меньше, чем int на целевой платформе, что стандарт C не требует.

• Действительно, похожий код можно найти в языке программирования C Брайана. Керниган и Деннис Ричи, знаменитая Библия K&R C, созданная ее изобретателями. Они используют этот подход в упрощенной реализации strcmp() в главе 5. Код в книге датирован концом семидесятых. Хотя он имеет поведение, определяемое реализацией, он не вызывает неопределенного поведения ни в одной, кроме самых редких архитектур, среди которых печально известный DeathStation-9000, но его нельзя использовать для сравнения int значений.

Вы правы, *(int*)a - *(int*)b представляет риск целочисленного переполнения, и его следует избегать как метода сравнения двух int значений.

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

Причина, по которой так много неправильных книг, вероятно, является корнем всего зла: книгой K&R. В главе 5.5 они пытаются научить, как реализовать strcmp:

int strcmp(char *s, char *t)
{
  int i;
  for (i = 0; s[i] == t[i]; i++)
    if (s[i] == '\0')
      return 0;
  return s[i] - t[i];
}

Этот код вызывает сомнения, поскольку char имеет подпись, определяемую реализацией. Игнорируя это и игнорируя то, что они не могут использовать корректность констант, как в стандартной версии C, код в остальном работает, частично потому, что он полагается на неявное продвижение типа до int (что некрасиво), частично потому, что они предполагают 7-битный ASCII, а в худшем случае 0 - 127 не может переполниться.

Далее в книге, 5.11, они пытаются научить использовать qsort:

qsort((void**) lineptr, 0, nlines-1,
  (int (*)(void*,void*))(numeric ? numcmp : strcmp));

Игнорируя тот факт, что этот код вызывает неопределенное поведение, поскольку strcmp несовместим с указателем функции int (*)(void*, void*), они учат использовать указанный выше метод из strcmp.

Однако, глядя на их numcmp функцию, это выглядит так:

/* numcmp: compare s1 and s2 numerically */
int numcmp(char *s1, char *s2)
{
  double v1, v2;
  v1 = atof(s1);
  v2 = atof(s2);
  if (v1 < v2)
    return -1;
  else if (v1 > v2)
    return 1;
  else
    return 0;
}

Игнорируя тот факт, что этот код выйдет из строя и сгорит, если atof обнаружит недопустимый символ (например, очень вероятная проблема локали с . по сравнению с ,), им действительно удается научить правильному методу написания такой функции сравнения. Поскольку эта функция использует числа с плавающей запятой, другого способа записать ее нет.

Теперь кто-то может захотеть придумать int версию этого. Если они будут делать это на основе реализации strcmp, а не реализации с плавающей запятой, они получат ошибки.

В целом, просто пролистав несколько страниц в этой некогда канонической книге, мы уже нашли 3-4 случая зависимости от неопределенного поведения и 1 случай зависимости от поведения, определенного реализацией. Так что неудивительно, что люди, изучающие C по этой книге, пишут код, полный неопределенного поведения.

Во-первых, конечно, правильно, что целое число во время сравнения может создать для вас серьезные проблемы.

С другой стороны, выполнение одного вычитания дешевле, чем выполнение if / then / else, и сравнение выполняется O (n ^ 2) раз в быстрой сортировке, поэтому, если эта сортировка критична к производительности, и мы можем уйти с его помощью мы можем захотеть использовать разницу.

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

Обратите внимание, что проверка того, что значения находятся в таком диапазоне до сортировки, является операцией O (n).

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

Обратите внимание, что много материала, который вы видите, явно не учитывает переполнение; просто, возможно, этого более ожидаемо в чем-то более очевидном «арифметическом» контексте.