Флаг Unix O_CREAT без режима указан

Стандарт POSIX (IEEE 1003.1:2008) прототипы open() как:

int open(const char *path, int oflag, ...);

Раздел, описывающий поведение O_CREAT не говорит, что произойдет, если Вы опустите необходимый третий аргумент, что означает, что поведение не определено - что-либо возможно.

На практике использование части стека, который был предназначен, чтобы быть стековым фреймом или обратным адресом или чем-то подобным, довольно вероятно - к разумному приближению, которое можно считать случайным целым числом.

Стандарт POSIX 2008 года имеет некоторых интересных новый (и полезный) флаги для open(), включая:

• O_FDCLOEXEC указывать замыкаться-должностное-лицо в открытом.
• O_DIRECTORY указывать, что файл должен быть каталогом.
• O_NOFOLLOW указывать для не преследования символьных ссылок.

hyperboreean, Ваше подозрение может быть не до сих пор от метки. Я надеялся найти ответ в Kernighan Ritchie. К сожалению, я не сделал. Я думаю, что параметр полномочий требуется с флагом O_CREAT, и если Вы не обеспечите, то он, открытый () вытянет случайное значение от стека, который, конечно, остается незамеченным в C.

Править: "случайным" я имею в виду не предсказуемый. Это, вероятно, берет часть обратного адреса, который находится сверху параметров на стеке.

Хороший вопрос. mode значение будет изменено umask из процесса. Таким образом, если Вы не передаете a mode явно к open в O_CREAT операция, и если это приводит к случайным битам, используемым для режима, те случайные биты, будет изменена umask.

Желание я мог быть более категоричным и точным, но я соглашаюсь с cdonner, что "случайные" значения используются, наряду с umask.

Править: Одна вещь, которую Вы могли попробовать, состоит в том, чтобы использовать dtruss или связку или некоторое другое средство, чтобы проследить системные вызовы и посмотреть на значение mode во времени выполнения, чтобы видеть, используется ли что-то разумное, или если это - просто случайные биты, измененные umask, например.