| |
| 2.5, Дмитрий (??), 12:23, 30/10/2013 [^] [^^] [^^^] [ответить]
| +3 +/– |
Если почитать оригинал (http://lwn.net/Articles/342330/)
There is one little problem with that reasoning, though: NULL (zero) can actually be a valid pointer address. By default, the very bottom of the virtual address space (the "zero page," along with a few pages above it) is set to disallow all access as a way of catching null-pointer bugs (like the one described above) in both user and kernel space. But it is possible, using the mmap() system call, to put real memory at the bottom of the virtual address space. There are some valid use cases for this functionality, including running legacy binaries.
| | |
| |
| 3.53, Герберт Уэллс (?), 14:18, 30/10/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если бы мапирование в первые страницы действительно где-либо использовалось, то был бы приведён пример не tun драйвера, а этого софта. Мол, так и так, вот эти ребята написали аналог буст-шаред-мемори, для верности мапируем в ноль во всех процессах, использующих модуль.Это нет, и всем ясно почему: не было цепочки событий "ой что же это - не работает такой-то код! Давайте разберёмся почему" а была цепочка "ух ты! можно, оказывается, по нулевому адресу разместить данные! Но где бы мне это знание применить-то?".
| | |
| |
| 4.299, PereresusNeVlezaetBuggy (ok), 17:04, 01/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > Если бы мапирование в первые страницы действительно где-либо использовалось, то был бы
> приведён пример не tun драйвера, а этого софта. Мол, так и
> так, вот эти ребята написали аналог буст-шаред-мемори, для верности мапируем в
> ноль во всех процессах, использующих модуль.Это нет, и всем ясно почему:
> не было цепочки событий "ой что же это - не работает
> такой-то код! Давайте разберёмся почему" а была цепочка "ух ты! можно,
> оказывается, по нулевому адресу разместить данные! Но где бы мне это
> знание применить-то?".
Ещё не так давно (пока не началась эпопея с уязвимостями, эксплуатирующими именно разыменование нулевого указателя) оно использовалось, например, в Wine...
| | |
|
| 3.65, dq0s4y71 (ok), 14:46, 30/10/2013 [^] [^^] [^^^] [ответить]
| +10 +/– |
 Ну, написали бы тогда:
volatile struct tun_struct * tun = ...
volatile struct sock * sk = tun->sk;
Компилятор вовсе не обязан знать, что при каких-то экзотических условиях кривой код всё-таки работает. Но компилятору можно об этом сообщить :)
| | |
| |
| 4.217, pavlinux (ok), 14:52, 31/10/2013 [^] [^^] [^^^] [ответить]
| +3 +/– |
 volatile const struct tun_struct const __restrict * const __attribute__((const), nocommon, mode(pointer)) tun = ...
