Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> > +# Prerequisites of lib/uinttostr.c.
>> > +AC_DEFUN([gl_PREREQ_UINTTOSTR], [:])
>>
>> What are these dummy functions useful for, anyway?
>
> They separate the autoconf macros needed to determine _when_ to enable a
> replacemen
Eric Blake-1 <[EMAIL PROTECTED]> wrote:
> I checked this in:
>
> 2006-10-23 Eric Blake <[EMAIL PROTECTED]>
>
> * lib/getaddrinfo.c (includes): Add missing include.
Thanks!
> I've checked it in:
>
> 2006-10-23 Jim Meyering <[EMAIL PROTECTED]>
>
> * lib/getaddrinfo.c (getnameinfo): Use new lightweight uinttostr,
> in place of snprintf.
You missed a piece:
gcc -Wall -DHAVE_CONFIG_H -I. -I.. -I../../gllib -g -O2 -MT
getaddrinfo.o -MD -MP -MF .deps/
>> What are these dummy functions useful for, anyway?
>
> They're just place-holders.
They are place-holders so often that I've come to omit them if I think
they'll always be place-holders. I think it's a matter of style as
much as anything.
Simon Josefsson wrote:
> > +# Prerequisites of lib/uinttostr.c.
> > +AC_DEFUN([gl_PREREQ_UINTTOSTR], [:])
>
> What are these dummy functions useful for, anyway?
They separate the autoconf macros needed to determine _when_ to enable a
replacement from the autoconf macros needed for compiling the r
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> ...
>> +# Prerequisites of lib/uinttostr.c.
>> +AC_DEFUN([gl_PREREQ_UINTTOSTR], [:])
>
> What are these dummy functions useful for, anyway?
Not much.
They're just place-holders.
Jim Meyering <[EMAIL PROTECTED]> writes:
> If you prefer uint16_t over "unsigned short int" we can try that, but
> since that type is used solely for a temporary, with no risk of sign
> extension its width shouldn't matter, and with the latter, we don't
> have to worry about whether the type is de
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> On Sat, 2006-10-21 at 10:39 +0200, Jim Meyering wrote:
>>> Paul, Simon,
>>> Any objection to the changes below?
>>
>> Seems generally fine to me, thanks!
...
> If you prefer uint16_t over "unsigned short int" we
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> On Sat, 2006-10-21 at 10:39 +0200, Jim Meyering wrote:
>> Paul, Simon,
>> Any objection to the changes below?
>
> Seems generally fine to me, thanks!
>
>> + short int port = ntohs (((const struct sockaddr_in *) sa)->sin_port);
>
> Shouldn't 'short i
On Sat, 2006-10-21 at 10:39 +0200, Jim Meyering wrote:
> Paul, Simon,
> Any objection to the changes below?
Seems generally fine to me, thanks!
> + short int port = ntohs (((const struct sockaddr_in *) sa)->sin_port);
Shouldn't 'short int' be either 'unsigned short int' or 'uint16_t'?
My
Paul, Simon,
Any objection to the changes below?
I noticed that getaddrinfo uses snprintf to perform a simple
short-to-string conversion. For such a simple job, snprintf
and its dependent, vasnprintf, are overkill.
Instead, how about using a new shorttostr function instead?
Why a new function?
11 matches
Mail list logo