[foreign] road to posix

[Maurizio Cimadamore]

My bad - it looks like jextract has some basic support for constants 
like the ones defined in limits.h.

However, some manual hackery is required, since such constants are not 
defined when using a recent GCC compiler.

But I've been able to get at the constants by passing the following flag 
to jextract:

-C-U__GNUC__

(that is, undefine __GNUC__, which will force definition of the 
constants in limit.h)

Nice!

So, to close the loop,  it seems like the problem I had with 
RTLD_DEFAULT was _not_caused by jextract not supporting constant macros 
- but, rather, with jextract not recognizing that specific kind of macro 
constant.

Maurizio



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