volatile const struct sock const __restrict * const __attribute__((const), nocommon, mode(pointer)) sk = tun->sk;
:D
| | |
| |
| 5.218, arisu (ok), 14:57, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > volatile const struct tun_struct const __restrict * const __attribute__((const), nocommon,
> mode(pointer)) tun = …
> volatile const struct sock const __restrict * const __attribute__((const), nocommon, mode(pointer))
> sk = tun->sk;
> :D
это будет покруче «Фауста» Гёте…
| | |
|
|
|
|
| |
| 2.240, Аноним (-), 16:13, 31/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> если нет ошибки в программе, значит ошибка в компиляторе..
Ошибка в стандарте языка.
| | |
|
| 1.6, BayaN (ok), 12:29, 30/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Приведены два примера неистового говнокода, в проблемах безопасности конечно виноват оптимизатор компилятора.
| | |
| |
| |
| 3.70, noname01 (?), 14:51, 30/10/2013 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> Комментор умнее исследователей и редакторов научных статей. Гений прям.
Нет, все ещё круче. Если учитывать "3471 пакете из 8575 пакетов, доступных в репозиториях Debian" то комментатор просто сверх человек какой-то
| | |
| 3.75, Аноним (-), 14:58, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
Чтобы подобным образом наезжать на комментатора, неплохо бы исследованиями заниматься и научные статьи писать, а не на постинг время тратить.
| | |
| |
| 4.103, Аноним (-), 16:51, 30/10/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Чтобы подобным образом наезжать на комментатора, неплохо бы исследованиями заниматься
> и научные статьи писать, а не на постинг время тратить.
Если комментатор пишет явную херню, проводить специальные исследования по данному вопросу - слегка оверкилл.
| | |
| |
| 5.181, Аноним (-), 23:13, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Если комментатор пишет явную херню, проводить специальные исследования по данному вопросу - слегка оверкилл.
Но можно по ссылке сходить и прочитать хотя бы первые буквы работы, которую "американские ученые" Си Вань и Николай Зельдович начали следующими словами:
This paper studies an emerging class of SOFTWARE BUGS called optimization-unstable code: code that is unexpectedly discarded by compiler optimizations due to UNDEFINED BEHAVIOR IN THE PROGRAM.
Т.е. они это называют багами в первой же фразе, и ни разу не утверждают, что проблема в компиляторах, а сразу говорят, что проблема - следствие неопределенного поведения в программе.
| | |
| |
| 6.233, Аноним (-), 15:56, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Т.е. они это называют багами в первой же фразе, и ни разу
> не утверждают, что проблема в компиляторах, а сразу говорят, что проблема
> - следствие неопределенного поведения в программе.
Оптимизация UB втихую - это, конечно, мудро и правильно. Вместо того, чтобы выдать предупреждение.
| | |
| |
| 7.243, arisu (ok), 16:26, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Оптимизация UB втихую - это, конечно, мудро и правильно. Вместо того, чтобы
> выдать предупреждение.
в данном случае не было никакой «оптимизации UB»: включение оптимизатора изначально подразумевает, что ему на вход подаётся корректная программа. потому что ни один компилятор сей ничего не гарантирует в случае, когда оптимизатору скормили мусор. по мере сил компиляторы стараются предупреждать, но полноценный ИИ ещё не написали, так что получается у них не всегда.
| | |
| 7.246, Аноним (-), 16:29, 31/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Оптимизация UB втихую - это, конечно, мудро и правильно. Вместо того, чтобы выдать предупреждение.
Предназначение компилятора - компилировать, т.е. преобразовать исходный текст программы в исполняемый код согласно описанию/стандарту языка. Компилятор не обязан быть телепатом и пытаться сравнивать то, что Вы делаете, с тем, что Вы на самом деле хотели сделать. Для таких задач как раз есть всевозможные анализаторы, включая описанный в новости. Всё просто - если Вам нужен анализ Вашего кода на всевозможные проблемы - используйте анализаторы.
Как ни странно, многие от компилятора ждут только компиляции, по возможности быстрой, и вовсе не хотели бы, чтобы он тратил время на размышления о том, что же имел в виду автор исходников.
| | |
|
| 6.336, IRASoldier (?), 12:11, 18/06/2018 [^] [^^] [^^^] [ответить]
| +/– | |
>"американские ученые"
Кавычки лишние. Работают и живут в США, значит американские. Что, бомбит?
| | |
|
|
|
| 3.85, BayaN (ok), 15:38, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
Нет, просто комментатор на стороне создателей компиляторов, а не говнокодеров. Поэтому если стандарт Си позволяет компилятору выкинуть говнокод, то пусть выкидывает.
Авторы же, не столь категоричны, поэтому решили немного разрядить войну компиляторы vs программисты, предоставив средства по обнаружению плохого кода. Это естественно позволит выводить красивые предупреждения и все будут счастливы. За это честь им и хвала.
>The main contributions of this paper are:
>• a new model for understanding unstable code,
>• a static checker for identifying unstable code, and
>• a detailed case study of unstable code in real systems. | | |
| 3.192, arisu (ok), 08:25, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Комментор умнее исследователей и редакторов научных статей. Гений прям.
в данном случае — умнее авторы компилятора. которые стандарты таки читали, в отличие от этих «исследователей».
| | |
| |
| 4.234, Аноним (-), 15:57, 31/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> в данном случае — умнее авторы компилятора. которые стандарты таки читали, в отличие от этих «исследователей».
Стандарт прочитать и обезьянка может. А вот корректно обрабатывать отклонения от стандарта (например, выдавать предупреждения) - это уже мозг нужен.
С чем, к сожалению, у авторов современных компиляторов проблемы.
| | |
| |
| 5.248, arisu (ok), 16:35, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Стандарт прочитать и обезьянка может. А вот корректно обрабатывать отклонения от стандарта
> (например, выдавать предупреждения) — это уже мозг нужен.
> С чем, к сожалению, у авторов современных компиляторов проблемы.
предлагаю тебе надрать им всем задницы и показать, как надо делать компиляторы. раз ты так уверен, что ты сможешь научить компилятор выдавать предупреждения лучше, чем те, что есть — сделай это! заодно и «скайнет» напишешь, думаю.
| | |
| |
| 6.258, Аноним (-), 17:00, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> раз ты так уверен, что ты сможешь научить компилятор выдавать предупреждения
Ага, для того чтобы это хорошо работало, правда, придется тезисы Тюринга опровергнуть. Но об этом он узнает немного попозже...
| | |
| |
| 7.260, arisu (ok), 17:52, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Ага, для того чтобы это хорошо работало, правда, придется тезисы Тюринга опровергнуть.
> Но об этом он узнает немного попозже…
не веришь ты в людей. это, может, гений среди нас, а ты его расхолаживаешь. он тебя послушает-послушает, сопьётся с горя, умрёт — и не будет у нас «скайнета».
| | |
| 7.268, Аноним (-), 18:51, 31/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> раз ты так уверен, что ты сможешь научить компилятор выдавать предупреждения
> Ага, для того чтобы это хорошо работало, правда, придется тезисы Тюринга опровергнуть.
Вас послушать, так для оптимизаций компилятор вообще должен собственным сознанием обладать.
А типичные случаи UB хорошо известны и разжеваны. С их отловом справился бы даже очень тyпой компилятор.
| | |
|
|
|
|
|
| 2.102, Аноним (-), 16:49, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Приведены два примера неистового гoвнокода
На сях гoвнокод, как правило, является наиболее простым и эффективным решением проблемы.
Так что его надо любить и лелеять, как священную корову. Особенно на уровне компилятора.
| | |
| |
| 3.193, arisu (ok), 08:27, 31/10/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> На сях гoвнокод, как правило, является наиболее простым и эффективным решением проблемы.
это просто потому, что у тебя мозг кроме говнокода ничего больше произвести не в состоянии. вот ты и считаешь, что это не у тебя в голове кю, а просто кю — такое решение всех проблем.
| | |
| |
| 4.232, Аноним (-), 15:54, 31/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> это просто потому, что у тебя мозг кроме гoвнокода ничего больше произвести не в состоянии.
Не только у меня. Сколько сишных программ не смотрел - никогда не видел, чтобы был не гoвнокод.
| | |
| |
| 5.239, Аноним (-), 16:13, 31/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Не только у меня. Сколько сишных программ не смотрел - никогда не видел, чтобы был не гoвнокод.
Поэтому сам я стараюсь на сях не писать. Благо, задачи не системные, и перл отлично справляется.
| | |
| |
| 6.257, Аноним (-), 16:58, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> и перл отлично справляется.
Жаль что на перле операционки не пишут, правда? :)
| | |
| |
| 7.265, Аноним (-), 18:46, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Жаль что на перле операционки не пишут, правда? :)
Когда-нибудь найдется один ценитель истинного юниксвея, а не фанат блобов, и вот тогда...
| | |
| 7.302, Аноним (-), 18:56, 01/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> и перл отлично справляется.
> Жаль что на перле операционки не пишут, правда? :)
Ага. Тока на Lua :(
| | |
|
|
| 5.249, arisu (ok), 16:37, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> это просто потому, что у тебя мозг кроме гoвнокода ничего больше произвести не в состоянии.
> Не только у меня. Сколько сишных программ не смотрел — никогда не
> видел, чтобы был не гoвнокод.
бедняга. плохо быть тобой.
| | |
| |
| 6.269, Аноним (-), 18:54, 31/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> бедняга. плохо быть тобой.
Не только мной.
> Более широкая проверка исходных текстов показала, что нестабильные блоки кода присутствуют в 3471 пакете из 8575 пакетов, доступных в репозиториях Debian.
| | |
| |
| 7.313, Аноним (-), 00:42, 02/11/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Не только мной.
FYI, баги встречаются не только в программах на си :).
| | |
|
|
| 5.256, Аноним (-), 16:58, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Сколько сишных программ не смотрел - никогда не видел, чтобы был не гoвнокод.
Я прямо удивляюсь даже - какой же операционкой вы тогда пользуетесь? И если они все плохие - ну вы нам покажете как их лучше писать, или как? :)
| | |
| |
| 6.266, Аноним (-), 18:47, 31/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Сколько сишных программ не смотрел - никогда не видел, чтобы был не гoвнокод.
> Я прямо удивляюсь даже - какой же операционкой вы тогда пользуетесь?
А я не перфекционист :)
| | |
| |
| 7.314, Аноним (-), 00:44, 02/11/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> А я не перфекционист :)
Более того, сажать баги можно на любом ЯП. Некоторые из них будут вести к проблемам безопасности. Вообще, умиляет наивное хомячковое хотение чтобы умный компьютер думал вместо глупого программиста сам. Если бы это было так просто - глупый программист вообще отправился бы подметать улицы.
| | |
|
|
|
|
|
| |
| 3.304, Аноним (-), 18:59, 01/11/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Константин Серебряный, залогиньтесь
А кто это? Герой повести А.Толстого?
| | |
|
|
| |
| 2.190, Led (ok), 04:11, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > Компиляторы стали слишком умными, началась игра кто кого...
Относительно. Потому как кодеры в среднем стали на порядок тупее.
| | |
| 2.194, arisu (ok), 08:27, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Компиляторы стали слишком умными
нет, это говнокодеры продолжают считать, что учить ПДД перед тем, как сесть за руль — излишество.
| | |
| |
| 3.236, Аноним (-), 16:07, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Компиляторы стали слишком умными
> нет, это гoвнокодеры продолжают считать, что учить ПДД перед тем, как сесть
> за руль — излишество.
Тупое следование ПДД чревато. Если бы пользующиеся преимуществом водители (при перестроении, на главной, при выезде с прилегающих) никогда не уступали тем, кто не имеет преимущества - пробки были бы раз в десять больше, чем сейчас.
| | |
| |
| 4.250, arisu (ok), 16:38, 31/10/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>> Компиляторы стали слишком умными
>> нет, это гoвнокодеры продолжают считать, что учить ПДД перед тем, как сесть
>> за руль — излишество.
> Тупое следование ПДД чревато.
так же, как и тупые автомобильные аналогии. каюсь, сам первый начал.
| | |
| |
| 5.267, Аноним (-), 18:49, 31/10/2013 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> каюсь, сам первый начал.
Профессиональный сишник может наступить на грабли даже на ровном месте :)
Сначала сам их напишет, потом наступит.
| | |
| |
| 6.315, Аноним (-), 00:46, 02/11/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Сначала сам их напишет, потом наступит.
А иные будут грести листья лопатой, как дeбилы. Потому что грабли видите ли вообще не предусмотрели, а сделать самому - обломно. Вот и приходится эмулировать их из того что есть...
| | |
|
|
|
|
|
| 1.8, BSA (?), 12:36, 30/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
А причем тут компиляторы? Вместо того, чтобы проверить len, проверяется выход указателя за пределы выделенной области. Если в стандарте языка указано, что результат операции переполнения не определен, то нет ничего криминального в том, что компиляторы этим пользуются. Другое дело, что могли бы выдавать предупреждение в этом случае.
Это косяки программистов.
| | |
| |
| 2.10, z (??), 12:58, 30/10/2013 [^] [^^] [^^^] [ответить]
| –4 +/– | |
>Вместо того, чтобы проверить len, проверяется выход указателя за пределы выделенной области.
А если этот len добавляется к buf в каждой итерации? Умник такой умник
| | |
| |
| 3.32, ананим (?), 13:41, 30/10/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
Покажите такой код, где нужно в цикле к указателю постоянно добавлять число и я скажу в каком месте и насколько он гoвнo.
| | |
| |
| 4.87, клоун Стаканчик (?), 15:43, 30/10/2013 [^] [^^] [^^^] [ответить]
| –3 +/– |
; копирование первого поля структуры
struct data
dd data1
dd data2
ends
@@:
movsd
add esi,4 ; <<<<
loop @b
; ACPI: таблица RSDT состоит из последовательно идущих структур разного размера, каждая из которых имеет стандартный заголовок
struct ACPI_HEADER
db size
ends
xor eax,eax
mov esi,[RSDT]
mov edi,[RSDT_TABLE_SIZE]
@@:
call parse_ACPI_table
lodsb
add esi,eax ; <<<<<
cmp edi,edi
jb @b
| | |
| |
| 5.92, ананим (?), 16:01, 30/10/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Хинт: Сабж (и данный трэд) о С... в крайнем случае о С++.
ПС: понятно что в ассемблере без готу и условных джампов (включая флаги переполния) никуда. Более того, скомпилённый из С/С++ (да из любого языка!) код ими просто напичкан, но... трэд про язык С/С++ и линейную зависемость его оптимизации от уровня быдлoкoда.
ППС: жалко что у индусов нет понятия быдлoкoд... они искренне не понимают за что их ругают.
Вот и к нам скоро покатятся. Будут нас учить программировать и как за 50'000 рупий работать сеньором-девелопером.
| | |
| |
| 6.97, клоун Стаканчик (?), 16:18, 30/10/2013 [^] [^^] [^^^] [ответить]
| –3 +/– | |
Пример 1:
// ACPI: таблица RSDT состоит из последовательно идущих структур разного размера, каждая из которых имеет стандартный заголовок
struct ACPI_HEADER
{
int size;
}
...
ACPI_HEADER *ptr;
...
while(ptr < rsdt_end)
{
parse_ACPI_table(ptr);
ptr += ptr.size; // <<<<<<<
}
Пример 2: в присланном файле каждая запись выровнена на N байт. Записи идут последовательно и имеют непостоянный размер. Напр. линии картинки имеют фиксированный размер и выровнены на 16 байт, записи в самописной файловой БД имеют переменный размер и выровнены на 4096, и т.д.
| | |
| |
| 7.104, ананим (?), 16:52, 30/10/2013 [^] [^^] [^^^] [ответить] | –2 +/– | 1 Ещё раз для упoрoтых , Об аспи речи не шло аспи кривое по-жизни даже созда... большой текст свёрнут, показать | | |
| |
| 8.114, z (??), 17:21, 30/10/2013 [^] [^^] [^^^] [ответить] | +1 +/– | Для употорых аспи лишь один из примеров, взять любые данные, упакованные в стру... текст свёрнут, показать | | |
| |
| |
| 10.131, ананим (?), 18:20, 30/10/2013 [^] [^^] [^^^] [ответить] | +/– | ззыж Вот и покажи где тут бегают по указателям, потенциально выходящим за предел... большой текст свёрнут, показать | | |
| |
| |
| |
| 13.153, Аноним (-), 20:15, 30/10/2013 [^] [^^] [^^^] [ответить] | +/– | Программа в юзерспейсе в общем случае понятия не имеет о том какая там память Э... большой текст свёрнут, показать | | |
| |
| |
| 15.183, Аноним (-), 23:43, 30/10/2013 [^] [^^] [^^^] [ответить] | +1 +/– | Кажется, Линус тоже плавает - он почему-то не совсем согласен насчет элегантно... большой текст свёрнут, показать | | |
| 15.226, Аноним (-), 15:43, 31/10/2013 [^] [^^] [^^^] [ответить] | +/– | Как-то так переполнения буферов и случаются Что, ты совсем не в состоянии осозн... большой текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
|
|
| 4.164, Филипп Филиппович (ok), 21:07, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Ну-ну, расскажите миру, в каком месте это верно про цикл, итерирующий массив структур, инкрементируя указатель.
| | |
|
|
| 2.12, Аноним (-), 13:00, 30/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Это косяки ЯЗЫКА.
Стандарт С позволяет не только себе ногу отстрелить, но и покалечить окружающих.
| | |
| |
| 3.13, Аноним (-), 13:07, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
Аноним такой "знаток", что не в силах отличить недостатки от достоинств?
| | |
| |
| 4.35, Аноним (-), 13:44, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Аноним такой "знаток", что не в силах отличить недостатки от достоинств?
А, так возможность переполнения - это на самом деле достоинство?
Как и создаваемая им дыра в безопасности?
| | |
| |
| 5.38, Аноним (-), 13:46, 30/10/2013 [^] [^^] [^^^] [ответить]
| +3 +/– | |
>Как и создаваемая им дыра в безопасности?
Для кого дыра, а для кого и мать родна :)
| | |
| |
| 6.305, Аноним (-), 19:00, 01/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
>>Как и создаваемая им дыра в безопасности?
> Для кого дыра, а для кого и мать родна :)
Намек на АНБ?
| | |
|
| 5.64, Аноним (-), 14:46, 30/10/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
да. Это следствие ручного управление памятью. Такое же как низкое ее потребление, например.
| | |
| |
| 6.238, Аноним (-), 16:11, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> да. Это следствие ручного управление памятью.
Возможность целочисленного переполнения - это _не_ следствие ручного управления памятью.
| | |
|
| 5.154, Аноним (-), 20:18, 30/10/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> А, так возможность переполнения - это на самом деле достоинство?
Это всего лишь то как по факту работают процессоры в массе своей. Обойти сие можно, но сложно и получится тормозная и многоэтажная этажерка из кода вместо 1 простой и быстрой команды проца. Си таки не язык для идиoтов. Для таких есть JS, питон и прочие, где пинками в стойло загоняют. А на си априори можно делать небезопасные вещи. Что делает его удобным выбором для системного программирования. Потому что записать число 0x20 по адресу 0x100500 на сях совершенно не проблема. А вот на других ЯП это уже потребует нифиговых костылей...
| | |
| |
| 6.166, chinarulezzz (ok), 21:15, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
 >т. А на си априори можно делать небезопасные вещи. Что делает его удобным выбором для системного программирования. Потому что записать число 0x20 по адресу 0x100500 на сях совершенно не проблема. А вот на других ЯП это уже потребует нифиговых костылей...
