Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #35623 > unrolled thread

htons, htonl, ntohs, ntohl

Back to article view | Back to comp.lang.c

Contents

  htons, htonl, ntohs, ntohl "James Harris" <james.harris.1@gmail.com> - 2013-08-23 13:17 +0100
    Re: htons, htonl, ntohs, ntohl Siri Cruise <chine.bleu@yahoo.com> - 2013-08-23 05:34 -0700
    Re: htons, htonl, ntohs, ntohl James Kuyper <jameskuyper@verizon.net> - 2013-08-23 08:44 -0400
      Re: htons, htonl, ntohs, ntohl Keith Thompson <kst-u@mib.org> - 2013-08-23 08:36 -0700
        Re: htons, htonl, ntohs, ntohl James Kuyper <jameskuyper@verizon.net> - 2013-08-23 12:27 -0400
    Re: htons, htonl, ntohs, ntohl Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-23 09:52 -0600
      Re: htons, htonl, ntohs, ntohl glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-23 18:04 +0000
        Re: htons, htonl, ntohs, ntohl Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-23 15:24 -0600
          Re: htons, htonl, ntohs, ntohl Ian Collins <ian-news@hotmail.com> - 2013-08-24 11:22 +1200
          Re: htons, htonl, ntohs, ntohl glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-26 01:55 +0000
            Re: htons, htonl, ntohs, ntohl James Kuyper <jameskuyper@verizon.net> - 2013-08-25 22:03 -0400
            Re: htons, htonl, ntohs, ntohl Richard Damon <Richard@Damon-Family.org> - 2013-08-25 22:03 -0400
            Re: htons, htonl, ntohs, ntohl Ian Collins <ian-news@hotmail.com> - 2013-08-26 14:10 +1200
      Re: htons, htonl, ntohs, ntohl "James Harris" <james.harris.1@gmail.com> - 2013-08-23 21:16 +0100
        Re: htons, htonl, ntohs, ntohl Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-25 13:54 -0600
      Re: htons, htonl, ntohs, ntohl christian.bau@cbau.wanadoo.co.uk - 2013-08-30 10:58 -0700
        Re: htons, htonl, ntohs, ntohl Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-30 12:37 -0600
          Re: htons, htonl, ntohs, ntohl Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-08-31 17:03 +0000
            Re: htons, htonl, ntohs, ntohl glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-08-31 18:13 +0000
              Re: htons, htonl, ntohs, ntohl Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-08-31 20:52 +0000
            Re: htons, htonl, ntohs, ntohl Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-08-31 14:08 -0600
    Re: htons, htonl, ntohs, ntohl Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-08-27 13:54 +0000
      Re: htons, htonl, ntohs, ntohl Stephen Sprunk <stephen@sprunk.org> - 2013-08-27 10:53 -0500
        Re: htons, htonl, ntohs, ntohl Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-08-27 22:00 +0000
          Re: htons, htonl, ntohs, ntohl "James Harris" <james.harris.1@gmail.com> - 2013-08-27 23:15 +0100
            Re: htons, htonl, ntohs, ntohl Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-08-28 11:10 +0000
              Re: htons, htonl, ntohs, ntohl James Kuyper <jameskuyper@verizon.net> - 2013-08-28 07:20 -0400
                Re: htons, htonl, ntohs, ntohl "James Harris" <james.harris.1@gmail.com> - 2013-08-28 12:47 +0100
                  Re: htons, htonl, ntohs, ntohl Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-08-31 16:40 +0000
        Re: htons, htonl, ntohs, ntohl "James Harris" <james.harris.1@gmail.com> - 2013-08-27 23:36 +0100
          Re: htons, htonl, ntohs, ntohl James Kuyper <jameskuyper@verizon.net> - 2013-08-27 18:54 -0400
          Re: htons, htonl, ntohs, ntohl Stephen Sprunk <stephen@sprunk.org> - 2013-08-27 21:02 -0500
            Re: htons, htonl, ntohs, ntohl Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-08-28 14:10 +0000
              Re: htons, htonl, ntohs, ntohl Stephen Sprunk <stephen@sprunk.org> - 2013-08-28 15:06 -0500
              Re: htons, htonl, ntohs, ntohl christian.bau@cbau.wanadoo.co.uk - 2013-08-30 10:42 -0700
                Re: htons, htonl, ntohs, ntohl Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-08-31 11:49 +0000

