Здравствуйте, удусекшл, Вы писали:

У>Заголовок темы перечитай, что ли.

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

CreateFileA function (fileapi.h)
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea

HANDLE CreateFileA(
  [in]           LPCSTR                lpFileName,
  [in]           DWORD                 dwDesiredAccess,
  [in]           DWORD                 dwShareMode,
  [in, optional] LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  [in]           DWORD                 dwCreationDisposition,
  [in]           DWORD                 dwFlagsAndAttributes,
  [in, optional] HANDLE                hTemplateFile
);

[in] dwCreationDisposition

CREATE_NEW — Creates a new file, only if it does not already exist.

собственно и вопрос с правами тут судя по всему решается автоматически т.к. ничего специально на чтение открывать — не надо ..

У>Обычный open есть, но объявлен депрекейтед и генерит варнинги. А "_open" — не уверен, что он есть во всяких линупсах. И константы опций в линупсах тоже без '_', а у МС с ним. И тут вроде бы МС все правильно делает:
У>

The name is deprecated because it doesn't follow the Standard C rules for implementation-specific names. However, the function is still supported.

А почему CreateFileW не нарушает Standard C rules? Он не начинается с прочерка.

Здравствуйте, удусекшл, Вы писали:

У>Обычный open есть, но объявлен депрекейтед и генерит варнинги. А "_open" — не уверен, что он есть во всяких линупсах. И константы опций в линупсах тоже без '_', а у МС с ним. И тут вроде бы МС все правильно делает:
У>

The name is deprecated because it doesn't follow the Standard C rules for implementation-specific names. However, the function is still supported.

Не могу найти такого требования в стандарте C.

У>и редиски в данном случае линупсоиды, но легче от этого не становится.
У>Хотя, может я отстал от жизни, и "_open" в линупсы тоже подвезли

И не начинали.

У>>Обычный open есть, но объявлен депрекейтед и генерит варнинги. А "_open" — не уверен, что он есть во всяких линупсах. И константы опций в линупсах тоже без '_', а у МС с ним. И тут вроде бы МС все правильно делает:
У>>

The name is deprecated because it doesn't follow the Standard C rules for implementation-specific names. However, the function is still supported.

N>Не могу найти такого требования в стандарте C.

http://port70.net/~nsz/c/c11/n1570.html#7.1.3

Здравствуйте, σ, Вы писали:

У>>>Обычный open есть, но объявлен депрекейтед и генерит варнинги. А "_open" — не уверен, что он есть во всяких линупсах. И константы опций в линупсах тоже без '_', а у МС с ним. И тут вроде бы МС все правильно делает:
У>>>

The name is deprecated because it doesn't follow the Standard C rules for implementation-specific names. However, the function is still supported.

N>>Не могу найти такого требования в стандарте C.

σ>http://port70.net/~nsz/c/c11/n1570.html#7.1.3

Не будет ли так любезен дорогой коллега объяснить конкретнее, какой подпункт данного пункта в какой конкретно формулировке подразумевает такое требование?

У>>>>Обычный open есть, но объявлен депрекейтед и генерит варнинги. А "_open" — не уверен, что он есть во всяких линупсах. И константы опций в линупсах тоже без '_', а у МС с ним. И тут вроде бы МС все правильно делает:
У>>>>

The name is deprecated because it doesn't follow the Standard C rules for implementation-specific names. However, the function is still supported.

N>>>Не могу найти такого требования в стандарте C.

σ>>http://port70.net/~nsz/c/c11/n1570.html#7.1.3

N>Не будет ли так любезен дорогой коллега объяснить конкретнее, какой подпункт данного пункта в какой конкретно формулировке подразумевает такое требование?

Я предполагаю что шизы из Microsoft решили, что зарезервированы (не могут объявляться/определяться программой) идентификаторы как описано в том разделе.
open не зарезервирован и может определяться программой. Если будет конфликт с open, который пришёл извне программы, например, из fcntl.h, то тут виноват fcntl.h.

Здравствуйте, σ, Вы писали:

σ>>>http://port70.net/~nsz/c/c11/n1570.html#7.1.3

σ>Я предполагаю что шизы из Microsoft решили, что зарезервированы (не могут объявляться/определяться программой) идентификаторы как описано в том разделе.
σ>open не зарезервирован и может определяться программой. Если будет конфликт с open, который пришёл извне программы, например, из fcntl.h, то тут виноват fcntl.h.

Идея понятна, но тогда почему open должен был подпадать под это требование, а CreateFile — нет? Кто мешает определить такое имя в юзерском коде?
Даже если предположить, что они пользовались такой логикой, то что-то не сходится.

У меня тут другое предположение: периодически у них формулировалась необходимость реализовать и дать программам POSIX-подсистему. В Posix явно определён свой open(). Сделать POSIX поверх WinAPI они не могли, глубинная семантика очень разная. В таком случае им нужно различать тот open(), который полноценный POSIX, и тот open(), который эмуляция в CRT в пределах того, что они хотят в него вложить. Логично тогда второй назвать _open() (минимум замены), или crt_open, или ещё как-то.
И вот тогда это требование не создавать конфликта обретает плоть...

Здравствуйте, удусекшл, Вы писали:

У>Здравствуйте, Kernan, Вы писали:

У>>>Это при том, что в POSIX есть open с O_CREAT|O_EXCL, через которую в итоге всё равно всё делается
K>>std::filesystem::exists?

