Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

["Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>]

Hi Alex,

On 10/1/20 6:55 PM, Alejandro Colomar wrote:
> 
> 
> On 2020-10-01 18:38, Michael Kerrisk (man-pages) wrote:
>> Hi Alex,
>>
>>> +According to the C language standard,
>>> +a pointer to any object type may be converted to a pointer to
>>> +.I void
>>> +and back.
>>> +POSIX further requires that any pointer,
>>> +including pointers to functions,
>>> +may be converted to a pointer to
>>> +.I void
>>> +and back.
>> I know you are correct about POSIX, but which part of the
>> standard did you find this information in? The only
>> reference that I find in POSIX is the dlsym() spec. Is it
>> covered also somewhere else in the standrd?
>>
>> Thanks,
>>
>> Michael
>>
> 
> Hi Michael,
> 
> I've bean searching, and dlsym is the only one:
> 
> ________
> 
> user@debian:~/Desktop/src/Standards/susv4-2018$ grep -rn "pointer to a 
> function"
> functions/regfree.html:530:"undefined" means that the action 
> by the application is an error, of similar severity to passing a bad 
> pointer to a function.</p>
> functions/dlsym.html:138:<p>Note that conversion from a <b>void *</b> 
> pointer to a function pointer as in:</p>
> functions/regcomp.html:530:&quot;undefined&quot; means that the action 
> by the application is an error, of similar severity to passing a bad 
> pointer to a function.</p>
> functions/regexec.html:530:&quot;undefined&quot; means that the action 
> by the application is an error, of similar severity to passing a bad 
> pointer to a function.</p>
> functions/V2_chap02.html:3039:<p>There are three types of action that 
> can be associated with a signal: SIG_DFL, SIG_IGN, or a pointer to a 
> function. Initially,
> functions/regerror.html:530:&quot;undefined&quot; means that the action 
> by the application is an error, of similar severity to passing a bad 
> pointer to a function.</p>
> user@debian:~/Desktop/src/Standards/susv4-2018$ grep -rn "function pointer"
> basedefs/glob.h.html:165:"../functions/glob.html"><i>glob</i>()</a> 
> prototype definition by removing the <b>restrict</b> qualifier from the 
> function pointer
> xrat/V4_xsh_chap02.html:114:when the application requires it; for 
> example, if its address is to be stored in a function pointer variable.</p>
> functions/dlsym.html:138:<p>Note that conversion from a <b>void *</b> 
> pointer to a function pointer as in:</p>
> user@debian:~/Desktop/src/Standards/susv4-2018$ grep -rn "pointer to 
> function"
> functions/dlsym.html:73:converted from type pointer to function to type 
> pointer to <b>void</b>; otherwise, <i>dlsym</i>() shall return the 
> address of the
> user@debian:~/Desktop/src/Standards/susv4-2018$
> 
>  From those, the only one that documents this is functions/dlsym.
> The rest is noise.
> 
> The most explicit paragraph in dlsym is the following:
> 
> [[
> Note that conversion from a void * pointer to a function pointer as in:
> 
> fptr = (int (*)(int))dlsym(handle, "my_function");
> 
> is not defined by the ISO C standard.
> This standard requires this conversion to work correctly
> on conforming implementations.
> ]]

Okay -- so, one more thing for a revised (squashed) patch.
I think you better say that that POSIX requirements exists 
only since POS0X.1-2008 Technical Corrigendum 1 (2013).

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/