[foreign] road to posix

[Maurizio Cimadamore]

On 29/05/18 14:33, Florian Weimer wrote:
> On 05/29/2018 03:12 PM, Maurizio Cimadamore wrote:
>> There was a minor surprise though: the dlfcn header defines a bunch 
>> of constants which are necessary in order to work with the library; 
>> my example above uses RTLD_DEFAULT. Unfortunately, such constants are 
>> (unsurprisignly) defined as this:
>>
>> ```
>> # define RTLD_DEFAULT   ((void *) 0)
>> ```
>>
>> Since Jextract doesn't understand these, these constants are omitted 
>> from the jextract output.
>
> It's not entirely unlikely that RTLD_DEFAULT will turn into a function 
> call in the future.  MB_CUR_MAX is an existing example for that.
>
> Furthermore, <dlfcn.h> is very special because functions like dlopen 
> and (particularly) dlsym are expected to be caller-sensitive in the 
> sense that they give different results depending on which DSO calls 
> them.  So they are very difficult to wrap properly.
Thanks, that helps.

I've looking at other posix headers and they do look more well-behaved. 
For instance I had more success in experimenting with ctypes.h (*). I'll 
keep looking at these cases - we can obviously define well-known 
constants (such as RTLD_DEFAULT) in a Java library, I just wanted to 
have a sense of how frequent these cases could be in practice.

(*) the standard jextract behavior is to NOT generate classfiles for 
anything that is imported from a 'system' header file. As such, when 
working with ctypes, you have to explicitly pass to jextract all the 
headers that might contain useful definitions: for instance, I had also 
to pass locale.h and xlocale.h, in order to arrive at the 
__locale_struct definition. Manually computing the transitive closure of 
the header dependencies is not nice from a usability perspective, so 
something is needed here.

I understand that the rationale behind the current behavior is twofold: 
on the one hand, it is likely for system header files to be pulled in 
most of the times - so the current approach enables _sharing_: e.g. a 
separate jextract run could be done on system headers, and then have 
another run at another library - then put both jarfiles in the 
classpath. Another potential problem with system header files is 
compiler builtins - e.g. symbols for which there's no real definition - 
one such example is `__va_list` which I have encountered in the past.

Maurizio
>
> Thanks,
> Florian