Comments on: Undefined behavior – это все, что явно не указано в документации.

By: amirul

amirul — Fri, 29 Aug 2008 23:48:01 +0000

OUT появился в C (MS edition) задолго до того, как появился сам C#, в котором “есть и OUT и REF”. Если Вам не нравится различия в поведении OUT в C и C#, то пенять надо прежде всего разработчикам C#, а не C.

By: Stoune

Stoune — Tue, 22 Jul 2008 14:14:56 +0000

Ау, народ очнитесь, документации по WinAPI и ядру сколько лет не напомните, какие управляемые языки, ява в зачаточном состоянии только в 1996-ом появилась?
Определениям OUT, REF в понимании Microsoft всё таки больше. Я не понимаю подхода “солнце жёлтое, а я хочу чтобы было зелёное” и появление в современных! языках отличной от WinAPI терминологии ничего не изменяет. Если я читаю MSDN пояснение как интерпретировать данные термины, я буду пытаться именно так их интерпретировать и если будет что-то не так, я трижды проверю не ошибся ли я в понимании, а после отправлю отчёт об ошибке в Майкрософт, а не буду притягивать за уши что мне хочется чтобы так было.

By: Not a kernel guy : Проверка параметров функции.

Not a kernel guy : Проверка параметров функции. — Tue, 22 Jul 2008 06:19:49 +0000

[...] пост про параметры функций вызвал на удивление много споров, так что я еще [...]

By: Not a kernel guy » Blog Archive » Проверка параметров функции.

Not a kernel guy » Blog Archive » Проверка параметров функции. — Tue, 22 Jul 2008 06:18:01 +0000

[...] пост про параметры функций вызвал на удивление много споров, так что я еще [...]

By: code writer

code writer — Wed, 09 Jul 2008 09:10:02 +0000

Я говорил, что я не против, чтобы осталось и так. Если стоит выбор - скорость или красота, конечно первое должно побеждать.

By: Not a kernel guy

Not a kernel guy — Wed, 09 Jul 2008 06:52:30 +0000

2-4 команды, не вызова. Например, чтобы проинициализировать вот такой параметр:

__deref_out PVOID* Param

нужно две команды:

mov eax, [esp+Param]
mov [eax], 0

А вот чтобы проинициализировать вот такой:

__deref_opt_out PVOID* Param

Уже нужен условный переход или conditional mov:

mov eax, [esp+Param]
test eax, eax
jz @f
mov [eax], 0
@@:

Не говоря уже о том, что обычно нужно записать больше 4-х байт.

By: code writer

code writer — Wed, 09 Jul 2008 05:34:00 +0000

Вы предлагаете добавить несколько команд (2-4) в каждую функцию API, что эквивалентно по частоте вызовов.

Откуда там 2-4 вызова?

By: Not a kernel guy

Not a kernel guy — Tue, 08 Jul 2008 16:00:56 +0000

Они не проверяли и не будут проверять результат, поэтому любители не скроются.

Это не так, к сожалению. Как показывает практика, если какая-то функция, которая всегда инициализировала буфер (даже если в этом не было необходимости, как в примере выше), вдруг перестает это делать - обязятельно кто-то с грохотом упадёт по Access Violation. И это в production коде.

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

Третье - неужели написать одно присваивание так сложно?

Одно присваивание - не сложно, но даже оно увеличивает объем кода, т.к. каждая функция должна это делать. Только кто вам сказал, что там будет только одно присваивание? Помимо строк функции могут возвращать и другие типы, включая вложенные буферы или полиморфные структуры. Их тоже, скажете, нужно инициализировать всегда и везде?

Одно присваивание конечно очень сильно скажется на производительности и процессорном цеше

Вы не поверите, но удлиннение кода перехода из user mode в kernel mode на несколько (2-4) команд уже заметно на тестах “общего назначения”. Вы предлагаете добавить несколько команд (2-4) в каждую функцию API, что эквивалентно по частоте вызовов.

By: code writer

code writer — Tue, 08 Jul 2008 05:45:25 +0000

Подведу такой итог, ибо спор здесь бессмысленен:

Наезды на MS необоснованы, потому что нарушения нет и функция ведет себя корректно. Но хотелось бы красоты.

By: code writer

code writer — Tue, 08 Jul 2008 05:34:21 +0000

1. Ухудшить производительность и загадить процессорный кеш;
2. Уменьшить вероятность обраружения любителей не проверять результат функции во время тестирования;
3. Усложнить написание и сопровождение кода API.

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

Третье - неужели написать одно присваивание так сложно?

Ради чего? Ради красоты и простоты сопровождения. Мне кажеться, как раз сопровождение упростится.

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