Date: Sun, 10 Mar 2002 03:58:34 -0500 From: Alan Eldridge <alane@geeksrus.net> To: mike@FreeBSD.org Cc: freebsd-bugs@FreeBSD.org, FreeBSD Bugs <freebsd-gnats-submit@FreeBSD.org> Subject: Re: bin/35071: include/arpa/inet.h broken: must include <netinet/in.h> Message-ID: <20020310085834.GA40177@wwweasel.geeksrus.net> In-Reply-To: <200203100757.g2A7vHc86077@freefall.freebsd.org> References: <200203100757.g2A7vHc86077@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 09, 2002 at 11:57:17PM -0800, mike@FreeBSD.org wrote: >Synopsis: include/arpa/inet.h broken: must include <netinet/in.h> ><arpa/inet.h> and <netinet/in.h> will never conform to SUSv2 in the >4.x branch, but 5.0-RELEASE will resolve this issue. The patch >submitted in this PR takes advantage of which I consider to be >mistakes in SUSv2 and other standards, which allow for sloppy >implementations. Needless to say, this is not the approach taken in >5.0. Perhaps I should have been more explicit: there is a missing structure definition that provokes "incomplete type" warnings (at best) and compilation errors (in cases where the code include the header actually uses 'struct in_addr'). The fact that including a system header will unconditionally provoke compiler warnings is sufficient for me to label that header "broken". (In the 20+ years that I have been doing "C" development, I have seen very few occasions where a compilation warning was truly innocuous; at best, they indicate sloppy coding practice.) AFAIK, other Unixes manage to get this right. There is code out there, in real applications, that assumes (IMO, correctly) that it will get 'struct in_addr' with "include <arpa/inet.h>". I had to recently make patches to wget's CVS tree because of this issue, for example. Including <netinet/in.h> was the easies, and least intrusive method to fix this; it is by no means the most elegant, nor was it advertised as such. I don't disagree that a different solution would be preferable to the one proposed; I do strongly disagree that no solution should be forthcoming until 5.0-RELEASE. A temporary fix to 4.x, pending the "real" one in 5.0, is better than none at all. -- Alan Eldridge "Dave's not here, man." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020310085834.GA40177>