пффф)) modula-2(3), oberon.
| | |
| |
| 7.229, Аноним (-), 15:46, 31/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> пффф)) modula-2(3), oberon.
Я и смотрю - то-то все низкоуровневые и системные дела на них написаны. Ядра, бутлоадеры, фирмвары эмбедовочные, угу. Ну, пользуй наздоровье, мне что, жалко чтоли? А в упомянуых вещах столько методов прострела пяток что упомянутый - вообще так, мелочи жизни.
| | |
| |
| 8.242, arisu (ok), 16:23, 31/10/2013 [^] [^^] [^^^] [ответить] | +/– | не тупи, пожалуйста надо ли в очередной раз пояснять, что популярность не обяза... текст свёрнут, показать | | |
| |
| |
| |
| |
| 12.327, arisu (ok), 11:04, 02/11/2013 [^] [^^] [^^^] [ответить] | +2 +/– | синтаксис отстойный, конечно, я не спорю но гвидобейсик не потому гвидобейсик ... текст свёрнут, показать | | |
|
|
|
| 9.319, Аноним (-), 09:52, 02/11/2013 [^] [^^] [^^^] [ответить] | +1 +/– | Теоретически это может быть и так Практически - по логике вещей получается что ... большой текст свёрнут, показать | | |
|
|
|
|
|
| 4.199, arisu (ok), 08:37, 31/10/2013 [^] [^^] [^^^] [ответить] | +/– | вот конктретно 171 неопределённое поведение при целочисленном переполнении 18... большой текст свёрнут, показать | | |
| |
| 5.230, Аноним (-), 15:48, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> ведут себя вполне определённо, и именно это поведение имело смысл стандартизировать.
Тем более что процы умеют выставлять carry-флаг в массе своей на уровне железа, блин...
| | |
| 5.235, Аноним (-), 16:04, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> но стандарты пишут идиoты^w сферические академики в вакууме. и у них выходит
> стандарт, у которого, на минуточку, есть понятие «поведение не определено».
> это, пардон, не стандарт, а кусок туалетной бумаги. поведение в стандарте
> *должно* быть определено. или определённый результат, или ошибка. а если оно
> «не определено» — это значит, что стандарт писали идиoты, больше заботящиеся
> об удобстве машины, а не человека.
Ваши рассуждения очень напоминают поттеринга: "наше любимое ядро linux поддерживает эту функциональность, а проблемы тех, у кого ядра не ее не поддерживают, нас не беспокоят".
Если язык позиционируется как _портабельный_ - он должен опираться на общий доступный минимум возможностей _всех_ целевых платформ, а не "большинства".
| | |
| |
| 6.253, arisu (ok), 16:48, 31/10/2013 [^] [^^] [^^^] [ответить] | +/– | любую идею можно довести до абсурда 8212 и тогда получится полная фигня в да... большой текст свёрнут, показать | | |
| |
| 7.307, Аноним (-), 19:07, 01/11/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> кратко: если *большинство* процессоров уже кучу лет работают неким определённым образом, и это *настолько* привычно, что программисты подчас забывают об UB, полагаясь на такое поведение — то следует починить стандарт, прописав туда именно такое поведение. а остальные архитектуры пусть эмулируют.
Ну вот поццеринг примерно так же и рассуждал. Кому надо - пусть эмулируют.
| | |
|
|
|
|
| 3.14, Аноним (-), 13:09, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Это косяки ЯЗЫКА.
> Стандарт С позволяет не только себе ногу отстрелить, но и покалечить окружающих.
Могу посоветовать тебе и твоим функциональным аналогам писать на Visual Basic.
| | |
| |
| 4.36, Аноним (-), 13:44, 30/10/2013 [^] [^^] [^^^] [ответить]
| –3 +/– |
>> Это косяки ЯЗЫКА.
>> Стандарт С позволяет не только себе ногу отстрелить, но и покалечить окружающих.
> Могу посоветовать тебе и твоим функциональным аналогам писать на Visual Basic.
Советы свои знаешь куда засунь?
| | |
| |
| 5.98, Аноним (-), 16:25, 30/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Советы свои знаешь куда засунь?
Да ладно. Барсик - это тайная эротическая мечта любого сишника)
| | |
| |
| 6.156, Аноним (-), 20:19, 30/10/2013 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Да ладно. Барсик - это тайная эротическая мечта любого сишника)
Вы явно путаете сишников и питонистов. Тут один типаж даже название ему придумал - гвидобэйсик.
| | |
| |
| 7.241, Аноним (-), 16:14, 31/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Да ладно. Барсик - это тайная эротическая мечта любого сишника)
> Вы явно путаете сишников и питонистов. Тут один типаж даже название ему
> придумал - гвидобэйсик.
Ну так правильно. Питонисты имеют то, о чем сишники только мечтают.
| | |
| |
| 8.245, arisu (ok), 16:29, 31/10/2013 [^] [^^] [^^^] [ответить] | +2 +/– | честно не мечтаем мы о том, чтобы смена количества пробелов в начале строки изм... текст свёрнут, показать | | |
| 8.320, Аноним (-), 09:57, 02/11/2013 [^] [^^] [^^^] [ответить] | +1 +/– | Тормозилово, с синтаксисом где дeбила пинками заставляют форматировать гoвнокод ... текст свёрнут, показать | | |
|
|
|
|
|
| 3.26, Филипп Филиппович (ok), 13:37, 30/10/2013 [^] [^^] [^^^] [ответить]
| +8 +/– |
> Это косяки ЯЗЫКА.
> Стандарт С позволяет не только себе ногу отстрелить, но и покалечить окружающих.
Стандарт определяет язык, который хорошо переносим и одновременно эффективен. Результат переполнения сильно зависит от аппаратной платформы, поэтому язык НЕ МОЖЕТ регламентировать результат переполнения. Если он регламентирует, к каждой операции с арифметикой указателей придётся генерировать код проверки переполнения и приведения результатов к заданному стандартом виду. Это убьёт эффективность. Косяка в этом никакого нет, очень логичная особенность дизайна, если понимать, что язык изначально позиционировался как переносимая альтернатива ассемблеру.
Другой вопрос, что сейчас уже не очень естественно писать почти всё прикладное ПО на таком языке. Но традиция пока жива. :-)
| | |
| |
| 4.44, тоже Аноним (ok), 13:57, 30/10/2013 [^] [^^] [^^^] [ответить]
| –3 +/– |
 Вообще-то "почти все прикладное ПО" пишут не на Сях, а скорее на Крестах. В которых есть Стандартная Библиотека, при правильном применении избавляющая от необходимости маяться с указателями вовсе.
