Bug 199806 - [libc] Add a new option letter "l" to make fopen() use O_SHLOCK or O_EXLOCK when calling open()
Summary: [libc] Add a new option letter "l" to make fopen() use O_SHLOCK or O_EXLOCK w...
Status: Closed Not Accepted
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Fernando Apesteguía
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2015-04-30 11:25 UTC by jau
Modified: 2023-02-19 18:17 UTC (History)
1 user (show)

See Also:


Attachments
A patch to add the proposed new option letter to fopen() (675 bytes, patch)
2015-04-30 11:25 UTC, jau
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description jau 2015-04-30 11:25:53 UTC
Created attachment 156144 [details]
A patch to add the proposed new option letter to fopen()

This is a change proposal.

Since FreeBSD already has the open() flags O_SHLOCK and O_EXLOCK
it would make sense for the same feature to be also available when
calling fopen(). So, I propose adding a new option letter "l" to
force fopen() to add the suitable one of these locking flags when
calling open(), O_SHLOCK for "r" and O_EXLOCK for "w", "r+", etc.

Such an extension is of course non-standard, but when code portability
is not a big issue such an extension would make FreeBSD specific code
easier to read and write, and maybe also a bit more robust while avoiding
the need to go the extra mille passum to call fileno() and flock() later.

From my point of view writing something like...

fp = fopen("whateverfile", "wb+lex");

... is a pretty neat idea. Either I get a handle to a completely
new file with the exclusive lock applied, and it will not be left
open after an exec*() call, or I get a NULL.

Obviously the same change applies to 10.1 as well, if the merits of
this idea are accepted.
Comment 1 Fernando Apesteguía freebsd_committer freebsd_triage 2023-02-19 18:17:08 UTC
Thanks for the patch.

However, this PR didn't get any traction from the developers probably due to the non-standard nature of the change.

Closing, but feel free to reopen (no pun intended) if you think it is proper.