[foreign] road to posix

[Maurizio Cimadamore]

Also,
w/o pulling in dflcn.h, which, as you say is a bit special, a good 
example of the 'constant problem' I was hinting at would be limits.h.

e.g.

```
#  define INT_MIN       (-INT_MAX - 1)
#  define INT_MAX       2147483647
```

Maurizio


On 29/05/18 15:20, Maurizio Cimadamore wrote:
>
>
> 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
>