> From [EMAIL PROTECTED] Sun Apr 7 08:08:37 2002
> Date: Sun, 7 Apr 2002 16:06:50 +0200 (CEST)
> From: Villy Kruse <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: LPRng: patch for 3.8.10 to compile on Solaris 2.6
>
> On Sat, 6 Apr 2002, Dr Andreas F Muller wrote:
>
> >
> > --- LPRng-3.8.10/src/common/linksupport.c Mon Apr 1 19:54:51 2002
> > +++ LPRng-3.8.10-patched/src/common/linksupport.c Sat Apr 6 12:55:14 2002
> > @@ -1462,7 +1462,7 @@
> > #if !defined(INADDR_NONE)
> > #define INADDR_NONE (-1)
> > #endif
> > - if( inet_addr( strptr ) != INADDR_NONE ){
> > + if( inet_addr( strptr ) != (in_addr_t)INADDR_NONE ){
> > ((unsigned long *)addr)[0] = inet_addr( strptr );
> > return(1);
> > }
> >
>
{
unsigned long t = inet_addr( strptr );
if( sizeof(t) != 4 ){
Errorcode = JABORT;
FATAL(LOG_ERR) "inet_pton: PORTABILITY PROBLEM - legacy
support assumes sizeof(long) == 4, and it is %d",
sizeof(t) );
}
if( t != (unsigned long)INADDR_NONE ){
((unsigned long *)addr)[0] = t;
return(1);
}
}
>
> On my linux system no such thing as in_addr_t. Comparing to 0xffffffffUL
> should be safe.
>
> Appart from that:
>
>
> Seing this code, though, I got suspicious about the cast to (unsigned
> long *): what would happen on systems where longs are 64 bits and
> not 32 bits? If the system is little endian you would copy an addition
> 4 byts of binary zeroes, but on big endian system you would copy 4 binary
> zeroes to addr followed by the 4 bytes of the internet address.
I like the way you think... Paranoid...
>
> Anyone done a porting on big endian 64bit systems? 64bit Solaris should
> qualify.
>
> You might consider to create a temporary structure of type in_addr, move
> the result from inet_addr() to the s_addr member of that structure and
> them memcpy the structure to the area pointed to by addr. Then you don't
> need to call inet_addr more than once, too, although I don't think this is
> a very expensive function.
>
> Or, if you trust that uit32_t is defined somewhere, you can cast to
> (uint32_t *) instead. Some systems may have u_int32_t instead, and
> some have neither, so this may not be portable everywhere.
>
>
> If those systems do HAVE_INET_ATON that problem would become a non-issue.
>
>
> Villy
Patrick Powell Astart Technologies,
[EMAIL PROTECTED] 9475 Chesapeake Drive, Suite D,
Network and System San Diego, CA 92123
Consulting 858-874-6543 FAX 858-279-8424
LPRng - Print Spooler (http://www.lprng.com)
-----------------------------------------------------------------------------
YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST
The address you post from MUST be your subscription address
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body. For the impatient,
to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED]
with: | example:
subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
If you have major problems, send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------
