sys/socket.h __BSD_VISIBLE

2013-04-01 Thread James Turner
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

2013-04-01 Thread Ted Unangst
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

2013-04-01 Thread Philip Guenther
On Mon, Apr 1, 2013 at 8:35 PM, Ted Unangst t...@tedunangst.com wrote:

 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.


Disagree.  Indeed, I just committed James's diff (plus one additional
change to CMSG_DATA()).

(Thanks, James!)

Philip Guenther


Re: sys/socket.h __BSD_VISIBLE

2013-04-01 Thread Ted Unangst
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

2013-04-01 Thread Philip Guenther
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