Page 1 of 2  [1] 2  Next page →

#35623 — htons, htonl, ntohs, ntohl

On the plus side htons and its friends are a great idea. On the minus side 
they seem to be badly specified or at least incomplete.

I would say they are a great idea for two reasons:

1. they can be null operations on some hardware and thus cost nothing to use

2. rather than a programmer having to encode various byte extracts and 
shifts htons etc can use the instructions provided in the machine's 
instruction set to swap bytes around.

To illustrate that latter point, if we had to reverse the byte order of 
two-byte and four-byte unsigned values in an HLL the code might be

  ((val >> 8) & 0xff) | ((val & 0xff) << 8)
  ((val & 0xff) << 24) | ((val & 0xff00) << 8) | ((val >> 8) & 0xff00) | 
((val >> 24) & 0xff)

Hopefully the compiler will realise that it can drop some of the operations 
but without such as htons or ntohs the programmer still has to write some 
long-winded code. By contrast, many CPUs can carry out such changes much 
more simply. For example, on a Pentium the two seqeunces above could be one 
instruction each

  rol ax, 8
  bswap eax

The first swaps the two bytes of a 16-bit value. The second reverses the 
order of all four bytes of a 32-bit value.

(Incidentally, that code gives the lie to the oft-made assertion that 
assembly code has to be longer than HLL code!)

My point is that htons and friends are great in that they remove the need 
for a programmer to fiddle with that stuff and can be extremely fast. 
However, they have some weaknesses:

