I proposed changing default compilation flags to get to a sane environment that is closer to POSIX by default over a year ago. That proposal was not well received. Apparently people are happier to continue with our broken defaults in order to avoid making life harder for folks who've written code to the legacy API.
Basically the idea was that it is better to inconvenience new users and be POSIX incompatible by default than to break the legacy API. (Even if it is just changing defaults.) Sent from my iPhone > On May 25, 2016, at 5:06 AM, Richard PALO <[email protected]> wrote: > > Le 25/05/16 09:18, Alexander Pyhalov a écrit : >> Hi. >> It seems illumos/Solaris is the only OS which doesn't have msg_control >> and msg_controllen in struct msghdr by default. So, code like this (this >> time taken from scrren), fails. >> >> struct sockaddr_un a; >> struct msghdr msg; >> struct iovec iov; >> char control[1024]; >> >> len = sizeof(a); >> debug("Ha, there was someone knocking on my socket??\n"); >> if ((ns = accept(ns, (struct sockaddr *) &a, (void *)&len)) < 0) >> { >> Msg(errno, "accept"); >> return; >> } >> >> p = (char *) &m; >> left = sizeof(m); >> bzero(&msg, sizeof(msg)); >> iov.iov_base = &m; >> iov.iov_len = left; >> msg.msg_iov = &iov; >> msg.msg_iovlen = 1; >> msg.msg_controllen = sizeof(control); >> msg.msg_control = &control; >> >> I know I can define _XPG4_2 or experiment with _XOPEN_SOURCE, but it >> seems ugly. Is it because of some standard requirements or just >> historical artifact? Can we somehow alleviate this issue? > > it is ugly... would be nice to do away with the issue! > > Note the comment in the linux sys/socket.h: >> /* >> * As we do 4.4BSD message passing we use a 4.4BSD message passing >> * system, not 4.3. Thus msg_accrights(len) are now missing. They >> * belong in an obscure libc emulation or the bin. >> */ > > we have 4.3 compat in omsghdr. > > there are actually quite few gate related uses of the non _XPG4_2 nor _KERNEL > flavour > > libresolv2/common/bsd/writev.c -- is already overkill and doesn't need to > reference it > libpapi-lpd/common/ -- looks like it's in need of an update anyway > libslp/clib/ -- can also be updated > > libbc may or may not be problematic, to check out. > > this is in the ballpark of bite-size... > > -- > Richard PALO > ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
