Confused about a basic TCP daytime server program

Confused about a basic TCP daytime server program

Post by Jorgen Grah » Thu, 09 Dec 2010 08:29:57





>> Then again, if all the world were big-endian, the issue would be moot :)

> But even on big-endian architectures, registers tend to be little-endian
> <http://wlug.org.nz/BigEndian>.

    Odd fact: even on big-endian CPUs, registers are still
    little-endian. To see this, consider the following
    pseudo-AssemblyLanguage sequence:

    move two-byte integer from A to X
    move one-byte integer from X to B

    Question: will the byte at B end up containing the high byte or
    the low byte of A? In little-endian architectures, the answer is
    always "the low byte". However, in big-endian architectures, the
    answer depends on whether X is a memory location or a register; if
    it's a memory location, then B gets the high byte. Otherwise, it
    gets the low byte.

You should have mentioned that /you/ wrote that text.

I'm pretty sure you're wrong in any normal sense of the word, and that
registers[1] are endian-less ... but if you want to argue that you're
/not/, first show how it matters to the programmer. For example by
showing a function which detects if your CPU has big- or little-endian
registers.

/Jorgen

[1] Not counting odd x86 registers where register FOO is really 16
    bits of the 32-bit register BAR and so on ... that sort of thing
    was clearly not what you had in mind.

--

\X/     snipabacken.se>   O  o   .

 
 
 

Confused about a basic TCP daytime server program

Post by Joe Pfeiffe » Thu, 09 Dec 2010 08:36:18




> Your main issue was already identified, but I wanted to point out
> another issue:

>> ? ? ? ? servaddr.sin_addr.s_addr = htonl(INADDR_ANY);

> This is incorrect. INADDR_ANY is already in network byte order.
> Converting it is an error.

Do you have a cite for this?  I went looking, and couldn't find an
actual definition of its byte order.  The old "Advanced 4.4BSD IPC
Tutorial" by Leffler et al has

sin.sin_addr.s_addr = htonl(INADDR_ANY);

on page 30.  /usr/include/netinet/in.h includes its definition in a list
of symbols in which all the symbols for which byte order matters are in
host order.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)

 
 
 

Confused about a basic TCP daytime server program

Post by David Schwart » Thu, 09 Dec 2010 09:20:15



Quote:> Do you have a cite for this? ?I went looking, and couldn't find an
> actual definition of its byte order. ?The old "Advanced 4.4BSD IPC
> Tutorial" by Leffler et al has

The POSIX definition of INADDR_ANY.

"The <netinet/in.h> header shall define the following macros for use
as destination addresses for connect(), sendmsg(), and sendto():

INADDR_ANY
    IPv4 local host address.
INADDR_BROADCAST
    IPv4 broadcast address."

If they weren't in network byte order, you couldn't use them as
destination addresses since destination addresses must be specified in
network byte order.

DS

 
 
 

Confused about a basic TCP daytime server program

Post by David Schwart » Thu, 09 Dec 2010 09:22:35




> > INADDR_ANY is an API detail, not a property of TCP/IP. I know of no
> > rule that requires INADDR_ANY to be equivalent to zero.
> But any other value would conflict with a valid IP address.

255.255.255.255 wouldn't conflict with a valid IP address. In
addition, a platform could specifically state that it doesn't support
254.0.0.0/16 as valid addresses for any of its API functions (since
nobody knows how to use them) and use addresses inside here for its
constants. If those addresses were ever defined as valid for any
purpose, the constants would have to change before that platform could
support them, but likely other changes would be needed as well.

DS

 
 
 

Confused about a basic TCP daytime server program

Post by Lawrence D'Oliveir » Thu, 09 Dec 2010 11:54:20


In message




>> > INADDR_ANY is an API detail, not a property of TCP/IP. I know of no
>> > rule that requires INADDR_ANY to be equivalent to zero.

>> But any other value would conflict with a valid IP address.

> 255.255.255.255 wouldn't conflict with a valid IP address.

That IS a valid IP address. Its the local subnet broadcast address.
 
 
 

Confused about a basic TCP daytime server program

Post by Lawrence D'Oliveir » Thu, 09 Dec 2010 11:55:17






>>> Then again, if all the world were big-endian, the issue would be moot :)

>> But even on big-endian architectures, registers tend to be little-endian
>> <http://wlug.org.nz/BigEndian>.

>     Odd fact: even on big-endian CPUs, registers are still
>     little-endian. To see this, consider the following
>     pseudo-AssemblyLanguage sequence:

>     move two-byte integer from A to X
>     move one-byte integer from X to B