1. htons doesn't address the issue of communicating with a machine which has 
a different idea of the size of a short. AIUI a short on one machine might 
be 16-bit but on another 64-bit. (Hence it's poorly specified.)

2. htons is not designed for handling data that we know to be one endianness 
or the other. In that case we know the endianness of the data; that's 
defined by a spec. But we don't know the endianness of the machine we are 
running on! ISTM the existing operations should remain because they do have 
their uses but that there should be other similar operations for dealing 
with specific sizes. (Hence they are incomplete.)

The above text is already long so I'll post separately about defining such 
operations.

James

[toc] | [next] | [standalone]

#35626

In article <kv7jr7$eig$1@dont-email.me>,
 "James Harris" <james.harris.1@gmail.com> wrote:

> My point is that htons and friends are great in that they remove the need 
> for a programmer to fiddle with that stuff and can be extremely fast. 
> However, they have some weaknesses:

These were intended for internet programming. Binary integers and unsigneds in 
IPV4 packets are either one byte, two bytes, or four bytes, and multibyte 
integers all have defined byte order, the network byte order. htons et al 
transparently convert host representations and network packet representations.

Outside of Microsoft, other vendors were faced with binary representations that 
had to work on different hosts, such as TIFF tags or tables in removable disc 
packs. Some of these settled on the network byte order and depended on htons et 
al.
-- 
Edward Snowden for President 2016! He can pardon himself!
Snowden 2016! Disclosure you can believe in!
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
NSA CIA  Constitution patriot terrorism freedom Snowden Paid Maternity Leave

[toc] | [prev] | [next] | [standalone]

#35628

On 08/23/2013 08:17 AM, James Harris wrote:
...
> 1. htons doesn't address the issue of communicating with a machine which has 
> a different idea of the size of a short. AIUI a short on one machine might 
> be 16-bit but on another 64-bit. (Hence it's poorly specified.)

POSIX requires that htons be declared as
     uint16_t htons(uint16_t hostshort);

uint16_t is required to have exactly 16 bits, and the size of a short is
irrelevant. If your system has a declaration that is in terms of short
int, then it's a different htons(), one that doesn't conform to POSIX,
at least not to the current version.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#35636

James Kuyper <jameskuyper@verizon.net> writes:
> On 08/23/2013 08:17 AM, James Harris wrote:
> ...
>> 1. htons doesn't address the issue of communicating with a machine
>> which has a different idea of the size of a short. AIUI a short on
>> one machine might be 16-bit but on another 64-bit. (Hence it's poorly
>> specified.)
>
> POSIX requires that htons be declared as
>      uint16_t htons(uint16_t hostshort);
>
> uint16_t is required to have exactly 16 bits, and the size of a short is
> irrelevant. If your system has a declaration that is in terms of short
> int, then it's a different htons(), one that doesn't conform to POSIX,
> at least not to the current version.

It could conform to POSIX on a system where uint16_t is a typedef for
unsigned short (since typedefs, as you know, don't create new types).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#35638

On 08/23/2013 11:36 AM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 08/23/2013 08:17 AM, James Harris wrote:
>> ...
>>> 1. htons doesn't address the issue of communicating with a machine
>>> which has a different idea of the size of a short. AIUI a short on
>>> one machine might be 16-bit but on another 64-bit. (Hence it's poorly
>>> specified.)
>>
>> POSIX requires that htons be declared as
>>      uint16_t htons(uint16_t hostshort);
>>
>> uint16_t is required to have exactly 16 bits, and the size of a short is
>> irrelevant. If your system has a declaration that is in terms of short
>> int, then it's a different htons(), one that doesn't conform to POSIX,
>> at least not to the current version.
> 
> It could conform to POSIX on a system where uint16_t is a typedef for
> unsigned short (since typedefs, as you know, don't create new types).

You're right, of course. I was thinking mainly in terms of cases like
James Harris' hypothetical 64-bit short, for which that would not be
possible.

[toc] | [prev] | [next] | [standalone]

#35637

"James Harris" <james.harris.1@gmail.com> writes:

> On the plus side htons and its friends are a great idea. On the minus side 
> they seem to be badly specified or at least incomplete.
>
> I would say they are a great idea for two reasons:
>
> 1. they can be null operations on some hardware and thus cost nothing to use
>
> 2. rather than a programmer having to encode various byte extracts and 
> shifts htons etc can use the instructions provided in the machine's 
> instruction set to swap bytes around.
>
> To illustrate that latter point, if we had to reverse the byte order of 
> two-byte and four-byte unsigned values in an HLL the code might be
>
>   ((val >> 8) & 0xff) | ((val & 0xff) << 8)
>   ((val & 0xff) << 24) | ((val & 0xff00) << 8) | ((val >> 8) & 0xff00) | 
> ((val >> 24) & 0xff)
>
> Hopefully the compiler will realise that it can drop some of the operations 
> but without such as htons or ntohs the programmer still has to write some 
> long-winded code. By contrast, many CPUs can carry out such changes much 
> more simply. For example, on a Pentium the two seqeunces above could be one 
> instruction each
>
>   rol ax, 8
>   bswap eax
>
> The first swaps the two bytes of a 16-bit value. The second reverses the 
> order of all four bytes of a 32-bit value.
>
> (Incidentally, that code gives the lie to the oft-made assertion that 
> assembly code has to be longer than HLL code!)
>
> My point is that htons and friends are great in that they remove the need 
> for a programmer to fiddle with that stuff and can be extremely fast. 
> However, they have some weaknesses:
>
> 1. htons doesn't address the issue of communicating with a machine which has 
> a different idea of the size of a short. AIUI a short on one machine might 
> be 16-bit but on another 64-bit. (Hence it's poorly specified.)

The names are unfortunate; the functions are perfectly well specified.
The name htons() gives the impression that it's for 'short's, whatever
that means on the host machine, but it's actually declared (according to
the man page on my machine) as

 uint16_t htons(uint16_t hostshort);

 So it actually does the right thing with a 16 bit value, no matter what
 the host machine's idea of a short is.
 
> 2. htons is not designed for handling data that we know to be one endianness 
> or the other. In that case we know the endianness of the data; that's 
> defined by a spec. But we don't know the endianness of the machine we are 
> running on! ISTM the existing operations should remain because they do have 
> their uses but that there should be other similar operations for dealing 
> with specific sizes. (Hence they are incomplete.)

I don't understand your point here.  The whole idea is to make it
so we don't have to care about the endianness of the machine we're
writing our code on.

> The above text is already long so I'll post separately about defining such 
> operations.
>
> James

[toc] | [prev] | [next] | [standalone]

#35649

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> "James Harris" <james.harris.1@gmail.com> writes:

(snip)

>> My point is that htons and friends are great in that they remove 
>> the need for a programmer to fiddle with that stuff and can be 
>> extremely fast.  However, they have some weaknesses:

(snip)

> The names are unfortunate; the functions are perfectly well specified.
> The name htons() gives the impression that it's for 'short's, whatever
> that means on the host machine, but it's actually declared (according to
> the man page on my machine) as
 
> uint16_t htons(uint16_t hostshort);
 
> So it actually does the right thing with a 16 bit value, no matter what
> the host machine's idea of a short is.

Seems to me less of a problem than the host machine's idea of long.

Except for some strange cases, short has been pretty consisitently
just 16 bits, but htonl() and ntohl(), were defined in terms of long.

In some years passed, int was either 16 or 32 bits, and long 
was 32 bits. When Alpha came out, with 64 bit long, as well as I
understand it, all the IP code failed to compile.

-- glen

[toc] | [prev] | [next] | [standalone]

#35667

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
>> "James Harris" <james.harris.1@gmail.com> writes:
>
> (snip)
>
>>> My point is that htons and friends are great in that they remove 
>>> the need for a programmer to fiddle with that stuff and can be 
>>> extremely fast.  However, they have some weaknesses:
>
> (snip)
>
>> The names are unfortunate; the functions are perfectly well specified.
>> The name htons() gives the impression that it's for 'short's, whatever
>> that means on the host machine, but it's actually declared (according to
>> the man page on my machine) as
>  
>> uint16_t htons(uint16_t hostshort);
>  
>> So it actually does the right thing with a 16 bit value, no matter what
>> the host machine's idea of a short is.
>
> Seems to me less of a problem than the host machine's idea of long.
>
> Except for some strange cases, short has been pretty consisitently
> just 16 bits, but htonl() and ntohl(), were defined in terms of long.

No, from the same man page:

       uint32_t htonl(uint32_t hostlong);

> In some years passed, int was either 16 or 32 bits, and long 
> was 32 bits. When Alpha came out, with 64 bit long, as well as I
> understand it, all the IP code failed to compile.

Hopefully this resulted in the code being rewritten in terms of uint32_t
instead of long.

[toc] | [prev] | [next] | [standalone]

#35670

Joe Pfeiffer wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>
>> Seems to me less of a problem than the host machine's idea of long.
>>
>> Except for some strange cases, short has been pretty consisitently
>> just 16 bits, but htonl() and ntohl(), were defined in terms of long.
>
> No, from the same man page:
>
>         uint32_t htonl(uint32_t hostlong);

Note the past tense!  The POSIX interfaces were updated post-C99, just 
in time for the increase in popularity of little-endian 64 bit 
platforms.  I guess newcomers will miss the significance of the names.

>> In some years passed, int was either 16 or 32 bits, and long
>> was 32 bits. When Alpha came out, with 64 bit long, as well as I
>> understand it, all the IP code failed to compile.
>
> Hopefully this resulted in the code being rewritten in terms of uint32_t
> instead of long.

Alpha predated C99.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#35802

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:

(snip, I wrote)

>> Seems to me less of a problem than the host machine's idea of long.

>> Except for some strange cases, short has been pretty consisitently
>> just 16 bits, but htonl() and ntohl(), were defined in terms of long.
 
> No, from the same man page:
 
>       uint32_t htonl(uint32_t hostlong);
 
>> In some years passed, int was either 16 or 32 bits, and long 
>> was 32 bits. When Alpha came out, with 64 bit long, as well as I
>> understand it, all the IP code failed to compile.
 
> Hopefully this resulted in the code being rewritten in 
> terms of uint32_t instead of long.

When did uint32_t come out?  Alpha was about 1992.

-- glen

[toc] | [prev] | [next] | [standalone]

#35804

On 08/25/2013 09:55 PM, glen herrmannsfeldt wrote:
> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
...
>>> In some years passed, int was either 16 or 32 bits, and long 
>>> was 32 bits. When Alpha came out, with 64 bit long, as well as I
>>> understand it, all the IP code failed to compile.
>  
>> Hopefully this resulted in the code being rewritten in 
>> terms of uint32_t instead of long.
> 
> When did uint32_t come out?  Alpha was about 1992.

It came out in 1999, as part of C99.

-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#35805

On 8/25/13 9:55 PM, glen herrmannsfeldt wrote:
> 
> When did uint32_t come out?  Alpha was about 1992.
> 
> -- glen
> 

C99

[toc] | [prev] | [next] | [standalone]

#35806

glen herrmannsfeldt wrote:
>
> When did uint32_t come out?  Alpha was about 1992.

Didn't I answer that last week?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#35662

"Joe Pfeiffer" <pfeiffer@cs.nmsu.edu> wrote in message 
news:1bob8o1k22.fsf@snowball.wb.pfeifferfamily.net...
> "James Harris" <james.harris.1@gmail.com> writes:

...

>> 2. htons is not designed for handling data that we know to be one 
>> endianness
>> or the other. In that case we know the endianness of the data; that's
>> defined by a spec. But we don't know the endianness of the machine we are
>> running on! ISTM the existing operations should remain because they do 
>> have
>> their uses but that there should be other similar operations for dealing
>> with specific sizes. (Hence they are incomplete.)
>
> I don't understand your point here.  The whole idea is to make it
> so we don't have to care about the endianness of the machine we're
> writing our code on.

I didn't express it well. I was thinking of the preprocessor's ignorance. I 
meant that there should be macros for reading and writing data with specific 
sizes and endianness such as

  ui16_LE and ui16_BE
  ui32_LE and ui32_BE
  ui64_LE and ui64_BE
  and possibly ui32_PE ;-)

On the subject of how things 'should' be the real solution would be if C 
allowed multibyte declarations to be tagged with specific endiannesses, and 
for structures to be defined without automatic padding. Then the above 
macros would not be needed.

James

[toc] | [prev] | [next] | [standalone]

#35773

"James Harris" <james.harris.1@gmail.com> writes:

> "Joe Pfeiffer" <pfeiffer@cs.nmsu.edu> wrote in message 
> news:1bob8o1k22.fsf@snowball.wb.pfeifferfamily.net...
>> "James Harris" <james.harris.1@gmail.com> writes:
>
> ...
>
>>> 2. htons is not designed for handling data that we know to be one 
>>> endianness
>>> or the other. In that case we know the endianness of the data; that's
>>> defined by a spec. But we don't know the endianness of the machine we are
>>> running on! ISTM the existing operations should remain because they do 
>>> have
>>> their uses but that there should be other similar operations for dealing
>>> with specific sizes. (Hence they are incomplete.)
>>
>> I don't understand your point here.  The whole idea is to make it
>> so we don't have to care about the endianness of the machine we're
>> writing our code on.
>
> I didn't express it well. I was thinking of the preprocessor's ignorance. I 
> meant that there should be macros for reading and writing data with specific 
> sizes and endianness such as
>
>   ui16_LE and ui16_BE
>   ui32_LE and ui32_BE
>   ui64_LE and ui64_BE
>   and possibly ui32_PE ;-)

