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

Это перевод More undocumented behavior and the people who rely on it: Output buffers. Автор: Реймонд Чен.

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

Но это всё равно не останавливает людей.

Я вспомнил об этой теме, после чтения истории Майкла Каплана о клиенте, который хотел, чтобы содержимое выходных буферов было бы согласованным даже при ошибке. Причина, по которой буфера могут оставаться в нетронутом состоянии - потому что многие программы это предполагают, даже хотя в документации ничего такого не сказано.

Вот один из примеров, которые я видел (переписан), который ожидает, что буфер не изменится:

var
  hk: HKEY;
begin
  ...
  hk := hkFallback;
  RegOpenKeyEx(..., hk);
  RegQueryValue(hk, ...);
  if hk <> hkFallback then
    RegCloseKey(hk);
  ...
end;

Этот фрагмент кода начинается с "запасного" (fallback) ключа, а затем пытается открыть "лучший" ключ, предполагая, что если открытие будет неудачным, то содержимое hk не будет изменено и, таким образом, будет использовано исходное fallback-значение. Это поведение не гарантируется спецификацией функции RegOpenKeyEx, но это не останавливает людей от его использования.

А вот ещё один пример из настоящего кода. Заметьте, что метод CRegistry::Restore документирован как "Если указанный ключ не существует, то значение 'Value' не изменяется" (давайте проигнорируем, что документация использует терминологию реестра неверно: указываемый параметр - это имя значения, а не имя ключа). Если вы посмотрите на то, что код делает, то он загружает в буфер исходное значение "Value", а затем дважды вызывает функцию RegQueryValueEx и игнорирует возвращаемый результат в обоих случаях! Настоящая работа происходит в методе CRegistry::RestoreDWORD. Заметьте, что в первый вызов он инициализирует переменную типа, а затем вызывает функцию RegQueryValueEx и предполагает, что она не изменяет параметр &type при ошибке. Затем, он вызывает RegQueryValueEx второй раз, но в этот раз предполагая, что буфер &Value останется неизменным при ошибке, потому что это то, что ожидает метод CRegistry::Restore.

Я не хотел придираться к конкретно этому фрагменту кода. Это был просто пример, как люди могут злоупотреблять API. Win32 нужно быть устойчивым к таким злоупотреблениям во имя обратной совместимости. Потому что, в конечном итоге, люди покупают компьютеры, чтобы на них программы работали, а не ломались.

Одним важным исключением из правила "выходные буферы не определены при ошибке" являются буфера, возвращаемые интерфейсам COM. Правила COM таковы, что выходные буфера инициализированы всегда, даже при ошибке в методе. Это необходимо, чтобы маршаллер не вылетел. К примеру, последний параметр к методу IUnknown.QueryInterface должен быть установлен в nil при ошибке.