FindFirstFile недокументированный шаблон или ошибка?

MSDN говорит:

HANDLE WINAPI FindFirstFile( LPCTSTR lpFileName, LPWIN32_FIND_DATA lpFindFileData );

lpFileName Каталог или путь и имя файла, которое может содержать подстановочные знаки, например, звездочку (*) или знак вопроса (?)...

До сегодняшнего дня я не заметил "например".

Предполагая, что у вас есть каталог c:\temp, в приведенном ниже коде отображается "temp". Обратите внимание на искомый каталог: "c:\temp > ". Если у вас есть каталог c:\temp1 и каталог c:\tem, FindNextFile найдет "temp1", но не найдет "tem". Я предположил, что '< найдет "тем", но я ошибся: он ведет себя одинаково. Неважно, сколько "</" > вы добавляете: поведение одинаковое.

С моей точки зрения, это ошибка (' > ' & '<' не являются допустимыми символами в имени файла). С точки зрения Microsoft это может быть особенностью.

Мне не удалось найти полное описание поведения F * Fs.

const TCHAR* s = _T("c:\\temp>");
  {
    WIN32_FIND_DATA d;
    HANDLE h;

    h = FindFirstFile( s, &d );
    if ( h == INVALID_HANDLE_VALUE )
    {
      CString m;
      m.Format( _T("FindFirstFile failed (%d)\n"), GetLastError() );
      AfxMessageBox( m );
      return;
    }
    else
    {
      AfxMessageBox( d.cFileName );
      FindClose( h );
    }
  }

Изменить 1:

Во-первых, я попытался использовать реализацию Windows _stat. Он отлично работал с незаконными символами * и '?, Но проигнорировал' > , поэтому я вступил и заметил, что в реализации особое внимание было уделено документированным подстановочным символам. Я закончил FFF.

Изменить 2:

Я заполнил две формы ошибок: один для FFF - другой для _stat. Я теперь жду ответа MS.

Я не думаю, что нормально смотреть в то, что должно быть черным ящиком и размышлять. Поэтому мои возражения основаны на том, что говорит "контракт": "lpFileName [in] Каталог или путь и имя файла, которое может содержать подстановочные знаки, например, звездочку (*) или знак вопроса (?)...." Я не являюсь носителем английского языка. Возможно, это означает, что "это не единственные подстановочные знаки", может быть, и нет. Однако, если это не единственные подстановочные знаки, они должны были перечислить все (возможно, они будут). На данный момент, я думаю, разрешение MS будет "По дизайну" или "Исправить ошибку".

Что касается _stat, который, я думаю, является функцией ISO, MSDN говорит: "Возвращаемое значение: каждая из этих функций возвращает 0, если информация о статусе файла получена". Он ничего не говорит о подстановочных знаках, задокументированных или нет. Я не вижу, какую информацию можно получить из "c:\temp *" или "c:\temp → ". Очень маловероятно, что кто-то полагается на текущее поведение, поэтому они могут выдать исправление.

Изменить 3:

Microsoft закрыла ошибку _stat как исправленную.

"... Мы исправили это для следующего крупного выпуска Visual Studio (это будет Visual Studio" 14 ", но обратите внимание, что исправление отсутствует в CTP Visual Studio" 14 ", выпущенном на прошлой неделе). В Visual Studio" 14 "функции _stat теперь используют CreateFile для запроса существования и свойств пути. Изменение использования CreateFile было выполнено, чтобы обойти другие причуды, связанные с разрешениями файлов, которые присутствовали в старой реализации FindFirstFile, но изменение также разрешило эту проблему..."