Ah, OK.  Yes, I can see that could be a useful enhancement.

> On the subject of how things 'should' be the real solution would be if C 
> allowed multibyte declarations to be tagged with specific endiannesses, and 
> for structures to be defined without automatic padding. Then the above 
> macros would not be needed.

[toc] | [prev] | [next] | [standalone]

#36147

On Friday, August 23, 2013 4:52:21 PM UTC+1, Joe Pfeiffer wrote:

> The names are unfortunate; the functions are perfectly well specified.

Not _really_. The man page on my computer says: "These routines convert 16 and 32 bit quantities between network byte order and host byte order.". But a value doesn't have a byte order. Only it's representation has a byte order. Both ntohl and htonl convert values to values. Now on every computer I have ever used, ntohl and htonl perform exactly the same operation, so using the wrong one is no problem. But what if a computer has a byte order where that isn't the case,  for example where 0x01020304 is stored as four bytes 2, 3, 4, 1?

These functions should really have been defined in terms of a 32 bit value vs. an array of four bytes, not in terms of two 32 bit values. 

[toc] | [prev] | [next] | [standalone]

#36148

christian.bau@cbau.wanadoo.co.uk writes:

> On Friday, August 23, 2013 4:52:21 PM UTC+1, Joe Pfeiffer wrote:
>
>> The names are unfortunate; the functions are perfectly well specified.
>
> Not _really_. The man page on my computer says: "These routines
> convert 16 and 32 bit quantities between network byte order and host
> byte order.". But a value doesn't have a byte order. Only it's
> representation has a byte order. Both ntohl and htonl convert values
> to values. Now on every computer I have ever used, ntohl and htonl
> perform exactly the same operation, so using the wrong one is no
> problem. But what if a computer has a byte order where that isn't the
> case,  for example where 0x01020304 is stored as four bytes 2, 3, 4,
> 1?

