> On 11 Jun 2024, at 08:44, Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Tue, Jun 11, 2024 at 09:27:37AM +0200, Richard Biener wrote:
>> On Tue, 11 Jun 2024, FX Coudert wrote:
>>
>>> Hi
>>>
>>> I can’t seem to get a review of this one-line patch. Could a global
>>> reviewer help?
>>
>> While stdio.h can be relied on to exist I do not think you can assume
>> the same for sys/types.h without "configury", but libgccjit.h is an
>> installed API. I would assume including stdlib.h gets you ssize_t as
>> well?
>
> If stdlib.h includes sys/types.h like often on Linux, yes, but not
> necessarily. ssize_t is a POSIX type and it might be solely in sys/types.h.
.. and that is the case for at least some affected Darwin versions (stdlib.h
does not include sys/types.h).
> Perhaps libgccjit.h could use
> #ifdef __has_include
> #if __has_include (<sys/types.h>)
> #include <sys/types.h>
> #endif
> #endif
That seems like a good solution to me.
(my original patch was conditional on __APPLE__ but it seems that the
issue could exist on other platforms too).
Iain
> instead of just #include <sys/types.h>.
> When compiled by gcc, one can use hacks like
> #define unsigned signed
> typedef __SIZE_TYPE__ gcc_jit_ssize_t;
> #undef unsigned
> but that might not work with other compilers and is perhaps
> just too ugly.
>
>> In fact the C11 standard doesn't even mention ssize_t so the
>> API should probably avoid using it and instead use size_t for
>>
>> /* Given type "T", get its size.
>> This API entrypoint was added in LIBGCCJIT_ABI_20; you can test for its
>> presence using
>> #ifdef LIBGCCJIT_HAVE_SIZED_INTEGERS */
>> extern ssize_t
>> gcc_jit_type_get_size (gcc_jit_type *type);
>
> Jakub