Кто-нибудь из форумчан на практике сталкивался с ошибкой при работе sprintf()?

Когда при выполнении происходит ошибка.

Да ты прям генерал ясен х*р.

Что на счёт конкретики? У остальных функций есть список errno, который содержит все возможные ошибки.

У остальных функций есть список errno, который содержит все возможные ошибки.

Это не соответствует действительности.

Ну то есть по делу сказать нечего. Ок.

Ну то есть по делу сказать нечего. Ок.

Вы не задали конкретного вопроса.

И, чтобы вы не утруждались:

ты не задал конкретного вопроса

К окулисту загляни на досуге ;)

Не стоит так отвечать, если вы просите о помощи.

sprintf нормальные люди вообще не используют, потому что это прямой путь к buffer overflow. Нормальные люди используют snprintf, а у него есть как минимум ошибка недостаточного размера буфера как раз.

Нормальные люди используют snprintf, а у него есть как минимум ошибка недостаточного размера буфера как раз.

Он не возвращает ошибку если буфер маленький, просто тихо обрезает, а потом злоумышленник может это использовать.

#include <stdio.h>

int main() {
    char path[5];
    if (snprintf(path, sizeof(path), "/usr/share/useless-program") < 0)
        return -1;
    printf("rm -rf %s\n", path);
    return 0;
}

Так что нормальные люди не используют strlcat, snprintf. Нормальные люди используют sprintf_s под управлением Microsoft (TM) (C) (Protected) (Patented) .NET CLI/C.

snprintf

Он не возвращает ошибку если буфер маленький, просто тихо обрезает

Он не «тихо обрезает», а возвращает количество байт, которое требуется для результата. Для этого и предназначен. Чтобы сделать malloc() или realloc() под результат и вызвать snprintf повторно.

Нормальные люди используют

g_strdup_printf(), при использовании glib2 в проекте.

Или если glib2 не используется, её аналог пишется за 5 минут при помощи того же snprintf.

snprintf() не спасает от неправильного количества аргументов. Читай выше.

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

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

Вот тут ты сильно ошибаешься.

n The number of characters written so far is stored into the integer pointed to by the corresponding argument. That argument shall be an int *

Этой штукой вполне можно перетереть, например, указатель на возврат в стеке.

Он не «тихо обрезает», а возвращает количество байт, которое требуется для результата.

Однако стоило ограничить это только на NULL, 0

Чтобы сделать malloc() или realloc() под результат и вызвать snprintf повторно.

А в это время произошла смена локали, поэтому результат не влез!

Нормальные люди используют

g_strdup_printf(), при использовании glib2 в проекте.

Зачем тащить glib? Есть asprintf.

Или если glib2 не используется, её аналог пишется за 5 минут при помощи того же snprintf.

asprintf!

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

Конечно приведет. Почти любая неправильная передача va_arg к этому приведет.

всё что общается с человеком это глюкодром, даже glibc в кернел паник ядро раняет при работай с локалью на не валидном utf8, сейчас вроде нет, но новость проскакивала что ошибка в php который функцию glib вызывал и он систему ронял. Мне musl в этом плане очень даже ничего в локаль не ползёт, но говорят что медленее (мои тесты показали что нет), и дома на alpine с musl пол года просидел, заколебало весь софт практически пересобирать исходники править.

КСЖ

Раскажи как это происходит? Ведь там идет только чтение того, что лежит на стеке.

Как это возможно, если функция пишет только в переданный буффер, и при этом не выходит за указанный размер?

Как это возможно, если функция пишет только в переданный буффер, и при этом не выходит за указанный размер?

Нет. При указании «%n» в форматной строке данные будут записаны по указателю в соответствующем аргументе.

Это одна из причин, почему никогда нельзя куски форматной строки брать из пользовательского ввода, тащемта. Можно словить remote code execution.

Ну и плюс тут есть ещё такой нюанс что va_arg. Про это морковка тебе объяснит, мне лень печатать, я и так в двух тредах параллельно тут.

Стек был 30 лет назад, сейчас она принимает регистры.

А нахрена его использовать? Просто не используй и не будет выстрела в ногу.