Подразумевает ли квалификатор типа ограничения C99/C11 что-либо для функций без определения?

Если да, то: является ли последнее предложение описания sprintf лишним (пусть и уточняющим)?
Если копирование происходит между перекрывающимися объектами, поведение не определено.

int sprintf(char * restrict s,  const char * restrict format, ...);

restrict на s означает, что чтение и запись зависят только от того, что делает sprintf(). Следующий код делает это, читая и записывая данные, указанные p1 в качестве аргумента char * restrict s. Чтение/запись произошло только из-за прямого кода sprintf(), а не из-за побочного эффекта.

char p[100] = "abc";
char *p1 = p;
char *p2 = p;
sprintf(p1, "<%s>", p2);

Тем не менее, когда sprintf() получает доступ к данным, на которые указывает p2 , restrict не существует. «Если копирование происходит между перекрывающимися объектами, поведение не определено» применяется к p2, чтобы сказать, что данные p2 не должны изменяться из-за какого-то побочного эффекта.

Если нет, то наоборот: является ли квалификатор limited лишним, поскольку именно описание дает нам знать, какое поведение будет неопределенным?

restrict здесь для компилятора, чтобы реализовать доступ restrict. Нам не нужно его видеть, учитывая спецификацию «Если происходит копирование...».

Рассмотрим более простой strcpy(), который имеет то же самое «Если копирование происходит между перекрывающимися объектами, поведение не определено». Для нас, читателей, здесь это лишнее, так как тщательное понимание restrict (новое в C99) в этом не нуждается.

char *strcpy(char * restrict s1, const char * restrict s2);

C89 (до restrict дней) также имеет эту формулировку для strcpy(), sprintf(), ... и поэтому может быть просто остатком спецификации в C99 для strcpy().

Самым сложным аспектом type * restrict p я считаю то, что он относится к тому, что не произойдет с его данными (данные p не изменятся неожиданно - только через p). Тем не менее, запись в данные p разрешена, чтобы запутать других — если только у них нет restrict.

• restrict был введен в C99.
• Since we do not know how the pointers will be accessed, we cannot know if a call will trigger undefined behavior
  Да. Но это вопрос доверия. Объявление функции — это контракт между программистом, написавшим определение функции, и программистом, использующим эту функцию. Помните, когда-то в C мы просто написали бы void f(); — здесь f — функция, которая принимает неопределенное количество параметров. Если вы не доверяете тому программисту, который написал эту функцию, никто не будет и не будет использовать эти функции. В C мы передаем адрес первого элемента массива, поэтому, увидев функцию, объявленную таким образом, я бы предположил: программист, написавший эту функцию, дает некоторое описание того, как используются эти указатели, или функция f использует их как указатели на один элемент, не как массивы.
  ( В такие времена мне нравится использовать C99 VLA в объявлении функции, чтобы указать, какой длины массивы ожидает моя функция: void f(int p[restrict 5], int q[restrict 10], int r[restrict 15]);. Такое объявление функции точно такое же, как у вас, но у вас есть некоторое представление о том, какая память может' т перекрываются.)
• char s[4]; sprintf(s, "%s", s); вызовет неопределенное поведение?
  Да. Копирование происходит между объектами, которые перекрываются и ограничивают доступ к расположению двумя указателями.

Учитывая сигнатуру функции, например:

void copySomeInts(int * restrict dest, int * restrict src, int n);

кому-то, кто хочет, чтобы функция давала определенное поведение в случае, когда источник и место назначения перекрываются [или даже когда они равны], должен был приложить некоторые дополнительные усилия для этого. Было бы возможно, например.

void copySomeInts(int * restrict dest, int const * restrict src, int n)
{
  for (int i=0; i<n; i++)
  {
    if (dest+i == src)
    {
      int delta = src-dest;
      for (i=0; i<n; i++)
        dest[i] = dest[delta+i];
      return;
    }
    if (src+i == dest)
    {
      int delta = src-dest;
      for (i=n-1; i>=0; i--)
        dest[i] = src[delta+i];
      return;
    }
  }
  /* No overlap--safe to copy in normal fashion */
  for (int i=0; i<n; i++)
    dest[i] = src[i];
}

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

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

Обратите внимание, что в случае, когда источник и место назначения перекрываются, никакое хранилище фактически не адресуется с помощью указателя src или чего-либо, производного от него. Если src+i==dest или dest+i==src, это будет означать, что и src, и dest идентифицируют элементы одного и того же массива, и, таким образом, src-dest будет просто представлять разницу в их индексах. Квалификаторы const и limited в src означают, что ничто, доступ к которому осуществляется с помощью указателя, полученного из src, не может быть каким-либо образом изменено во время выполнения функции, но это ограничение применяется только к вещам, доступ к которым осуществляется с помощью указателя, полученного из src. Если с помощью таких указателей фактически ни к чему не обращаются, ограничение бесполезно.