sys/socket.h __BSD_VISIBLE
I've come across a piece of software that defines __POSIX_C_SOURCE which
causes __BSD_VISIBLE to bet set to 0.
In sys/socket.h if __BSD_VISIBLE is 0 sys/_types.h is included instead
of sys/types.h. This is fine however in three cases we reference
u_int8_t (2) and u_int64_t (1) which requires sys/types.h.
If we change these to __uint8_t and __uint64_t they work with either
types.h or _types.h. Does this make sense? Will there be any side
effects?
--
James Turner
Index: sys/sys/socket.h
===
RCS file: /cvs/src/sys/sys/socket.h,v
retrieving revision 1.82
diff -u -p -r1.82 socket.h
--- sys/sys/socket.h15 Sep 2012 00:47:08 - 1.82
+++ sys/sys/socket.h2 Apr 2013 02:40:46 -
@@ -186,7 +186,7 @@ struct splice {
* addresses.
*/
struct sockaddr {
- u_int8_tsa_len; /* total length */
+ __uint8_tsa_len;/* total length */
sa_family_t sa_family; /* address family */
charsa_data[14];/* actually longer; address value */
};
@@ -204,10 +204,10 @@ struct sockaddr {
* occurrences (including header file) to __ss_len.
*/
struct sockaddr_storage {
- u_int8_tss_len; /* total length */
+ __uint8_t ss_len; /* total length */
sa_family_t ss_family; /* address family */
unsigned char __ss_pad1[6]; /* align to quad */
- u_int64_t __ss_pad2; /* force alignment for stupid compilers
*/
+ __uint64_t __ss_pad2; /* force alignment for stupid compilers
*/
unsigned char __ss_pad3[240]; /* pad to a total of 256 bytes */
};
Re: sys/socket.h __BSD_VISIBLE
On Mon, Apr 01, 2013 at 22:54, James Turner wrote: I've come across a piece of software that defines __POSIX_C_SOURCE which causes __BSD_VISIBLE to bet set to 0. In sys/socket.h if __BSD_VISIBLE is 0 sys/_types.h is included instead of sys/types.h. This is fine however in three cases we reference u_int8_t (2) and u_int64_t (1) which requires sys/types.h. If we change these to __uint8_t and __uint64_t they work with either types.h or _types.h. Does this make sense? Will there be any side effects? I believe the correct type would be uint8_t or uint64_t. Those should be visible (I think). A quick look indicates that maybe they aren't, so that won't work. There won't be any side effects from using __uint64_t, but I think of it more like a building block for another type. Not to be used directly. I would like to believe that posix allows int64_t to be visible after including socket.h since they use it in their sample sockaddr_storage implementation, but the text doesn't seem to allow that. Maybe the __uint64_t type is the way to go.
Re: sys/socket.h __BSD_VISIBLE
On Mon, Apr 01, 2013 at 20:40, Philip Guenther wrote: There won't be any side effects from using __uint64_t, but I think of it more like a building block for another type. Not to be used directly. Disagree. Indeed, I just committed James's diff (plus one additional change to CMSG_DATA()). My (admittedly weak) rationale is that if a struct contains a field, I would like to be able to declare local variables of the same type as that field. And I don't want my local variables in my code to be using __int types.
Re: sys/socket.h __BSD_VISIBLE
On Mon, Apr 1, 2013 at 9:06 PM, Ted Unangst t...@tedunangst.com wrote: My (admittedly weak) rationale is that if a struct contains a field, I would like to be able to declare local variables of the same type as that field. And I don't want my local variables in my code to be using __int types. In the specific cases here, sa_len and __ss_pad2, the answers are no, you should *not* be modelling variables on those!. sa_len should only be used by code using routing-domain sockets, and there are macros for setting it after you've updated the socket, and you shouldn't be modelling your own data structures after what routing sockets do on the wire. Reusing the type of an double-underbar-prefix *padding* member gets you hurt in back alleys. Note that the stuff that it makes sense to copy into your own data structures does use real, public types. Philip Guenther
