You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by Roy Fielding <fi...@hyperreal.com> on 1996/11/12 19:24:41 UTC
cvs commit: apache/src util.c
fielding 96/11/12 10:24:40
Modified: src util.c
Log:
Fixed test for value of unsigned -1 to be less system-dependent.
Revision Changes Path
1.30 +1 -1 apache/src/util.c
Index: util.c
===================================================================
RCS file: /export/home/cvs/apache/src/util.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -C3 -r1.29 -r1.30
*** util.c 1996/11/06 10:30:38 1.29
--- util.c 1996/11/12 18:24:35 1.30
***************
*** 1175,1181 ****
#else
my_addr = inet_addr(w);
#endif
! if (my_addr != ((unsigned long) 0xffffffff))
{
if (p != NULL) *p = ':';
return my_addr;
--- 1175,1181 ----
#else
my_addr = inet_addr(w);
#endif
! if (my_addr != (~0ul))
{
if (p != NULL) *p = ':';
return my_addr;
Re: cvs commit: apache/src util.c
Posted by Brian Behlendorf <br...@organic.com>.
Committed.
Brian
On 18 Nov 1996, Dean Gaudet wrote:
> Hey, what if INADDR_NONE is an enumerated type? :)
>
> Count me for +1 if my piddly contributions amount to voting status yet.
>
> Dean
>
> In article <ho...@paris.ics.uci.edu>,
> Roy T. Fielding <ne...@hyperreal.com> wrote:
> >Dean said:
> >> As I mentioned, inet_addr/inet_network return -1 on Solaris, and return
> >> INADDR_NONE on Linux and IRIX. -1 is wrong, ~0ul is wrong, and INADDR_NONE
> >> is wrong too -- unless we use autoconf or stick something else in conf.h.
> >> So either we choose one of those wrongnesses and live with it, or we
> >> switch to inet_aton, or we use autoconf. I know how much some people
> >> like that last option (for reasons I can't fathom at all).
> >
> >I believe the follwing patch will settle the question. If there are further
> >platform-specific problems, we can modify the platform-specific definition
> >of INADDR_NONE in the platform-specific section of conf.h.
> >
> >.....Roy
> >
> >Index: conf.h
> >===================================================================
> >RCS file: /export/home/cvs/apache/src/conf.h,v
> >retrieving revision 1.43
> >diff -c -r1.43 conf.h
> >*** conf.h 1996/11/14 07:24:41 1.43
> >--- conf.h 1996/11/18 01:34:52
> >***************
> >*** 457,462 ****
> >--- 457,466 ----
> > #define S_ISLNK(m) (((m) & S_IFMT) == S_IFLNK)
> > #endif
> >
> >+ #ifndef INADDR_NONE
> >+ #define INADDR_NONE ((unsigned long) -1)
> >+ #endif
> >+
> > /* Finding offsets of elements within structures.
> > * Taken from the X code... they've sweated portability of this stuff
> > * so we don't have to. Sigh...
> >Index: util.c
> >===================================================================
> >RCS file: /export/home/cvs/apache/src/util.c,v
> >retrieving revision 1.31
> >diff -c -r1.31 util.c
> >*** util.c 1996/11/14 07:24:44 1.31
> >--- util.c 1996/11/18 01:34:53
> >***************
> >*** 1170,1176 ****
> > #else
> > my_addr = inet_addr(w);
> > #endif
> >! if (my_addr != (~0ul))
> > {
> > if (p != NULL) *p = ':';
> > return my_addr;
> >--- 1170,1176 ----
> > #else
> > my_addr = inet_addr(w);
> > #endif
> >! if (my_addr != INADDR_NONE)
> > {
> > if (p != NULL) *p = ':';
> > return my_addr;
>
>
>
>
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
Re: cvs commit: apache/src util.c
Posted by Dean Gaudet <dg...@hotwired.com>.
Hey, what if INADDR_NONE is an enumerated type? :)
Count me for +1 if my piddly contributions amount to voting status yet.
Dean
In article <ho...@paris.ics.uci.edu>,
Roy T. Fielding <ne...@hyperreal.com> wrote:
>Dean said:
>> As I mentioned, inet_addr/inet_network return -1 on Solaris, and return
>> INADDR_NONE on Linux and IRIX. -1 is wrong, ~0ul is wrong, and INADDR_NONE
>> is wrong too -- unless we use autoconf or stick something else in conf.h.
>> So either we choose one of those wrongnesses and live with it, or we
>> switch to inet_aton, or we use autoconf. I know how much some people
>> like that last option (for reasons I can't fathom at all).
>
>I believe the follwing patch will settle the question. If there are further
>platform-specific problems, we can modify the platform-specific definition
>of INADDR_NONE in the platform-specific section of conf.h.
>
>.....Roy
>
>Index: conf.h
>===================================================================
>RCS file: /export/home/cvs/apache/src/conf.h,v
>retrieving revision 1.43
>diff -c -r1.43 conf.h
>*** conf.h 1996/11/14 07:24:41 1.43
>--- conf.h 1996/11/18 01:34:52
>***************
>*** 457,462 ****
>--- 457,466 ----
> #define S_ISLNK(m) (((m) & S_IFMT) == S_IFLNK)
> #endif
>
>+ #ifndef INADDR_NONE
>+ #define INADDR_NONE ((unsigned long) -1)
>+ #endif
>+
> /* Finding offsets of elements within structures.
> * Taken from the X code... they've sweated portability of this stuff
> * so we don't have to. Sigh...
>Index: util.c
>===================================================================
>RCS file: /export/home/cvs/apache/src/util.c,v
>retrieving revision 1.31
>diff -c -r1.31 util.c
>*** util.c 1996/11/14 07:24:44 1.31
>--- util.c 1996/11/18 01:34:53
>***************
>*** 1170,1176 ****
> #else
> my_addr = inet_addr(w);
> #endif
>! if (my_addr != (~0ul))
> {
> if (p != NULL) *p = ':';
> return my_addr;
>--- 1170,1176 ----
> #else
> my_addr = inet_addr(w);
> #endif
>! if (my_addr != INADDR_NONE)
> {
> if (p != NULL) *p = ':';
> return my_addr;
Re: cvs commit: apache/src util.c
Posted by Dean Gaudet <dg...@hotwired.com>.
As I mentioned, inet_addr/inet_network return -1 on Solaris, and return
INADDR_NONE on Linux and IRIX. -1 is wrong, ~0ul is wrong, and INADDR_NONE
is wrong too -- unless we use autoconf or stick something else in conf.h.
So either we choose one of those wrongnesses and live with it, or we
switch to inet_aton, or we use autoconf. I know how much some people
like that last option (for reasons I can't fathom at all).
Nothing you put there will be portable. Some things will be more portable
than others. I'm sorry I even mentioned ~0ul, because I knew it would
lead to someone quoting ANSI and saying "only if it's a twos-complement
machine!". Yeah there's so many non-twos-complement machines rolling
off the production lines in the past 16 years which run unix.
Dean
In article <ho...@tees.elsevier.co.uk>,
Paul Richards <ne...@hyperreal.com> wrote:
>Roy Fielding <fi...@hyperreal.com> writes:
>
>> ! if (my_addr != (~0ul))
>
>Ahh, no. Ben's right. The function returns -1, since the return type
>is unsigned long it'll be -1 cast to an unsigned long. The correct fix
>is as Ben said (unsigned long) -1 since this is what the function is
>actually returning and we should test for the same construct.
>
>Assuming an 8 bit representation (save me typing lots of 1's).
>
>The representation of ~0ul is 11111111. That's a positive value that is
>the 1's complement (which is what the ~ operator is) of 0 i.e. the
>largest positive value representable. This is most definately *NOT*
>the same as an integral conversion, in fact, an integral conversion
>takes place on signed numbers as part of the ~ operator's behaviour.
>
>To quote (integral conversions A6.2 K&RII).
>
> "Any integer is converted to a given unsigned type by finding
> the smallest non-negative value that is congruent to that
> integer, modulo one more than the largest value that can be
> represented in the unsigned type. In a two's complement
> represenatation, this is equivalent to left-truncation if the
> bit pattern of the unsigned type is narrower, and to
> zero-filling unsigned values and sign-extending if the
> unsigned type is wider."
>
>Since we're all using 2's complement based machines we're not likely
>to see any difference between ~0ul and (unsigned long) -1 but that's
>only because we're relying on a particular implementation of the
>language and not because ~0ul is correct since it clearly isn't.
>
>--
> Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor)
> Elsevier Science TIS online journal project.
> Email: p.richards@elsevier.co.uk
> Phone: 0370 462071 (Mobile), +44 (0)1865 843155
Re: cvs commit: apache/src util.c
Posted by Paul Richards <p....@elsevier.co.uk>.
Roy Fielding <fi...@hyperreal.com> writes:
> ! if (my_addr != (~0ul))
Ahh, no. Ben's right. The function returns -1, since the return type
is unsigned long it'll be -1 cast to an unsigned long. The correct fix
is as Ben said (unsigned long) -1 since this is what the function is
actually returning and we should test for the same construct.
Assuming an 8 bit representation (save me typing lots of 1's).
The representation of ~0ul is 11111111. That's a positive value that is
the 1's complement (which is what the ~ operator is) of 0 i.e. the
largest positive value representable. This is most definately *NOT*
the same as an integral conversion, in fact, an integral conversion
takes place on signed numbers as part of the ~ operator's behaviour.
To quote (integral conversions A6.2 K&RII).
"Any integer is converted to a given unsigned type by finding
the smallest non-negative value that is congruent to that
integer, modulo one more than the largest value that can be
represented in the unsigned type. In a two's complement
represenatation, this is equivalent to left-truncation if the
bit pattern of the unsigned type is narrower, and to
zero-filling unsigned values and sign-extending if the
unsigned type is wider."
Since we're all using 2's complement based machines we're not likely
to see any difference between ~0ul and (unsigned long) -1 but that's
only because we're relying on a particular implementation of the
language and not because ~0ul is correct since it clearly isn't.
--
Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor)
Elsevier Science TIS online journal project.
Email: p.richards@elsevier.co.uk
Phone: 0370 462071 (Mobile), +44 (0)1865 843155