Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/lib/libc/net/ntohl.c

28 lines
501 B
C
Raw Normal View History

Fix RCSID's Fix gcc warnings Add missing prototypes Use "namespace.h"
1997-07-13 23:57:30 +04:00
/* $NetBSD: ntohl.c,v 1.8 1997/07/13 19:57:55 christos Exp $ */
use NetBSD rather than ID
1995-02-25 06:34:50 +03:00
Provide C language versions of the netorder functions. These may be "good enough" for big-endian systems that do not have assembly language versions of their own. A compiler should be able to do a fairly good job optimising them, it probably won't be smart enough to omit the stack frame, but then again, these functions won't be called unless the macro versions are undef'd. On the other hand, they are only intended for bootstrap purposes on little- endian systems. They should be replaced with assembly language versions as soon as possible.
1993-08-31 23:00:11 +04:00
/*
Winning Strategies has placed this code into the Public Domain
1995-04-29 03:19:22 +04:00
* Written by J.T. Conklin <jtc@netbsd.org>.
* Public domain.
Provide C language versions of the netorder functions. These may be "good enough" for big-endian systems that do not have assembly language versions of their own. A compiler should be able to do a fairly good job optimising them, it probably won't be smart enough to omit the stack frame, but then again, these functions won't be called unless the macro versions are undef'd. On the other hand, they are only intended for bootstrap purposes on little- endian systems. They should be replaced with assembly language versions as soon as possible.
1993-08-31 23:00:11 +04:00
*/
Fix RCSID's Fix gcc warnings Add missing prototypes Use "namespace.h"
1997-07-13 23:57:30 +04:00
#include <sys/cdefs.h>
Provide C language versions of the netorder functions. These may be "good enough" for big-endian systems that do not have assembly language versions of their own. A compiler should be able to do a fairly good job optimising them, it probably won't be smart enough to omit the stack frame, but then again, these functions won't be called unless the macro versions are undef'd. On the other hand, they are only intended for bootstrap purposes on little- endian systems. They should be replaced with assembly language versions as soon as possible.
1993-08-31 23:00:11 +04:00
#if defined(LIBC_SCCS) && !defined(lint)
Fix RCSID's Fix gcc warnings Add missing prototypes Use "namespace.h"
1997-07-13 23:57:30 +04:00
__RCSID("$NetBSD: ntohl.c,v 1.8 1997/07/13 19:57:55 christos Exp $");
Provide C language versions of the netorder functions. These may be "good enough" for big-endian systems that do not have assembly language versions of their own. A compiler should be able to do a fairly good job optimising them, it probably won't be smart enough to omit the stack frame, but then again, these functions won't be called unless the macro versions are undef'd. On the other hand, they are only intended for bootstrap purposes on little- endian systems. They should be replaced with assembly language versions as soon as possible.
1993-08-31 23:00:11 +04:00
#endif
maybe they should actually... WORK!
1994-10-19 06:27:52 +03:00
#include <sys/types.h>
Provide C language versions of the netorder functions. These may be "good enough" for big-endian systems that do not have assembly language versions of their own. A compiler should be able to do a fairly good job optimising them, it probably won't be smart enough to omit the stack frame, but then again, these functions won't be called unless the macro versions are undef'd. On the other hand, they are only intended for bootstrap purposes on little- endian systems. They should be replaced with assembly language versions as soon as possible.
1993-08-31 23:00:11 +04:00
#undef ntohl
in_addr_t and in_port_t changes
1996-10-13 08:08:34 +04:00
in_addr_t
maybe they should actually... WORK!
1994-10-19 06:27:52 +03:00
ntohl(x)
in_addr_t and in_port_t changes
1996-10-13 08:08:34 +04:00
in_addr_t x;
Provide C language versions of the netorder functions. These may be "good enough" for big-endian systems that do not have assembly language versions of their own. A compiler should be able to do a fairly good job optimising them, it probably won't be smart enough to omit the stack frame, but then again, these functions won't be called unless the macro versions are undef'd. On the other hand, they are only intended for bootstrap purposes on little- endian systems. They should be replaced with assembly language versions as soon as possible.
1993-08-31 23:00:11 +04:00
{
#if BYTE_ORDER == LITTLE_ENDIAN
in_addr_t and in_port_t changes
1996-10-13 08:08:34 +04:00
u_char *s = (u_char *)&x;
return (in_addr_t)(s[0] << 24 | s[1] << 16 | s[2] << 8 | s[3]);
Provide C language versions of the netorder functions. These may be "good enough" for big-endian systems that do not have assembly language versions of their own. A compiler should be able to do a fairly good job optimising them, it probably won't be smart enough to omit the stack frame, but then again, these functions won't be called unless the macro versions are undef'd. On the other hand, they are only intended for bootstrap purposes on little- endian systems. They should be replaced with assembly language versions as soon as possible.
1993-08-31 23:00:11 +04:00
#else
in_addr_t and in_port_t changes
1996-10-13 08:08:34 +04:00
return x;
Provide C language versions of the netorder functions. These may be "good enough" for big-endian systems that do not have assembly language versions of their own. A compiler should be able to do a fairly good job optimising them, it probably won't be smart enough to omit the stack frame, but then again, these functions won't be called unless the macro versions are undef'd. On the other hand, they are only intended for bootstrap purposes on little- endian systems. They should be replaced with assembly language versions as soon as possible.
1993-08-31 23:00:11 +04:00
#endif
}