Em 27/04/2021 17:33, Érico Nogueira escreveu:
> Em 27/04/2021 16:55, Szabolcs Nagy escreveu:
>> * Matus Kysel <mkysel@tachyum.com> [2021-04-26 09:49:35 +0000]:
>>> Hi Szabolcs,
>>>
>>> I am using your library as part of my validation suite and recently I 
>>> have updated it to latest master, but the sem_close test is not 
>>> buildable for me as it is missing fcntl.h header. I have attached 
>>> possible fix, because I did not found how to contribute to you repo.
>>
>> ccing musl, libc-test is mostly discussed there.
>>
>> posix says
>>
>> "Inclusion of the <semaphore.h> header may make visible symbols 
>> defined in the <fcntl.h> and <time.h> headers."
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/semaphore.h.html 
>>
>>
>> which sounds optional, not guaranteed visibility of O_ open flags in
>> semaphore.h, but sem_open is expected to be usable with only semaphore.h
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/sem_open.html
>>
>> i'm not sure what is the strict standard requirement here, without
>> clarification i consider it a libc header issue if an api is not usable
>> with just the header where it is declared.
>>
> 
> The linux man page for sem_open(3) says including <fcntl.h> is necessary 
> for the flags, and indeed the test fails to build on glibc.
> 
>   The oflag argument specifies flags that control the operation of the
>   call.  (Definitions of the flags values can be obtained by including
>   <fcntl.h>.)
> 
> sem_open(name, 0) works without <fcntl.h>, otherwise it's necessary.
> 
> Taking advantage of the fact that the regressions/sem_close-unmap test 
> has been brought up, it has some interesting results:
> 
> On glibc 2.32:
> - works with dynamic linking
> - segfaults in sem_open() with static linking (might be something wrong 
> with the build?)
> 
> On musl 1.2.2:
> - segfaults most of the time (always?)

My mistake, I was on 1.2.1.

> 
> On musl master (aad50fcd791e009961621ddfbe3d4c245fd689a3):
> - completes successfully most of the time, segfaults ever so often 
> (which would lead me to assume the fix from 
> f70375df85d26235a45e74559afd69be59e5ff99 wasn't enough)

The sem_create() calls can sometimes fail here with EINVAL because 
sem_open is being called with the wrong number of arguments. Included 
patch to fix it.

> 
> Note: for musl master I ran it as
> 
>   /path/muslrepo/lib/libc.so /path/libc-tests/.../sem_close-unmap.exe
> 
> Cheers,
> Érico