>     Question: will the byte at B end up containing the high byte or
>     the low byte of A? In little-endian architectures, the answer is
>     always "the low byte". However, in big-endian architectures, the
>     answer depends on whether X is a memory location or a register; if
>     it's a memory location, then B gets the high byte. Otherwise, it
>     gets the low byte.

> I'm pretty sure you're wrong in any normal sense of the word, and that
> registers[1] are endian-less ...

Then how do you explain the above?
 
 
 

Confused about a basic TCP daytime server program

Post by Joe Pfeiffe » Thu, 09 Dec 2010 12:07:36







>>>> Then again, if all the world were big-endian, the issue would be moot :)

>>> But even on big-endian architectures, registers tend to be little-endian
>>> <http://wlug.org.nz/BigEndian>.

>>     Odd fact: even on big-endian CPUs, registers are still
>>     little-endian. To see this, consider the following
>>     pseudo-AssemblyLanguage sequence:

>>     move two-byte integer from A to X
>>     move one-byte integer from X to B

>>     Question: will the byte at B end up containing the high byte or
>>     the low byte of A? In little-endian architectures, the answer is
>>     always "the low byte". However, in big-endian architectures, the
>>     answer depends on whether X is a memory location or a register; if
>>     it's a memory location, then B gets the high byte. Otherwise, it
>>     gets the low byte.

>> I'm pretty sure you're wrong in any normal sense of the word, and that
>> registers[1] are endian-less ...

> Then how do you explain the above?

Endianness really only makes sense in a context in which the data is
byte-addressable.  The experiment does establish that transferring the
low-order byte from one register to another has the same effect as
transferring the first byte of an object in memory in a little-endian
computer.  To say that means registers are little-endian is a leap in
the logic.

Let's try another experiment:  transfer one byte from source memory
address+1 to destination memory address+1.  Now transfer one byte from
source register+1 to destination register+1.  Unless you're on a
very weird machine, this time you won't get the same result.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)

 
 
 

Confused about a basic TCP daytime server program

Post by David Schwart » Thu, 09 Dec 2010 12:07:42




> > 255.255.255.255 wouldn't conflict with a valid IP address.
> That IS a valid IP address. Its the local subnet broadcast address.

Yeah, you're right. That was a bad choice.

DS

 
 
 

Confused about a basic TCP daytime server program

Post by Richard Kettlewel » Thu, 09 Dec 2010 18:39:27





>> Your main issue was already identified, but I wanted to point out
>> another issue:

>>> ? ? ? ? servaddr.sin_addr.s_addr = htonl(INADDR_ANY);

>> This is incorrect. INADDR_ANY is already in network byte order.
>> Converting it is an error.

> Do you have a cite for this?  I went looking, and couldn't find an
> actual definition of its byte order.  The old "Advanced 4.4BSD IPC
> Tutorial" by Leffler et al has

> sin.sin_addr.s_addr = htonl(INADDR_ANY);

> on page 30.  /usr/include/netinet/in.h includes its definition in a
> list of symbols in which all the symbols for which byte order matters
> are in host order.

He's talking nonsense, people have been passing INADDR_ANY to htonl()
since at least 1983, i.e. before POSIX even existed.  His interpretation
of the text is POSIX is just wrong.

--
http://www.greenend.org.uk/rjk/

 
 
 

Confused about a basic TCP daytime server program

Post by Jorgen Grah » Thu, 09 Dec 2010 22:35:54







>>>> Then again, if all the world were big-endian, the issue would be moot :)

>>> But even on big-endian architectures, registers tend to be little-endian
>>> <http://wlug.org.nz/BigEndian>.

>>     Odd fact: even on big-endian CPUs, registers are still
>>     little-endian. To see this, consider the following
>>     pseudo-AssemblyLanguage sequence:

>>     move two-byte integer from A to X
>>     move one-byte integer from X to B

>>     Question: will the byte at B end up containing the high byte or
>>     the low byte of A? In little-endian architectures, the answer is
>>     always "the low byte". However, in big-endian architectures, the
>>     answer depends on whether X is a memory location or a register; if
>>     it's a memory location, then B gets the high byte. Otherwise, it
>>     gets the low byte.

>> I'm pretty sure you're wrong in any normal sense of the word, and that
>> registers[1] are endian-less ...

> Then how do you explain the above?

I repeat the part which I wrote and you snipped:

   ... but if you want to argue that you're /not/, first show how it
   matters to the programmer. For example by showing a function which
   detects if your CPU has big- or little-endian registers.

/Jorgen

--

\X/     snipabacken.se>   O  o   .