Воскресенье пробило стек? )

ЧТД. Никто в здравом уме этим глюкодромом всё равно пользоваться не станет.

но ты конечно же заслал им уже патч вида

-gchar time_str[50];
+gchar time_str[64];

?

использование time(). если ты используешь GLib -> используй GDateTime

Как это может помешать залогиниться? Максимум, выведет мусор вместо даты.

http://mdzlog.alcor.net/2009/08/15/bohrbugs-openoffice-org-wont-print-on-tues...

Попробовал, но говнокодеры не дремлют и при попытке отправки сообщения о баге происходят другие баги :D :D :D

vitus@s1:~/.local/bin$ reportbug
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2211, in <module>
    main()
  File "/usr/bin/reportbug", line 1081, in main
    return iface.user_interface()
  File "/usr/bin/reportbug", line 1703, in user_interface
    latest_first=self.options.latest_first)
  File "/usr/lib/python2.7/dist-packages/reportbug/ui/gtk2_ui.py", line 1505, in func
    args, kwargs = op.sync_pre_operation (*args, **kwargs)
TypeError: 'NoneType' object is not iterable

по идее да (по данному куску кода), но пропадает окно с логином, выдаётся чёрный экран с сообщение сессия заблокирована и т.п. ввести пароль не просто.

Там когда-то было 25, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721510 получили бага и решили - «50 хватит всем» ! :D

Even simply increasing the buffer size to 50 with no other

changes would allow any reasonable date+time format to fit.

ну да, ну да, конечно

лучше сразу 128.

а потом жалуются, что программы жирные и память как не в себя жрут :D

C++ не нужен говорили они

Теоретически можно сделать time_str динамическим, засунуть strftime в конструкцию вида try-catch и делать realloc по вылету за пределы. Но на чистом си будет выглядеть тем ещё велосипедом, поэтому давайте просто зафигачим длину побольше.

но ты конечно же заслал им уже патч

Это же опенсорс, проще форкнуть и сделать gchar time_str[64] переписать нормально.

ЧТД. Никто в здравом уме этим глюкодромом всё равно пользоваться не станет.

++

256, кто больше. 256 ррраз. 256 два....

Теоретически можно сделать time_str динамическим, засунуть strftime в конструкцию вида try-catch и делать realloc по вылету за пределы.

Ты что курил?

Попробовал, но говнокодеры не дремлют и при попытке отправки сообщения о баге происходят другие баги :D :D :D

Напомнило мне крэш-репорт об упавшем крэш-репорте, предложившим отправить отчёт об упавшем центре установки программ в какой-то десятой бубунте, запущенной с фирменного ливсд, после чего моё знакомство с бубунтой было закончено.

256, кто больше. 256 ррраз. 256 два....

256 терабайт, чтобы пользователи подобное говно сразу в /dev/null выбрасывали.

-strftime(time_str, 50, clock_format, timeinfo)
+if (!strftime(time_str, sizeof(time_str), clock_format, timeinfo))
+    strcat(time_str, "date appears to long, please send a bug report to ours developers "
+                     "via reportbug or directly at https://bugs.debian.org.");

же

Otherwise, zero is returned and the buffer contents are indeterminate.

переписать нормально

Не использовать strftime?

Добавить экран лапши для предварительного определения нужной длины (с учётом локали)?

Не использовать strftime?

Не использовать C.

других нормальных языков нет

Блин

Слона-то я и не приметил 😀

size_t size = 64; char *s = malloc(size);
while (!strftime(s, size, ...)) s = realloc(s, size *= 2);

printf("%s\n", s);
free(s);

Либо вынести один раз в astrftime().

Лорчую этого лингвиста.

while (!strftime(s, size, ...)) s = realloc(s, size *= 2);

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

Неправда. Сишечка это не столько скорость кода, сколько неудаленная от железа и необремененная глупыми хипстерскими абстракциями среда со статической типизацией. Лучше выделить *начальный* буфер побольше и навсегда забыть об этом.

корректность важнее

Плюсую с оговоркой что strftime в других имплементациях libc может и не ноль возвращать в случае превышения указанной длины.

И еще

Note that the return value 0 does not necessarily indicate an error. For example, in many locales %p yields an empty string. An empty format string will likewise yield an empty string.

If the output string would exceed max bytes, errno is not set. This makes it impossible to distinguish this error case from cases where the format string legitimately produces a zero-length output string. POSIX.1-2001 does not specify any errno settings for strftime().

Так что пернписывай на плюсах с put_time и не морочь голову :)

size_t size = 64; char *s = malloc(size);
while (!strftime(s, size, " <format>", &tm))
    s = realloc(s, size *= 2);

printf("%s\n", s+1);
free(s);

Формулировка и правда печальная:

If the total number of resulting bytes including the terminating null byte is not more than maxsize, these functions shall return the number of bytes placed into the array pointed to by s, not including the terminating NUL character. Otherwise, 0 shall be returned and the contents of the array are unspecified.

Так что пернписывай на плюсах
не морочь голову

Взаимоисключающие параграфы для меня.

Да давно известно, что сишечка не умеет в строки от слова совсем.

Ну и чо? Патч с костылём, который обрезает строку до 50 символов в случае переполнения отправили?

Пришли им фотку Индиры Ганди с атомной бомбой

везет тебе. у меня вот пару раз права на файлы в /run/user слетали в ноль. вот тут точно хрен залогинишься.

В сишечку так и не завезли динамические массивы?

Меня почему-то удивляет то, что в коде делают магиеские цифры. Тем более тогда, как такой баг уже был и там была 25, ну сложно что-ль было нормально в константу куда-нибудь вынести?

Проще цыферку увеличить.

Ты не понял. Результат просто так может быт пустым. Просто потому что так задан формат. Функция вернет ноль. В итоге бесконечный цикл с бесконечным реаллоком.

gchar time_str[50];
File «/usr/lib/python2.7/dist-packages/reportbug/ui/gtk2_ui.py»

кто-то ещё удивляется?

нормальных языков для генерации глюкодрома? отчего же? вон, питон ещё есть.

Я же специально пробел вначале сунул. Как он ноль вернет, если для успеха минимум 1 нужен?

// в целом да, плохо спроектированная функция, лучше бы было sprintf-like.

Тут дело не в динамических массивах, а в том, что кодеры lightdm не думают о последствиях принимаемых решений. Могли бы хоть предусмотреть разные варианты ввода данных и вкорячить обрезалку строки.

Момент с пробелом на телефоне не уловил :)

Костыли :)

по сабжу: лень проверять.

не

const int time_str_size = 51;
gchar time_str[time_str_size];
gchar *markup;
time_str_size[time_str_size - 1] = '\0';
time ( &rawtime );
timeinfo = localtime ( &rawtime );
strftime(time_str, time_str_size-1, clock_format, timeinfo);
/code]

?

баг в том, что в конец time_str не дописывается ноль?

тут дело в динамических массивах, потому, что кодерам lightdm из-за них (точнее, их отсутствия в нормальном виде) приходится городить простыню и быдлокод, вместо одной строки на других языках.