[net.unix-wizards] Bug in inet

craig@SRN-VAX.ARPA (08/20/84)

From:  Craig Partridge <craig@SRN-VAX.ARPA>


    Compiled with -DDONTWORK (which produces a program conforming
to what Berkeley tells you to do) the following program doesn't work.
It gives the wrong answer on VAXen and core dumps on SUNs.

---------------------------------------------
/* program to show a bug */
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

#ifdef DONTWORK
#include <arpa/inet.h>
#else
extern char *inet_ntoa();
extern u_long inet_addr();
#endif

main()
{
/* pretty sure the address used is not critical */
printf("%s\n",inet_ntoa(inet_addr("128.11.0.0")));
}
__________________________________________________

Problem is that the compiler handles the structure in_addr, differently
from a u_long, and while the include file <arpa/inet.h> declares inet_addr
as a struct in_addr (a portable??? network address structure), in fact it
returns a u_long.  The different declarations produce different code, and
the one for struct in_addr is wrong.

The best solution is probably to just edit <arpa/inet.h> and redeclare
inet_addr to be a u_long and forget this structure farce.

Craig Partridge
craig@bbn-unix
{ihnp4,wjh12,{and others}}!bbncca!craig

essick@uiucdcsb.UUCP (08/22/84)

#R:sri-arpa:-1262400:uiucdcsb:14900013:000:751
uiucdcsb!essick    Aug 22 08:49:00 1984

re: the clash between declarations of inet_addr() in the include file
	and in the actual routine.

I ran into this problem earlier this summer and figured I would be clever
about it and change the routine to return the appropriate type.

Boy was I in for a treat.  The gethost() functions in libc.a EXPECT
the difference between the two declarations and do tricks with casting
to get things right.

I figured at that point it was easier to just play games with casting
rather than change either the header file or the routine itself. While
not the solution I would have liked [it would be nice if they were
all consistent], I can now expect my code to run on all of the 4.2
systems which still have this mistake.

--Ray Essick, University of Illinois