Си используются не в прикладном, а в системном ПО, драйверах и кодеках, где над бинарными данными может вообще не быть никакой абстракции и где действительно нужно иметь ничем не ограниченный доступ к памяти.
| | |
| |
| 5.47, Филипп Филиппович (ok), 14:12, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Вообще-то "почти все прикладное ПО" пишут не на Сях, а скорее на
> Крестах.
К сожалению, в крестах наследие Си очень сильно. В теории -- да, стандартная библиотека и всё такое. А на практике... Для начала половина пользователей пишет на нём так, как будто это Си с дополнительными фичами. Я не уверен, что при переходе от Си к "Крестам" ошибок стало меньше, вот в чём беда.
| | |
| |
| 6.52, тоже Аноним (ok), 14:17, 30/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Это скорее legacy-проблемы. За последнее время по всему интернету развешаны статьи-предупреждения "Не пользуйтесь Сями в Крестах, есть смарт-пойнтеры и контейнеры, которых вам хватит за глаза! А если не хватает, почитайте внимательно документацию к STL".
| | |
| |
| 7.57, Филипп Филиппович (ok), 14:30, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Это скорее legacy-проблемы. За последнее время по всему интернету развешаны статьи-предупреждения
> "Не пользуйтесь Сями в Крестах, есть смарт-пойнтеры и контейнеры, которых вам
> хватит за глаза! А если не хватает, почитайте внимательно документацию к
> STL".
Это-то да. Но ведь оно же лет без малого пятнадцать так. Некоторые сдвиги есть, но большинство кода откроешь -- прослезишься, те же самые родные поделия типа примеров из статьи. Причём иногда осмысленные, но чаще не очень (то есть всё можно было сделать именно на плюсах, а не на си с крестами).
| | |
| |
| |
| |
| 10.79, ананим (?), 15:12, 30/10/2013 [^] [^^] [^^^] [ответить] | –2 +/– | Потому что не уверены в своих силах Я предпочитаю рассчитывать на себя больше, ... текст свёрнут, показать | | |
| |
| |
| |
| |
| |
| Часть нити удалена модератором |
|
|
|
|
|
|
|
|
|
| 6.200, arisu (ok), 08:40, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Для начала половина
> пользователей пишет на нём так, как будто это Си с дополнительными
> фичами.
единственный нормальный способ использовать плюсовое недоразумение.
| | |
| |
| 7.224, ананим (?), 15:39, 31/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Бред. Нормальное плюсовое использование — это шаблоны.
Вот это действительно мощь и красота языка.
С другой стороны можно использовать на уровне тех же делфей.
Как пример Qt, по уровню вхождения, сложности и стройности один в один практически.
Главное не злоупотреблять различными техниками в перемежку.
В общем для юзер-спейса лучше ещё никто ничего не придумал.
| | |
| |
| 8.228, arisu (ok), 15:44, 31/10/2013 [^] [^^] [^^^] [ответить] | +1 +/– | это мощь и красота костылей ещё и на уровне синтаксиса костыльных вообще, наст... текст свёрнут, показать | | |
| |
| 9.252, ананим (?), 16:46, 31/10/2013 [^] [^^] [^^^] [ответить] | –1 +/– | Ха Шаблоны существовали уже тогда, когда маркетолухи ещё и слово то такое, гене... текст свёрнут, показать | | |
| |
| 10.329, Vkni (ok), 20:47, 02/11/2013 [^] [^^] [^^^] [ответить] | +1 +/– |  Я, честно говоря, тоже в своё время восхищался шаблонами, пока не узнал, что выв... текст свёрнут, показать | | |
| 10.330, arisu (ok), 21:17, 02/11/2013 [^] [^^] [^^^] [ответить] | +1 +/– | угу-угу правда, в Аде их придумали в районе 1978-го года, а первый cfront ни о ... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 2.16, Xasd (ok), 13:14, 30/10/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Если в стандарте языка указано, что результат операции переполнения не определен, то нет ничего криминального в том, что компиляторы этим пользуются.
верно..
какого чёрта -- программист такой "умный" что уже ПОСЛЕ того как СОВЕРШИТ переполнение проверяет "а не случилось ли переполнение?"..
всё правильно думает компилятор -- "программист уже совершил сложение, значит программист уверен в том что переполнения невозможно, а следовательно я выкину лишние проверки...".
нет чтобы проверить каждое из гипотетических слогаемых -- ПЕРЕД всякими операциями..
#include <climits>
... ...
if (buf >= INT_MAX/2 || len >= INT_MAX/2) {
return; // overflow
}
... ...
| | |
| |
| 3.18, Аноним (-), 13:23, 30/10/2013 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> buf >= INT_MAX/2 || len >= INT_MAX/2
По-моему, это еще более страшный быдлoкод.
| | |
| |
| 4.21, Xasd (ok), 13:28, 30/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> buf >= INT_MAX/2 || len >= INT_MAX/2
> По-моему, это еще более страшный быдлoкод.
где ты тут код увидил? тут лишь одно выражение, которое проверяет что каждое из слагаемых меньше чем половина от максимального значения обычного целочесленного типа..
| | |
| |
| 5.29, Аноним (-), 13:40, 30/10/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
> где ты тут код увидил? тут лишь одно выражение, которое проверяет что
> каждое из слагаемых меньше чем половина от максимального значения обычного целочесленного
> типа..
Да-да, скажи ещё что кот по клавиатуре прошёл и оно само напечаталось.
Ты показал чудовищную некомпетентность, что, впрочем, вполне ожидаемо, ибо ты её показываешь в каждом посте. Плюс хамская манера общения и неадекватная реакция на критику, догадки о твоём возрасте в очередной раз подтвердились.
| | |
| |
| 6.31, Аноним (-), 13:41, 30/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Плюс хамская манера общения
Хамская манера общения тут только у тебя (хотя я и использовал слово "быдлoкод" парой сообщений выше).
| | |
| |
| 7.37, Аноним (-), 13:45, 30/10/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Хамская манера общения тут только у тебя (хотя я и использовал слово
> "быдлoкод" парой сообщений выше).
Залогинься, Xasd. Щас прям, поверю что пришёл компетентный Аноним тебя защищать.
| | |
|
|
|
|
| 3.20, Аноним (-), 13:25, 30/10/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
За такой код надо тебе по пальцам молотком для мяса пройтись.
| | |
| |
| 4.23, Xasd (ok), 13:28, 30/10/2013 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> За такой код надо тебе по пальцам молотком для мяса пройтись.
ну напиши как надо. балобол.
так как ты писать ни чего не будешь -- то разговор я думаю на этом будет закрыт.
> молотком для мяса
тоже мне, любитель мяса..
жиром заплыл весь.. гуру элегантного кода на сиплюсплюс.. тфу, блин..
| | |
| |
| 5.25, Аноним (-), 13:35, 30/10/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Лол, как тебя зацепило. Нет уж - давай ты свои ошибки сам исправишь. Подскажу: во-первых, buf это указатель, а указатель с INT ничего общего не имеет. Во-вторых, указатель может располагаться в любой половине адресного пространства (в userspace будет в одной, в ядре - в другой), так что в одном случае твой код гарантированно не будет работать.
| | |
| |
| 6.33, Xasd (ok), 13:43, 30/10/2013 [^] [^^] [^^^] [ответить]
| –4 +/– | |
> buf это указатель
да -- я привёл код который просто проверяет переполнение при сложении.
совершенно нет смысла это использовать для случая с указателями.
(и вообще я считаю что нет смысла складывать указатели и работать с указателями -- как с целыми числами)
вот именно в этом смысле я принимаю критику.
| | |
| |
| 7.41, Аноним (-), 13:49, 30/10/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
Оправдываться уже поздно, молодой человек. С вами всё понятно.
| | |
| |
| 8.45, Xasd (ok), 13:57, 30/10/2013 [^] [^^] [^^^] [ответить] | –3 +/– | ну слово не воробей если уж я написал свою точку зрения -- назад взять слова не... текст свёрнут, показать | | |
|
|
| 6.69, ананим (?), 14:51, 30/10/2013 [^] [^^] [^^^] [ответить] | +/– | Именно что ЛОЛ Обозвал человека, докажи что заслуженно А пока только эти эпите... большой текст свёрнут, показать | | |
| |
| 7.78, Xasd (ok), 15:10, 30/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
да да, разумеется ''(ULONG_MAX - buf) > len'' здесь конечно явно уместнее) .. говоря про указатели -- точно уж не то что я привёл выше :-D
кстате мы тут исходим из того что размер size_t и long -- одинаковые... ведь не существует константы SIZE_T_MAX .. верно?
| | |
|
|
|
|
| |
| 4.39, Xasd (ok), 13:47, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> слогаемых
> По русскому у тебя то-же что и по информатике?
нет, по русскому у меня была почти двойка. а почему спрашиваешь?
может про физкультуру ещё интересно узнать? :-)
по физкультуре было обычно 4
| | |
| |
| 5.46, тоже Аноним (ok), 14:03, 30/10/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
А информатики еще не было вовсе, мы поняли.
Бросьте позориться. Вы написали безграмотное программистское решение с безграмотными русскими комментариями, да еще и раздуваете личностный срач.
Увы, "никогда не выдается второго случая создать первое впечатление".
| | |
| |
| 6.49, Xasd (ok), 14:12, 30/10/2013 [^] [^^] [^^^] [ответить] | –2 +/– | была у нас даже были там в классе -- немножко компьютеров но при чём тут ... большой текст свёрнут, показать | | |
| |
| 7.55, тоже Аноним (ok), 14:22, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
То, что вы невнимательны, было заметно и до этого комментария.
Работать с числами, большими половины максимума, вы тоже не видите смысла?
| | |
| |
| 8.60, Xasd (ok), 14:40, 30/10/2013 [^] [^^] [^^^] [ответить] | –2 +/– | да, конечно а в некоторых случаях -- я даже не вижу смысла работать с числами к... текст свёрнут, показать | | |
| |
| |
| 10.331, Xasd (ok), 00:50, 03/11/2013 [^] [^^] [^^^] [ответить] | –1 +/– | с чего ты взял что такого не случалось как раз такое бывало - всё равно не... текст свёрнут, показать | | |
|
|
|
| 7.202, arisu (ok), 08:49, 31/10/2013 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> опазорь как-нибудь меня совсем уж!
зачем трудиться, если ты сам отлично справляешься с задачей «опазоривания»? главное — дать тебе возможность писать, и ты сам себя так обгадишь… мы всем опеннетом за месяц не сможем повторить.
| | |
|
|
|
|
| 3.77, ... (?), 15:03, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
Подобные проверки перед каждой арифметической операцией негативно повлияют как на производительность так и на читаемость кода.
Да и писать такой код, держа в голове кто unsigned, кто long, а кто вообще double и какую проверку в связи с этим нужно влепить, - не особо комфортно.
| | |
| |
| 4.99, ананим (?), 16:25, 30/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
А для этого есть венгерская нотация и тд.
Опять же, имеет смысл для глобальных (или в нэймспейсах) переменных.
Для локальных переменных избяточно.
| | |
| |
| 5.203, arisu (ok), 08:56, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> А для этого есть венгерская нотация
за такое применение венгерской нотации надо бить бамбуковой палкой по пяткам, отбирать клавиатуру и вручать метлу.
использовать венгерскую нотацию следует для логических групп, а не для костыльного обозначения типов.
cntItems — нормально, если в проекте принято, что «cnt» — это префикс для обозначения счётчика.
dwItemCount — ненормально, что бы там в проекте ни принимали. привет, проблемы с портируемостью, например: «по средам и субботам dw обозначает два байта, по четвергам — четыре, а в пятницу бывает восемь, если это чётный день года.»
| | |
| |
| 6.214, ананим (?), 13:06, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
>например: «по средам и субботам dw обозначает
а не нужно выдумывать левые обозначения для стандартных типов.
int тоже меняется, но если переменная имеет тип int, то она имеет (или он её) постфактум.
либо определяйте этот тип также, либо не используйте такие обозначения.
а то ваша венгерская нотация получается с явно выраженным албанским акцентом.
зыж
и вот как раз за такое точно нужно и палочками по мягкому месту, и в угол.
| | |
|
|
|
| 3.201, arisu (ok), 08:46, 31/10/2013 [^] [^^] [^^^] [ответить] | +1 +/– | прикинь, процессор тоже делает именно так сюрпрайз, да а то, что си заставляет... большой текст свёрнут, показать | | |
| |
| 4.321, Аноним (-), 10:04, 02/11/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> прикинь, процессор тоже делает именно так. сюрпрайз, да?
Ну там проблема в том что на ширину регистров завязано, тогда как целочисленные типы совсем не обязаны 1 в 1 укладываться в регистры. Другое дело что все-равно же математику на регистрах "не той" ширины делают, а тут в половине случаев еще и железом подпереть можно было.
| | |
|
|
|
| 1.9, Аноним (-), 12:36, 30/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
вообще забавно:
сначала обратиться к структуре по указателю (*sk = tun->sk), а уже затем проверить указатель на NULL
| | |
| |
| 2.28, Crazy Alex (ok), 13:39, 30/10/2013 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Да уж, возмущаться таким кодом - умильно.
С первым примером, конечно, надо ворнинги бы выдавать или статикой проверять, но косяком компилятора это я бы не называл. Тем более, что проблема широко известна, как и решение - "if (buf_end > buf && buf_end - buf > len)". Допустим, в писании бинарного поиска практически всегда обращают внимание на то, то надо не (a+b)/2 писать, а (a-b)/2 - именно из-за возможного переполнения.
| | |
| |
| 3.56, dq0s4y71 (ok), 14:26, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
Зачем так сложно? :) Вот то, что имели ввиду авторы, но не осилили реализовать:
if ((intptr_t)buf + len < buf)
| | |
| |
| 4.204, arisu (ok), 08:57, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Зачем так сложно? :) Вот то, что имели ввиду авторы, но не
> осилили реализовать: if ((intptr_t)buf + len < buf)
беда в том, что значение этого выражения всё равно не определено, если случилось переполнение. так что этот код точно такой же бессмысленный, как и код из новости.
| | |
|
|
|
| 1.22, Филипп Филиппович (ok), 13:28, 30/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +9 +/– | |
Строго говоря, код в примерах не очень корректный. Увы, подобные перлы действительно перестают работать в результате деятельности оптимизатора, но это проблема кода, а не оптимизатора.
Полукорректная проверка переполнения при арифметике с указателями. Да, проверка переполнения, конечно, хорошая вещь, но ТАК это не надо делать. Поведение этого кода при переполнении неизвестно. Соответственно, это код под одну конкретную платформу, включая в понятие платформы и компилятор. Под то окружение, где работает так, как рассчитывал автор кода. И вполне естественно, что с развитием компилятора и появлением в нём более серьёзных оптимизаций ситуация изменилась. Код перестал работать так, как работал. Увы и ах. Ну так просто писать это надо подумавши. Посчитать, например, длину буфера вычитанием указателей и проверить, что индекс в диапазоне. А не заниматься не переносимым сложением с расчётом на переполнение, результат которого неопределён.
Ну и в переводе ошибка. Это не tun->sk не может быть нулевым, это tun не может быть нулевым. Кстати, в этом примере трудно не согласиться с оптимизатором! Если строкой выше идёт доступ к члену структуры, то указатель просто не имеет права быть нулевым. Проверять надо до доступа. Глючный код -- неопределённый результат, в чём удивление? Тот, кто этот код писал, видел за кодом арифметику с указателями на уровне ассемблерных команд. Это ценное умение. Но одновременно -- отвратительная привычка, если сопровождается тем, что программист рассчитывает на определённую низкоуровневую реализацию. Так он просто не сможет писать переносимый код.
Рациональное зерно, правда, в том, что кривоватый код, который ранее работал безупречно, может перестать это делать с включением оптимизации или заменой версии компилятора. Но ведь это ожидаемо и очевидно, нет?
| | |
| |
| 2.48, тоже Аноним (ok), 14:12, 30/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если позволите, вопрос от не читавшего стандарт.
А что, в С разыменование указателя не сопровождается проверкой на NULL?
Что по ассемблерным понятиям это разыменование - это просто прибавление к указателю смещения члена структуры, это понятно. Но разве эта строчка при исполнении не должна вызвать сегфолт в любом случае?
| | |
| |
| 3.61, Аноним (61), 14:40, 30/10/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > А что, в С разыменование указателя не сопровождается проверкой на NULL?
Еще чего не хватало.
| | |
| |
| 4.67, Аноним (61), 14:49, 30/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> И, кстати, что бинарно представляет собой этот нулевой указатель, иди разбери -- где как.
На любой вменяемой платформе это 0.
| | |
| |
| 5.76, Филипп Филиппович (ok), 15:01, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> На любой вменяемой платформе это 0.
Э, не спешите. Если в плоской модели, то наверное. Я другого ещё не видел, во всяком случае. Хотя никто этого не обещает, наверное, так будет. А вот если указатель включает в себя селектор сегмента и смещение, то каким будет этот селектор -- иди разбери. Возможно, каким-то таким, чтобы любая операция падала, не факт, что нулевым. Но это отдаётся на откуп железке-ОС-компилятору.
| | |
| |
| |
| 7.128, Филипп Филиппович (ok), 17:59, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
Ну я же говорил не о том, что оно сравнивается с нулём на C. Я говорил именно о том, что там бинарно, выше же так и написано.
| | |
| 7.206, arisu (ok), 09:03, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Вообще-то, на любой платформе это 0. Внутреннее представление значения не имеет. http://c-faq.com/null/ptrtest.html
тут нюанс: NULL — это всегда 0, и всегда обозначает «негодный указатель». но обратное неверно: «негодный указатель» может и не быть NULL'ом (например, указывать на область памяти, которой нет).
| | |
|
|
|
| 4.71, тоже Аноним (ok), 14:54, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
Да, пардон, это я напутал. Никаких проверок в самом коде, конечно. Это система выдаст сегфолт, но, насколько я понимаю, только в случае попытки записи по этому адресу.
А так - получается вполне валидный код, который работает с началом памяти как с read-only структурой. На чтение она вполне может быть доступна.
Тогда непонятна как раз логика оптимизатора - с чего это он считает, что разыменованный указатель не может быть NULL, если на практике - может? Стандарт запрещает такую практику? Ну, так "PDF - это не то, что записано в спецификации, а то, что читает Adobe Reader" ;)
| | |
| |
| 5.72, Аноним (61), 14:55, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Да, пардон, это я напутал. Никаких проверок в самом коде, конечно. Это
> система выдаст сегфолт, но, насколько я понимаю, только в случае попытки
> записи по этому адресу.
> А так - получается вполне валидный код, который работает с началом памяти
> как с read-only структурой. На чтение она вполне может быть доступна.
Разумеется это не так.
| | |
| 5.74, Филипп Филиппович (ok), 14:58, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
Нет, всё не так. :-) Очень много где будет защита и от чтения.
Стандарт такую практику, конечно, запрещает. Вернее, он ничего не запрещает, но честно говорит, что результат вам может не понравиться. Это и есть "результат неопределён", к слову. :-)
Результат неопределён = "это в разных реализациях может быть сделано по-разному, не рассчитывайте ни на что".
| | |
| 5.107, Crazy Alex (ok), 17:05, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
На каком-нибудь эмбеде запись по нулевому адресу может быть абсолютно корректной. На AVR том же.
| | |
| |
| 6.127, dq0s4y71 (ok), 17:56, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
Такая запись, возможно, не вызовет исключения, но это не значит, что она будет корректной :)
В бытность МС-ДОСа, помнится, в борландовских рантаймах в начале сегмента данных была специальная область с контрольной суммой, которая пересчитывалась на выходе, и если ты писал что-то по нулевому указателю, тебе на выходе на консоль выдавалось предупреждение :)
| | |
| |
| 7.135, Crazy Alex (ok), 18:25, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
На AVR по нулевому адресу находится регистр R0. Читать/писать его таким образом абсолютно корректно.
| | |
| 7.146, Филипп Филиппович (ok), 19:24, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
Это к вопросу про то, какой указатель. Там было несколько моделей памяти, в том числе и такие, в которых все указатели были дальние (сегмент+смещение). И нулевой адрес в дальнем указателе указывал на начало таблицы прерываний.
| | |
|
|
|
|
| 3.205, arisu (ok), 09:00, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> А что, в С разыменование указателя не сопровождается проверкой на NULL?
нет. этого делать нельзя, но по рукам никто не ударит, и код проверки тоже не вставят. точнее, по стандарту — не обязаны вставлять, это может быть дополнительной опцией компилятора. а может и не быть.
> разве эта строчка при исполнении не должна вызвать сегфолт в любом случае?
нет. более того, и не везде вызовет. в m$-dos, например, не вызовет. или в системе, где нет MMU и аппаратной защиты страниц.
| | |
|
|
| 1.24, Tav (ok), 13:32, 30/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
 В приведенных примерах компилятор следует стандарту, а программист предполагает определенное поведение в случаях, для которых оно не определено. Это не проблема компилятора.