OK, your quibble about the difference between a value and its
representation is noted and you are correct, but I'd be very surprised
if anybody out there has ever been confused by it.

If the host computer uses some weird order like you suggest, then the
routines should do the right thing; in this case, ntohl and htonl
wouldn't do the same thing any more, and a program that had a
long-standing bug of using the wrong one would start messing up.
Program bugs existing but not getting triggered under the existing
environment is unfortunate, but it happens.

A story I've told on myself many times is that for many years I thought
an empty string could be represented by a null pointer -- because I was
doing all my development on a VAX, and the byte at address 0 was
user-readable, and happened to contain a 0.  When I moved to Sun
workstations, I had a *lot* of code start getting segfaults.  The bugs
had always been there, they just hadn't been triggered.

> These functions should really have been defined in terms of a 32 bit
> value vs. an array of four bytes, not in terms of two 32 bit values.

Why?  They convert a value on your host into something that can be
passed to the various functions that need network order, and back.
Really, once you've got something in network order you should treat it
as opaque, and convert it back if you want to look at it.  I don't see
any particular advantage to converting to an array of four bytes, and of
course there is the potential problem of hosts whose byte isn't eight
bits.

[toc] | [prev] | [next] | [standalone]

#36164

On Fri, 2013-08-30, Joe Pfeiffer wrote:
> christian.bau@cbau.wanadoo.co.uk writes:
...
>> These functions should really have been defined in terms of a 32 bit
>> value vs. an array of four bytes, not in terms of two 32 bit values.
>
> Why?  They convert a value on your host into something that can be
> passed to the various functions that need network order, and back.
> Really, once you've got something in network order you should treat it
> as opaque, and convert it back if you want to look at it.