У>Там тогда надо ещё потанцевать и проверить, не является ли это каталогом. Это раз.

_stat. В Linux и прочих UNIX-подобных системах — stat. Если файл уже открыт, можно функцию _fstat использовать, у которой параметр — файловый дескриптор, а не путь.

Здравствуйте, AleksandrN, Вы писали:

У>>Там тогда надо ещё потанцевать и проверить, не является ли это каталогом. Это раз.

AN>_stat. В Linux и прочих UNIX-подобных системах — stat.

Пофиг, потому что всё равно есть шанс на обгон...

Здравствуйте, xma, Вы писали:

У>>И что? Твой код делает не то, что нужно, этого достаточно

xma>он делает то что ты и просил — в заголовке темы .. а что тебе реально было надо — тут телепатов нету ..

Он делает не то, что я просил.

Здравствуйте, xma, Вы писали:

У>>Заголовок темы перечитай, что ли.

xma>а ты не огрызайся, а почекай лучше что тебе предлагают .. (всё в точности с твоими требованиями в заголовке темы)

xma>CreateFileA function (fileapi.h)

Спасибо, я винапи знаю. Перечитай таки заголовок

Здравствуйте, AleksandrN, Вы писали:

У>>Там тогда надо ещё потанцевать и проверить, не является ли это каталогом. Это раз.

AN>_stat. В Linux и прочих UNIX-подобных системах — stat. Если файл уже открыт, можно функцию _fstat использовать, у которой параметр — файловый дескриптор, а не путь.

Ну, так я и говорю — танцевать надо. А _fstat, кстати, получает целочисленный дескриптор, и не не уверен, что из FILE* его можно вытащить

Здравствуйте, netch80, Вы писали:

N>Сделать POSIX поверх WinAPI они не могли, глубинная семантика очень разная.

А вот про это можно поподробнее? Я лично не вижу особых проблем

Здравствуйте, netch80, Вы писали:

N>Сделать POSIX поверх WinAPI они не могли, глубинная семантика очень разная.
Разве? А как же Windows Subsystem for Linux?

Здравствуйте, удусекшл, Вы писали:

У>Ну, так я и говорю — танцевать надо. А _fstat, кстати, получает целочисленный дескриптор, и не не уверен, что из FILE* его можно вытащить

int fileno(FILE *stream)

Здравствуйте, B0FEE664, Вы писали:

N>>Сделать POSIX поверх WinAPI они не могли, глубинная семантика очень разная.
BFE>Разве? А как же Windows Subsystem for Linux?

А так же Microsoft POSIX subsystem, Windows Services for UNIX. Я не уверен на 100%, но по-моему какая-то венда с этими нашлёпками даже была POSIX-сертифицирована.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, B0FEE664, Вы писали:

N>>>Сделать POSIX поверх WinAPI они не могли, глубинная семантика очень разная.
BFE>>Разве? А как же Windows Subsystem for Linux?

Все драйвера свои.

vsb>А так же Microsoft POSIX subsystem, Windows Services for UNIX. Я не уверен на 100%, но по-моему какая-то венда с этими нашлёпками даже была POSIX-сертифицирована.

Оно поверх ядерного API (причём особым образом), а не поверх WinAPI.

σ>>>>http://port70.net/~nsz/c/c11/n1570.html#7.1.3

σ>>Я предполагаю что шизы из Microsoft решили, что зарезервированы (не могут объявляться/определяться программой) идентификаторы как описано в том разделе.
σ>>open не зарезервирован и может определяться программой. Если будет конфликт с open, который пришёл извне программы, например, из fcntl.h, то тут виноват fcntl.h.

N>Идея понятна, но тогда почему open должен был подпадать под это требование, а CreateFile — нет? Кто мешает определить такое имя в юзерском коде?

CreateFile __stdcall, а юзерский код по-умолчанию __cdecl. Хотя да, это не спасёт от конфликтов в сырцах, только при линковке.

N>Даже если предположить, что они пользовались такой логикой, то что-то не сходится.

N>У меня тут другое предположение: периодически у них формулировалась необходимость реализовать и дать программам POSIX-подсистему. В Posix явно определён свой open(). Сделать POSIX поверх WinAPI они не могли, глубинная семантика очень разная. В таком случае им нужно различать тот open(), который полноценный POSIX, и тот open(), который эмуляция в CRT в пределах того, что они хотят в него вложить. Логично тогда второй назвать _open() (минимум замены), или crt_open, или ещё как-то.
N>И вот тогда это требование не создавать конфликта обретает плоть...

Если сам всё знаешь, зачем меня просишь объяснить тогда?

Здравствуйте, σ, Вы писали:

σ>Если сам всё знаешь, зачем меня просишь объяснить тогда?

Кто сказал, что знаю? Предполагаю. Уверен процентов на 70-80. Но для твёрдого утверждения этого мало.

Здравствуйте, удусекшл, Вы писали:

У>Всем привет!

У>Собственно, мои приключения с std::fopen

Автор: удусекшл
Дата: 03.02.22

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

У>Это при том, что в POSIX есть open с O_CREAT|O_EXCL, через которую в итоге всё равно всё делается

Создать файл с гарантированно уникальным именем (uuid какой-нибудь), затем std::filesystem::rename, а при неудаче удалить?