| | |
| |
| 2.27, Филипп Филиппович (ok), 13:39, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> В приведенных примерах компилятор следует стандарту, а программист предполагает определенное
> поведение в случаях, для которых оно не определено. Это не проблема
> компилятора.
Именно так. Но, возможно, проблема пользователя, который получил некорретно работающий код там, где раньше был корректный, просто обновлением версии компилятора. А так -- да, кривой код -- кривой результат.
| | |
|
| 1.42, Андерй (?), 13:54, 30/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Интересно, какие ошибки компилятора нужны АНБ, что используется именно определённая старая версия для TrueCrypt?...
| | |
| 1.54, dq0s4y71 (ok), 14:19, 30/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
Как здесь справедливо заметили, это - косяки программистов. В первом примере, если вы ожидаете переполнения (т.е. перехода в область отрицательных значений), то вы должны и проверять его КОРРЕКТНО, т.е.:
if ((intptr_t)buf + len < buf)
Этот код работает как надо при любой оптимизации, можете проверить.
Второй пример вообще странный. Если tun == NULL, то ваша программа упадёт ещё до того, как она достигнет оптимизируемого участка. Обвинять оптимизацию в том, что она неправильно компилит и без того кривую программу - это, конечно, сильно...
| | |
| |
| 2.123, клоун Стаканчик (?), 17:40, 30/10/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> if ((intptr_t)buf + len < buf)
Если len объявлена беззнаковым числом, то buf+len<buf ложно при любых значениях buf и len и проверка может быть сочтена избыточной.
Второй пример "упадёт" только если адрес 0000:0000 недоступен для чтения. Во многих ОС это так, но считать это аксиомой и закладывать в стандарты ЯП или в компилятор нельзя. Да, логичнее было бы изменить порядок следования операторов, но только это не делает код однозначно неправильным. Для сравнения: "c=a+b; if(!a)return;"
| | |
| |
| 3.132, dq0s4y71 (ok), 18:23, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Если len объявлена беззнаковым числом, то buf+len<buf ложно при любых значениях buf
> и len и проверка может быть сочтена избыточной.
Почему это? Сравниваются ведь указатели, а не целые, поэтому целое будут преобразовано в указатель, а не наоборот.
> Для сравнения: "c=a+b; if(!a)return;"
Не совсем корректное сравнение. У этого кода нет побочных эффектов, в отличие от. Я бы предложил такое сравнение:
(*funcptr)();
if (!funcptr) ...
Тоже "корректно", но результат в большинстве случаев будет неожиданным :)
| | |
| |
| 4.137, клоун Стаканчик (?), 18:43, 30/10/2013 [^] [^^] [^^^] [ответить]
| –2 +/– | |
Почему это? Сравниваются ведь указатели, а не целые, поэтому целое будут преобразовано в указатель, а не наоборот.
buf + len >= buf. Всегда для беззнакового len. Согласны? Преобразование типа данных - фиктивная процедура, предназначенная для контроля типов на уровне ЯП, которая не попадает (за редкими исключениями, напр. числа с плавающей точкой хранятся в FPU, а целые числа в регистрах общего назначения) в бинарный код.
> Не совсем корректное сравнение
Сравнение корректно в том плане, что в обоих случаях можно изменить порядок следования операторов, но нельзя убирать условие.
| | |
| |
| 5.143, Ordu (ok), 19:06, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > buf + len >= buf. Всегда для беззнакового len. Согласны?
Нет. Пример для 32-х битной платформы: buf=(void*) 0xffffffff; len=1
| | |
| 5.144, ананим (?), 19:06, 30/10/2013 [^] [^^] [^^^] [ответить]
| +3 +/– |
Проводить сравнение методом «а давайте попробуем вызвать переполнение?» — идиoтизм.
Вы ещ на ноль делите, чтобы проверить, был там 0 или нет.
Вот корректная проверка (ULONG_MAX - buf) > len. И оптимизатор тоже идиoтизмoм её не посчитает. (или SIZE_MAX для size_t, или >= вместо >. Тут уж хозяин барин)
| | |
| 5.150, Аноним (-), 19:55, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> buf + len >= buf. Всегда для беззнакового len. Согласны?
Вот ты и показал что ты болванчик. Как ты думаешь, что будет если к 32-битному uint32 0xfffffffe прибавить uint32 0x3? Ничего что оно врапнется по 32-битной границе? В общем твоими программами я бы пользоваться не стал - ты самых основ программирования не знаешь.
| | |
| |
| 6.159, Аноним (-), 20:27, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> buf + len >= buf. Всегда для беззнакового len. Согласны?
> Вот ты и показал что ты болванчик. Как ты думаешь,
Так думает не он, разработчики компиляторов.
| | |
| |
| 7.167, ананим (?), 21:21, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
Неа. Так думаешь ты и ахтур этого гoвнoкoда.
А компилятор думает а) С детишкам не игрушка и б) совсем тyпoй код надо выкинуть, если ахтур попросил его оптимизировать этот гoвнoкoд.
| | |
| 7.170, Аноним (-), 22:08, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Так думает не он, разработчики компиляторов.
На самом деле все проще: математика у процов так работает.
| | |
| 7.208, arisu (ok), 09:09, 31/10/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
>>> buf + len >= buf. Всегда для беззнакового len. Согласны?
>> Вот ты и показал что ты болванчик. Как ты думаешь,
> Так думает не он, разработчики компиляторов.
нет. разработчики компиляторов следуют стандарту, в котором сказано, что переполнения на свете не бывает вовсе. соответственно, коспилятор вправе считать именно так и оптимизировать, основываясь на этом.
пояснение: «неопределённое поведение» — это значит, что программист должен вручную позаботиться о том, чтобы переполнения не случилось; т.е. его не бывает в корректной программе. корректная же работа оптимизатора гарантирована только на корректных программах, на некорректных он может выдавать что угодно.
| | |
|
|
|
|
|
|
| 1.63, annulen (ok), 14:45, 30/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
 Оптимизации компилятора не нарушают стандарт языка, так что достаточно не писать код с undefined behavior, или выявлять его с помощью инструментов, таких как UB sanitizer в Clang.
