[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: c-ctype, inttostr, intprops module license
From: |
Simon Josefsson |
Subject: |
Re: c-ctype, inttostr, intprops module license |
Date: |
Thu, 16 Nov 2006 11:03:27 +0100 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.90 (gnu/linux) |
Jim Meyering <address@hidden> writes:
> Simon Josefsson <address@hidden> wrote:
>> Yoann Vandoorselaere <address@hidden> writes:
>>
>>> warning: getaddrinfo is LGPL but depend on intprops which is GPL
>>> warning: inttostr is LGPL but depend on intprops which is GPL
>>
>> Jim, Paul, is it possible to have intprops be under LGPL? The
>> alternative solution I see is to revert the patch for getaddrinfo that
>> made it use inttostr (which needs intprops), and use sprintf instead.
>
> Here's a work-around: remove the inclusion of intprops.h
> and add a simpler, slightly pessimistic definition instead:
>
> #define INT_BUFLEN_BOUND(t) ((sizeof (t) * CHAR_BIT) * 146 / 485 + 1 + 1)
So instead of
if (snprintf (service, servicelen, "%d",
ntohs (((const struct sockaddr_in *) sa)->sin_port))
+ 1 > servicelen)
return EAI_OVERFLOW;
we'd have
#define INT_BUFLEN_BOUND(t) ((sizeof (t) * CHAR_BIT) * 146 / 485 + 1 + 1)
...
unsigned short int port
= ntohs (((const struct sockaddr_in *) sa)->sin_port);
char buf[INT_BUFSIZE_BOUND (port)];
char const *s = uinttostr (port, buf);
if (strlen (s) + 1 > servicelen)
return EAI_OVERFLOW;
memcpy (service, s, strlen (s) + 1);
right?
That still uses uinttostr which is from the inttostr module which
depends on and uses the intprops module, so it would still need GPL'd
code in a possibly LGPL'd project.
I'm starting to feel that we should revert to the old code in
getaddrinfo. It was shorter and more readable, hence more
maintainable. snprintf() is C99 and POSIX, and there is a working
replacement for it in gnulib, under the LGPL.
/Simon
- Re: c-ctype, inttostr, intprops module license, (continued)
- Re: c-ctype, inttostr, intprops module license, Paul Eggert, 2006/11/14
- Re: c-ctype, inttostr, intprops module license, Yoann Vandoorselaere, 2006/11/15
- Re: c-ctype, inttostr, intprops module license, Paul Eggert, 2006/11/15
- Re: c-ctype, inttostr, intprops module license, Simon Josefsson, 2006/11/15
- Re: c-ctype, inttostr, intprops module license, Simon Josefsson, 2006/11/15
- Re: c-ctype, inttostr, intprops module license, Jim Meyering, 2006/11/15
- Re: c-ctype, inttostr, intprops module license, Paul Eggert, 2006/11/15
- Re: c-ctype, inttostr, intprops module license, Yoann Vandoorselaere, 2006/11/16
- Re: c-ctype, inttostr, intprops module license, Simon Josefsson, 2006/11/16
- Re: c-ctype, inttostr, intprops module license, Yoann Vandoorselaere, 2006/11/16
- Re: c-ctype, inttostr, intprops module license,
Simon Josefsson <=
- Re: c-ctype, inttostr, intprops module license, Bruno Haible, 2006/11/16
- Re: c-ctype, inttostr, intprops module license, Eric Blake, 2006/11/16
- Re: c-ctype, inttostr, intprops module license, Jim Meyering, 2006/11/16
- Re: c-ctype, inttostr, intprops module license, Paul Eggert, 2006/11/17
- Re: c-ctype, inttostr, intprops module license, Simon Josefsson, 2006/11/17