I suppose he's saying that if the "various functions that need network
order" didn't, there would be no need for htons & friends.  (And no
need to remember what's opaque and what's not).

There's a trap hidden in htons & co: you /do/ need them to handle
endianness in the BSD socket API ... but they are not suitable for
handling general endianness issues, because they tend to come together
with alignment issues.  E.g.

  ntohl(*(int*)(buf+n));

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#36165

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

(snip)

> I suppose he's saying that if the "various functions that need network
> order" didn't, there would be no need for htons & friends.  (And no
> need to remember what's opaque and what's not).
 
> There's a trap hidden in htons & co: you /do/ need them to handle
> endianness in the BSD socket API ... but they are not suitable for
> handling general endianness issues, because they tend to come together
> with alignment issues.  E.g.
 
>  ntohl(*(int*)(buf+n));

Yes, don't do that.  If there is question about the alignment, 
memcpy() to an appropriately aligned place and ntohl() that.

But that takes two statements instead of one.

-- glen

[toc] | [prev] | [next] | [standalone]

#36171

On Sat, 2013-08-31, glen herrmannsfeldt wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>
> (snip)
>
>> I suppose he's saying that if the "various functions that need network
>> order" didn't, there would be no need for htons & friends.  (And no
>> need to remember what's opaque and what's not).
>  
>> There's a trap hidden in htons & co: you /do/ need them to handle
>> endianness in the BSD socket API ... but they are not suitable for
>> handling general endianness issues, because they tend to come together
>> with alignment issues.  E.g.
>  
>>  ntohl(*(int*)(buf+n));
>
> Yes, don't do that.  If there is question about the alignment, 
> memcpy() to an appropriately aligned place and ntohl() that.
>
> But that takes two statements instead of one.

Yes -- and that's when I prefer not to use ntohl at all.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web