At 06:04 PM 5/18/2004, Tom Marshall wrote:

>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>
>*** PGP Signature Status: unknown
>*** Signer: Unknown, Key ID = 0xC62EDA6F
>*** Signed: 5/18/2004 6:04:01 PM
>*** Verified: 5/18/2004 6:45:44 PM
>*** BEGIN PGP VERIFIED MESSAGE ***
>
> > >By "some of these", do you mean inet_ntop() and inet_pton()?  Those chan=
>ges
> > >are fine.  I was just referring to the endian functions.
> >=20
> > I meant both the endian and the inet_pton. (If you look at the winsock2 s=
>dk=20
> > all these endian functions are grouped under the winsock2 api.) I updated=
>=20
> > netdrv.h so we these are inlined (via #defines) except for the case where=
>=20
> > we use hxwinsocklib (see diff at end of this email).
>
>Oh my.  Are you saying that ntohl and friends are in ws2_32.dll?  If that's
>the case, perhaps Win32 should not use the underlying functions at all, but
>define our own instead.  I'd hate to see winsock loaded for something as
>trivial as this.  Not to mention the fact that if they are in a DLL, they
>obviously cannot be reduced to inline instructions.

Surprisingly yes. I agree we probably should eventually just implement our 
own inlined versions and come up with one set of functions for endian stuff.


> > >I don't know exactly where the endian functions are or will be called fr=
>om,
> > >but it seems that they should be reduced to inline instructions if at all
> > >possible regardless of whether they are called from performance sensitive
> > >code.  It's just nicer.  I originally put them in nettypes.h so they cou=
>ld
> > >be used by all of the Helix code.
> > >
> > >I suppose we should discuss this issue and standardize on a single set of
> > >endian functions -- there are at least four different definitions in Hel=
>ix
> > >code that I know about.
> >=20
> > I think that's a good idea.
>
>We'll need a few more functions to round out this functionality, such as
>converting CPU endian to big and little endian, and possibly a function to
>determine endianness at runtime (depending on whether we support dual-endian
>processors with a single binary).  I've got my plate full right now but we
>should keep this in mind as a todo item.
>
>--=20
>Perfection in design is achieved not when there is nothing left to add, but
>rather when there is nothing left to take away.
>         - Antoine de Saint-Exupery
>
>
>*** END PGP VERIFIED MESSAGE ***