On May 19, 6:59 pm, nickf3 <nic...@[EMAIL PROTECTED]
> wrote:
> On May 18, 1:21 am, Martin Bonner <martinfro...@[EMAIL PROTECTED]
> wrote:
> > On May 17, 9:29 am, nickf3 <nic...@[EMAIL PROTECTED]
> wrote:
> > > On May 16, 8:27 pm, Alan McKenney <alan_mckenn...@[EMAIL PROTECTED]
> wrote:
> > > Please don't reinvent the wheel, use standard library:
> > > #include <arpa/inet.h>
> > > uint32_t
> > > htonl(uint32_t hostlong);
[etc]
> > > These are noops on big-endian machines, so there's no overhead.
>
> > Except that they are /not/ part of the standard library unless you can
> > assume Posix. Also they have a horrible interface. The code Alan
> > wrote took a buffer of unsigned chars (presumably containing octets
> > from the communications protocol) and converted it to a long in a way
> > that will work on any compiler that implements the C++ standard (and a
> > fair few that don't). ntohl et-al assumes all sorts of things about
> > the representations (which may not be true, eg, on a DSP)
>
> Let's look at the (open) source, shall we:
>
[snip]
> u_int32_t
> ntohl(u_int32_t x)
> {
> #if BYTE_ORDER == LITTLE_ENDIAN
> u_char *s = (u_char *)&x;
> return (u_int32_t)(s[0] << 24 | s[1] << 16 | s[2] << 8 | s[3]);
> #else
> return x;
> #endif
> }
>
> Taken directly from OpenBSD cvs. Looks familiar, doesn't it?
> Where's that horror you speak of?
It assumes u_char is eight bits. It will fail horribly on a machine
where CHAR_BIT is 32, and sizeof(u_int32_t) = 1.
.... however the real horror is the interface. It takes a u_int32_t in
and returns a value of the same type. This is plain wrong. Depending
one which way you are going, the conversion needs to be between a
u_int32_t and an array of four unsigned char (which can hold an
octet).
> It's perfectly fine (I'd say, required) to _understand_
> how to write ****table code, but would you want every
> programmer on your team doing this stuff by hand, or
> would you want them _reusing_ the existing libs?
I'm all in favour of using existing libs, but only if they are any
good. I don't think ntohl et al fits that description.
I would want /one/ member of the team writing the communications
library and everybody else will use it.
> Yes, it's not a part of the C++ std lib,
Thank you. That makes your original injunction
>>> use standard library
misleading.
> but neither is that
> socket API you use to get to the "communication channel", nor
True.
> whatever API you use to talk to a DSP (which doesn't have
> C interface, only C++, right?)
I'm not talking TO the DSP. I am running ON the DSP.
> Unless you elaborate on that last statement in
> your post, I call it FUD.
For reference, the last statement was:
>>ntohl et-al assumes all sorts of things about
>>the representations (which may not be true, eg, on a DSP)
The problem is that sane communications libraries deal in sequences of
octets stored in unsigned char (which are then packed up in the
correct order). ntohl is based on an approach where you store bytes
into the memory of a struct, and then fix-up the byte order. It
doesn't work if your platform has CHAR_BIT == 64; it requires you to
control padding between member variables of a struct; it requires you
to declare the structure with specific-sized members (rather than a
natural "int" or "long").
Just Say No.
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
