On 10/27/2015 03:19 PM, Florian Weimer wrote:
> * Daniel Colascione:
>
>> On 10/27/2015 03:12 PM, Florian Weimer wrote:
>>> * Daniel Colascione:
>>>
>>>> This test program works fine. (Watch it work in strace.) This patch is
>>>> against git master. It's okay to document accidental features, right?
>>>>
>>>> int
>>>> main()
>>>> {
>>>> int shmfd = shm_open(".", O_TMPFILE | O_RDWR | O_EXCL, 0600);
>>>> ftruncate(shmfd, 1000);
>>>> mmap(NULL, 1000, PROT_READ | PROT_WRITE, MAP_SHARED, shmfd, 0);
>>>>
>>>> return 0;
>>>> }
>>>
>>> This looks more like a bug to me. I wouldn't count on it continuing
>>> to work. glibc already tightened the rules for the name once.
>>
>> I don't think they can break compatibility like that, and besides: it's
>> a useful feature, not a bug.
>
> Names not starting with '/' do not have well-defined behavior with
> shm_open. Applications shouldn't rely on that.
We document non-portable extensions all the time. Why not this one? In
any case, the glibc info page documents that its implementation of
shm_open accepts whatever open(2) does, and the Linux man page for
open(2) indicates that O_TMPFILE works with the shmem filesystem.
>> Is it better for people to blindly open files in /dev/shm? Because
>> that's what they do today.
>
> memfd_create is the official interface for this purpose. But neither
> O_TMPFILE or memfd_create is very widely supported.
O_TMPFILE appeared in 3.11; memfd_create appeared in 3.17.
Attachment:
signature.asc
Description: OpenPGP digital signature