| | |
| |
| 2.73, ананим (?), 14:58, 30/10/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
До чего?
Что быдлo-кoд также ещё и быдлo-oптимизируется?
Так это и без этой рекламы синтаксического анализатора было ясно.
зыж
Видимо истории со Сноуденом заставили активизироваться производителей анализаторов.
Что сабж, что на хабре,…
Типа — Вы ещё не проверяете код на безопасность самым лучшим (понятно каким?) анализатором? Тогда мы идём к вам.
| | |
|
| 1.84, Пиу (ok), 15:36, 30/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 новость - боян и фигня. уже много лет говорят про UB и что нужно его избегать.
было бы куда интереснее, если бы они взяли настоящие баги компиляторов (а их много) и нашли те, которые бы приводили бы к проблема безопастности приложений.
а так - это курсовая второкурсника на факультете информационной безопастности
| | |
| 1.90, Аноним (-), 15:59, 30/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Главное, что они написали анализатор, который тычет программистов в их косяки. А, по-хорошему, этим должен бы заниматься компилятор. Тот же Clang гордиться своими многословными отчётами.
| | |
| |
| 2.110, Crazy Alex (ok), 17:10, 30/10/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Вот как раз компилятор этого делать и не должен. Он должен запускаться один раз и тупо собирать код согласно стандарту. А анализаторам место в ide, в коммит-хуках, системах ревью и так далее - в общем, там, где производится проверка качества кода.
Сейчас в clang запихнули то, что должно быть в lint - ну так кто-то забыл о one responcbility principle (оно же кусок unix way, кстати) - бывает.
| | |
| |
| |
| 4.163, Crazy Alex (ok), 21:05, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
Ну да, с аббревиатурами я не в ладах - в голове оно всё же не словами хранится. Сорри.
| | |
|
| 3.306, Аноним (-), 19:03, 01/11/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Вот как раз компилятор этого делать и не должен. Он должен запускаться
> один раз и тупо собирать код согласно стандарту.
Ага. И так как про сообщения об ошибках компиляции в стандарте ничего не сказано, компилятор должен тупо игнорировать все ошибки.
| | |
| 3.310, annulen (ok), 21:43, 01/11/2013 [^] [^^] [^^^] [ответить] | –1 +/– | Собственно, clang это и делает, если не просить о большем Замечательно И как т... большой текст свёрнут, показать | | |
|
| 2.176, Аноним (-), 22:29, 30/10/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Главное, что они написали анализатор, который тычет программистов в их косяки. А,
> по-хорошему, этим должен бы заниматься компилятор.
Давайте компилятор еще и программы писать начнет вместо программиста? А программистов уволить вообще.
| | |
|
| |
| 2.149, Аноним (-), 19:51, 30/10/2013 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> Мне кажется или подобные "проверки" на выход за пределы сами по себе ошибки?
Особенно порадовало "if (buf + len < buf)". Хакиры, однако. Про переполнение знают. Но почему чрезмерный размер len надо ловить через столь хитро закрученный болт с левой резьбой - загадка природы.
| | |
| |
| 3.220, pavlinux (ok), 15:10, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Мне кажется или подобные "проверки" на выход за пределы сами по себе ошибки?
> Особенно порадовало "if (buf + len < buf)". Хакиры, однако. Про переполнение
> знают. Но почему чрезмерный размер len надо ловить через столь хитро
> закрученный болт с левой резьбой - загадка природы.
Ваш вариант определения переполнения суммы, при условии, что операнды должны быть одного типа.
| | |
| |
| 4.223, arisu (ok), 15:39, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Ваш вариант определения переполнения суммы, при условии, что операнды должны быть одного
> типа.
а тут уже не раз приводили, вообще-то. в данном случае — '(UINTPTR_MAX-(uintptr_t)buf) < len', например. с надеждой, что len — size_t или uintptr_t.
а если очень хочется «один тип» — то limits.h и xxx_MAX/2.
костыли-с.
| | |
| |
| 5.271, Аноним (-), 23:45, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
так нельзя, т.к. UINTPTR_MAX может быть больше фактического значения адреса. Вообще не понятеен источник проблемы, во всех операциях с памятью всегда известна максимальная длина рабочего блока, с ним и нужно сравнивать.
| | |
| |
| 6.274, arisu (ok), 06:05, 01/11/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> так нельзя, т.к. UINTPTR_MAX может быть больше фактического значения адреса.
хм. портабельного метода узнать «место, где Земля закругляется» нет. но и речь шла о проверке на арифметическое переполнение, а не конкретно на валидность указателя.
к сожалению, это си: «портабельность» в понимании авторов стандартов — это ни в коем случае не определять фичи, одинаково работающие на большинстве платформ, и уж ни в коем случае не определять фичи, которые способны значительно облегчить портирование.
> не понятеен источник проблемы
это плохо.
> во всех операциях с памятью всегда известна
> максимальная длина рабочего блока, с ним и нужно сравнивать.
UINTPTR_MAX эта длина. сравниваем.
| | |
| |
| 7.280, all_glory_to_the_hypnotoad (ok), 12:36, 01/11/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > но и речь шла о проверке на арифметическое переполнение
для тупых ещё раз объясняю, uintptr_t может иметь большую битность чем void*, нельзя им проверять переполнение адреса. Что тут может быть не понятным?
> UINTPTR_MAX эта длина. сравниваем.
это не длина, балбес.
| | |
|
| 6.277, клоун Стаканчик (?), 11:03, 01/11/2013 [^] [^^] [^^^] [ответить]
| –2 +/– | |
Проблема возникает исключительно при программировании ядра Линукс. Для всех остальных она неактуальна. Из темы ядро никто не разрабатывал, так что идёт общение диванных теоретиков.
Источник проблемы - определение момента переполнения беззнакового целого. В ассемблере за это отвечает флаг CF:
add esi,eax
jc overflow ; <<<<
В Си такой конструкции нет. Адекватные люди пишут inline-вставку на ассемблере, но его использование в ядре Линукс запрещено. Дальше начинается обсуждение по типу как открыть входную дверь без ключа если у вас есть пустая консервная банка, бечёвка и окурок.
| | |
| |
| 7.278, arisu (ok), 11:07, 01/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Адекватные люди пишут inline-вставку на ассемблере
а потом офигевают: отчего это их говнософт не собирается на другой платформе? ах, ну да: ведь кроме x86 на свете ничего нет. ну, x86_64 ещё по праздникам. всё равно любимая винда больше нигде не работает нормально.
| | |
| 7.279, тоже Аноним (ok), 11:07, 01/11/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Адекватные люди пишут inline-вставку на ассемблере
И очень этим радуют неадекватных людей, которые собирают не только под x86.
Только почему-то потом эти неадекваты запрещают использовать ассемблер в ядре.
| | |
| 7.281, all_glory_to_the_hypnotoad (ok), 12:41, 01/11/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Проблема возникает исключительно при программировании ядра Линукс.
в ядре всегда известна модель памяти. И нигде нет необходимости проверять переполнение указателя, это выдуманная проблема.
| | |
|
|
| |
| 6.275, arisu (ok), 06:07, 01/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
p.s. $#%%&#! павлин, ну хлоп твою железку! ну перестань же ПОЛНОСТЬЮ посты переделывать, я же с почты отвечаю и не всегда обращаю внимание на процитированый текст — особенно если там одна строка!
| | |
|
|
| 4.323, Аноним (-), 10:45, 02/11/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Ваш вариант определения переполнения суммы,
Изначально неверная постановка задачи. На самом деле цель - поймать выход за границы буфера.
| | |
|
|
|
| 1.133, Аноним (-), 18:23, 30/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Пардон, но если программист в своём коде допускает случаи, когда поведение программы может стать неопределенным, то проблема именно в программисте и его плохом знании стандартов языка.
Рекомендую почитать статьи разработчиков PVS-Studio, которые постоянно подчеркивают, что если вы полагаете "а, ничего страшного, вряд ли когда-нибудь эта переменная станет неопределенной", то рано или поздно: a) это произойдет; б) вы потратите уйму времени, чтобы найти причину. Именно поэтому нужно изначально максимально точно следовать стандартам.
| | |
| |
| 2.141, клоун Стаканчик (?), 18:57, 30/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
Это называется парадокс римского права: знать все законы невозможно, при этом незнание законов не избавляет от ответственности. В рамках строгой логики данный парадокс неразрешим.
| | |
| 2.174, Аноним (-), 22:28, 30/10/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> что если вы полагаете "а, ничего страшного, вряд ли когда-нибудь эта
> переменная станет неопределенной", то рано или поздно: a) это произойдет; б)
> вы потратите уйму времени, чтобы найти причину.
Именно так - при том уповать на то что не описано в стандарте и/или "а вроде работает же" чревато тем что однажды работать таки перестанет. При том в самом неожиданном месте.
Достаточно вспомнить про абобу, memcpy и флеш, где странные люди зачем-то полагались на конкретное поведение memcpy() хотя в стандарте ничего не говорится как именно должен работать memcpy кроме того что он скопирует что попросили куда попросили.
| | |
| |
| 3.209, arisu (ok), 09:12, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> на конкретное поведение memcpy() хотя в стандарте ничего не говорится как
> именно должен работать memcpy кроме того что он скопирует что попросили
> куда попросили.
притом в конкретно описаной ситуации. и там же сказано, что в другой ситуации поведение не определено: может хоть «кукарачу» петь.
| | |
| 3.222, pavlinux (ok), 15:21, 31/10/2013 [^] [^^] [^^^] [ответить] | +1 +/– | Всё такие вумные Если уж вдаваться в абсолютизм, то НЕЛЬЗЯ ОБЕСПЕЧИТЬ КОРРЕКТН... большой текст свёрнут, показать | | |
| |
| |
| 5.259, pavlinux (ok), 17:43, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Этот абсолютизм к реальной жизни ни малейшего отношения не имеет.
Нужно добавить к твоей реальной жизни.
В институтах, на мех.-мате МГУ, в МИФИ,... много работ по этой теме.
| | |
|
| 4.231, arisu (ok), 15:51, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
> То есть, нельзя на компьютере написать программу проверки кода, который будет работать
> на этом же компьютере!!!
чушь. возможно, даже в случае, когда не гарантируется, что все «примитивы» работают корректно (хотя в этом случае, конечно, намного сложнее, чем если принять за данность корректное поведение «примитивов» — и да, есть граничные условия).
| | |
| |
| 5.261, pavlinux (ok), 17:53, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> То есть, нельзя на компьютере написать программу проверки кода, который будет работать
>> на этом же компьютере!!!
> чушь. возможно, даже в случае, когда не гарантируется, что все «примитивы» работают
> корректно (хотя в этом случае, конечно, намного сложнее, чем если принять
> за данность корректное поведение «примитивов» — и да, есть граничные условия).
Знаешь такую фичу, что корректность перевода на иностранный язык, с целью понимания, - есть обратный перевод. Ну или по нашему - дизассемблирование.
Вроде test eax, ebx и cmp eax, ebx одно и тоже, но на разных наречиях...
Для понимания этих наречий и нужон "алфавит дизассемблера".
| | |
| |
| 6.262, arisu (ok), 17:58, 31/10/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Вроде test eax, ebx и cmp eax, ebx одно и тоже, но на разных наречиях…
это для тех, кто язык плохо выучил. а для тех, кто хорошо выучил — «есть нюанс».
| | |
| |
| 7.272, pavlinux (ok), 01:55, 01/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Вроде test eax, ebx и cmp eax, ebx одно и тоже, но на разных наречиях…
> это для тех, кто язык плохо выучил. а для тех, кто хорошо
> выучил — «есть нюанс».
Этот нюанс зовётся компилятор, ибо на C ты напишешь if ( x == 0 ), а компулятор
сделает как ему "нравиться" иль test ax, ax или cmp ax, 0;
Не, ещё хуже - компилер скомпилит в двухбайтовую команду, скажем 0x0b12 или 0x0b10,
а чё там сделает процессор - хрен знает.
Вот так незаметно и подошли к тому, что логическая бага (фича) в проце, влияет как
на работу проверяемого, так и проверяющего.
| | |
|
|
|
|
|
|
| 1.147, Аноним (-), 19:42, 30/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Выход один, компилятор должен компилировать, а вот оптимизировать ли код должен решать конечный пользователь компилятора. Согласен с оптимизацией значит должен понимать что приносишь в жертву.
| | |
| |
| 2.152, const86 (ok), 20:14, 30/10/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Это полумера. Достаточно заковыристый код может и без оптимизатора стать дырой в безопасности.
| | |
| 2.175, Аноним (-), 22:28, 30/10/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Выход один, компилятор должен компилировать, а вот оптимизировать ли код должен решать
> конечный пользователь компилятора.
gcc -O0 вам в руки :)
| | |
|
| 1.191, arisu (ok), 08:22, 31/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– | |
после первого говнопримера читать прекратил: результат 'buf + len' при переполнении тупо не определён. «группе исследователей» — гоугоу читать стандарты, а потом уже делать заявления.
дятлы.
| | |
| 1.244, Аноним (-), 16:27, 31/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Это просто ещё одно доказательство, что убогий сипипи не приспособлен для промышленного, да и вообще мэйнстримного программинга - низкоуровневые выкрутасы ничего не говорят о намерениях (ошибочных или нет) программиста.
Пора уже блин обратить внимание на Ди - на порядок повысить уровень программ!
| | |
| |
| 2.247, arisu (ok), 16:32, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Пора уже блин обратить внимание на Ди
а они там уже перестали язык-то перетрясать? и стандартные библиотеки? пока что D — не смотря на хороший зачин — для «production» никак не готов. «ой, мы обновили компилятор или библиотеку, поэтому ваш старый код больше не соберётся» — это не то, что помогает разрабатывать большие продукты.
для альтернативщиков: я НЕ СКАЗАЛ, что D — плохой. тем более не сказал, что он хуже C++.
| | |
| 2.263, тоже Аноним (ok), 18:38, 31/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Это просто ещё одно доказательство, что убогий сипипи не приспособлен для промышленного, да и вообще мэйнстримного программинга
Вообще-то это аксиома: любой убогий язык не приспособлен для мэйнстрима.
Просто вы почему-то думаете, что убогость языка зависит не от того, кто на нем пишет.
Или не знаете, что большая часть мэйнстрима писалась и пишется на тех языках, от которых вас так высокомерно морщит. А пафосно-великолепный Д так к мэйнстриму никем и не приспособлен. Примерно так же, как и прочие панацеи на бумаге.
Тут кто-то заявлял, что на С всегда полные исходники говнокода. Забывая, что этот ужасный говнокод эффективен, а идеально прекрасные абстракции на какой-нибудь Жаве тратят ресурсы не на работу, а на поддержку этих идеальных абстракций...
| | |
|
| 1.335, rihad (?), 16:41, 06/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Код сам неосторожно написан. Компилятор просто следует стандарту, а стандарт гласит, что любая арифметика на указателях должна ссылаться на один и тот же массив, выходя не больше, чем на 1 элемент после него. Поведение программы в противном случае не определено.
char *buf = ...;
char *buf_end = ...;
unsigned int len = ...;
if (buf + len >= buf_end)
return; /* len too large */
if (buf + len < buf)
return; /* overflow, buf+len wrapped around write to buf[0..len-1] */
Во второй проверке, результат сложения в случае переполнения ссылался бы до объекта, поэтому поведение было бы не определено. Значит компилятор избегает неопределенного поведения.
Лучше было бы вместо обоих условий простое if (buf_end - buf <= len) return;
Во втором примере
struct tun_struct *tun = ...;
struct sock *sk = tun->sk;
if (!tun)
return POLLERR; /* write to address based on tun */
Если бы tun было NULL, обращение tun->sk не определено. Опять же, компилятор избегает не определенного кода if (!tun).
| | |
| 1.337, IRASoldier (?), 12:15, 18/06/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Компилятор выкидывает из кода костыли и грязные хаки (" неопределённые или нестабильные участки кода") - виноват компилятор, а не писатель костылей и грязных хаков, мда.
| | |
|
