Dagobert Michelsen writes:
> Sorry for the delay, I got distracted. I just tested the latest stdint.in.h
> from gnulib
> master and gnutls 3.0.19 passes this stage now.
Thanks.
> However, I didn't change anything on the nettle includes and now get
> lots of warnings.
Are these warnings harmle
Hi,
Am 08.05.2012 um 23:17 schrieb Paul Eggert:
> On 05/08/2012 01:05 PM, Niels Möller wrote:
>> I think it should work fine to just get the gnutls release and apply
>> Paul's patch to the file gnutls-3.0.9/gl/stdint.in.h before running the
>> configure script.
>
> Yes, that's the idea. Thanks.
On 05/08/2012 01:05 PM, Niels Möller wrote:
> I think it should work fine to just get the gnutls release and apply
> Paul's patch to the file gnutls-3.0.9/gl/stdint.in.h before running the
> configure script.
Yes, that's the idea. Thanks.
Dagobert Michelsen writes:
> If Paul or you could provide a bootstrapped tarball I'll be happy to test it
> as
> I am not really familiar with gnulib bootstrapping.
I'm also not very familiar with gnulib.
But I think it should work fine to just get the gnutls release and apply
Paul's patch to
Hi Niels,
Am 08.05.2012 um 10:55 schrieb Niels Möller:
> Paul Eggert writes:
>> Thanks. This seems to be a win regardless of whether it
>> fixes the nettle problems,
>
> Dago, can you test if it solves the SunOS-5.9 problem for you? I.e.,
> apply Paul's patch to gnutls/gnulib, then *unapply* th
Paul Eggert writes:
> Such usage violates the C standard: even if one compiler
> is not picky about it, your're likely to run into another that
> does. So a better solution is needed.
I've committed a workaround to nettle-types.h. It now does
/* Pretend these types always exists. Nettle does
On 05/08/2012 01:55 AM, Niels Möller wrote:
> I'm not sure how picky the compiler is about multiple but equivalent
> typedefs of the same name.
Such usage violates the C standard: even if one compiler
is not picky about it, your're likely to run into another that
does. So a better solution is ne
Paul Eggert writes:
> Thanks. This seems to be a win regardless of whether it
> fixes the nettle problems,
Dago, can you test if it solves the SunOS-5.9 problem for you? I.e.,
apply Paul's patch to gnutls/gnulib, then *unapply* the nettle
workaround I comitted yesterday, and see if you still ge
On 05/07/2012 01:43 PM, Bruno Haible wrote:
Looks good to me.
Thanks. This seems to be a win regardless of whether it
fixes the nettle problems, so I've pushed it into gnulib
master. We can look into further fixes later as needed.
Paul Eggert wrote:
> + stdint: be more consistent with glibc, SunOS libc
> + * lib/stdint.in.h (gl_int_fast8_t, gl_uint_fast8_t)
> + (gl_int_fast16_t, gl_uint_fast16_t)
> + (gl_int_fast32_t, gl_uint_fast32_t)
> + (INT_FAST8_MIN, INT_FAST8_MAX, UINT_FAST8_MAX)
> + (INT_FAST16
On 05/07/2012 10:13 AM, Niels Möller wrote:
> I thought the point of gnulib was to do those annoying things to keep
> the maintanance in one place.
True. Very true.
OK, how about the following patch to gnulib's lib/stdint.in.h?
Does it fix the problem?
And if not, could you please explain what
Paul Eggert writes:
> Hmm, well, the latter point is dubious. SunOS 5.10 standard headers do not
> mention int_fast*_t, except in stdint.h where C requires their definition.
I'd consider that definition to be authoritative...
> Presumably this is for the same reason that Gnulib avoids these ty
On 05/06/2012 12:38 PM, Niels Möller wrote:
But in the particular case of SunOS, the types are defined by system
headers in release 5.10 (and presumably nailed down by the ABI spec),
Hmm, well, the latter point is dubious. SunOS 5.10 standard headers do not
mention int_fast*_t, except in stdi
Paul Eggert writes:
> Intuitively, it's because the int_fast* types are so fragile: they
> depend so much on choice of compiler and compiler option.
Short version: I think gnulib should either make an effort to define
int_fast*_t in the common way on each system (always doing the same as
gcc wou
On 05/06/2012 12:13 AM, Niels Möller wrote:
Paul Eggert writes:
> Generally speaking, it's unwise to use
> the int_fast*_t types in a public header file.
Why (feel free to point to the relevant section of gnulib docs, if it's
explained well there)?
Intuitively, it's because the int_fast*
Bruno Haible writes:
> It doesn't exist so far. But it is feasible. - On the other hand, it
> looks like nettle-stdint.h can already be easily trimmed in this way,
> by undefining _STDINT_NEED_INT_LEAST_T and _STDINT_NEED_INT_FAST_T ?
I think that makes sense. I just need someone (Dagobert Miche
Nikos Mavrogiannopoulos wrote:
> > libunistring installs a trimmed-down version of
> > gnulib's stdint.h, that defines only the int{8,16,32}_t types and not
> > all the rest (int64_t, int_least*_t, int_fast*_t, etc.). [1]
>
> Is there a gnulib module that only provides the basic types?
It doesn't
On 05/06/2012 12:34 PM, Bruno Haible wrote:
> Niels Möller wrote:
>> One possibility might be to not define the types at all, unless the
>> gnulib application explicitly asks for them. Lots of applications want
>> uint32_t, and I imagine a lot fewer have any need for int_fast*_t.
> Yes. For this r
Niels Möller wrote:
> One possibility might be to not define the types at all, unless the
> gnulib application explicitly asks for them. Lots of applications want
> uint32_t, and I imagine a lot fewer have any need for int_fast*_t.
Yes. For this reason, libunistring installs a trimmed-down version
Hi Niels,
Am 06.05.2012 um 07:02 schrieb Paul Eggert:
> On 05/05/2012 12:19 PM, Niels Möller wrote:
>> So code which uses the int_fast*_t types and relies on gnulib will get a
>> slightly different ABI
>
> Generally speaking, it's unwise to use
> the int_fast*_t types in a public header file.
> T
Paul Eggert writes:
> Generally speaking, it's unwise to use
> the int_fast*_t types in a public header file.
Why (feel free to point to the relevant section of gnulib docs, if it's
explained well there)?
Maybe nobody uses these types so it's an academic issue, but if these
types are used in th
On 05/05/2012 12:19 PM, Niels Möller wrote:
So code which uses the int_fast*_t types and relies on gnulib will get a
slightly different ABI
Generally speaking, it's unwise to use
the int_fast*_t types in a public header file.
This is a documented issue in Gnulib.
It's hard to imagine a general
Dagobert Michelsen writes:
> I see different possibilities on how this can be resolved:
>
> 1. nettle uses the gnulib definitions
I currently have no plans to switch to using gnulib.
As far as I'm aware, there's no problem with the types which nettle
actually uses. So it would be a reasonable w
Hi Niels,
(adding bug-gnulib@)
Am 27.04.2012 um 17:24 schrieb Niels Möller:
> Simon Josefsson writes:
>> Yes. Understanding what the differences is, and which one is right,
>> seems useful first though. If the problem is in gnulib, we can fix
>> that and GnuTLS will have the new variant soon.
>
24 matches
Mail list logo
