Re: [Xen-devel] [patch] [3/3] dom0_ops explicitly sized types

[Anthony Liguori <aliguori@xxxxxxxxxx>]

Ian Campbell wrote:
> > If you use __u64, you'd need to include some header defining what __u64
> > is, so you're requiring another header anyways. You might as well use
> > the standard stdint.h rather than inventing your own.
> >     
> As I understand it the issue is that the C spec makes the __* namespace
> available for the kernel to pollute and reserves the non-prefixed
> namespace for application usage. (Single underscore is for compiler or
> libc internals or something).
>   
The relevant portions of the spec are:


     7.1.3 Reserved identifiers



      [#1] Each header declares or defines all identifiers  listed
      in  its  associated  subclause,  and  optionally declares or
      defines identifiers listed in its associated future  library
      directions   subclause  and  identifiers  which  are  always
      reserved either for  any  use  or  for  use  as  file  scope
      identifiers.

         - All identifiers  that  begin  with  an  underscore  and
           either  an  uppercase  letter or another underscore are
           always reserved for any use.

         - All identifiers  that  begin  with  an  underscore  are
           always  reserved  for  use as macros and as identifiers
           with file scope in  both  the  ordinary  and  tag  name
           spaces.

         - Each macro name in  any  of  the  following  subclauses
           (including  the  future library directions) is reserved
           for use as specified if any of its  associated  headers
           is  included;  unless  explicitly stated otherwise (see
           7.1.8 <http://www.vmunix.com/%7Egabor/c/draft.html#7.1.8>).

         - All identifiers with external linkage  in  any  of  the
           following  subclauses  (including  the  future  library
           directions) are always reserved for use as  identifiers
           with external linkage.133

         - Each identifier with file scope listed in  any  of  the
           following  subclauses  (including  the  future  library
           directions) is reserved for use  as  macro  and  as  an
           identifier  with  file  scope in the same name space if
           any of its associated headers is included.

      [#2] No other identifiers  are  reserved.   If  the  program
      declares  or  defines an identifier that is reserved in that
      context (other than as allowed by 7.1.8 
<http://www.vmunix.com/%7Egabor/c/draft.html#7.1.8>),  the  behavior  is
      undefined.134


It's pretty clear that __* names are reserved.  The kernel is wrong 
here.  The best explanation I've gotten is "egocentrism" :-)
Regards,

Anthony Liguori

> An application which has not included stdint.h itself can expect to use
> uint64_t however it wishes, including making it a struct, a function or
> even something as gross as a 32 bit signed int etc. Exporting some other
> idea of what uint64_t should be via the kernel headers breaks this. I
> guess this is more of a problem when a kernel header gets indirectly
> included -- presumably an app which includes a kernel header directly
> knows what it is doing.
>
> Anyway, regardless of any opinion expressed here the Linux gatekeepers
> will no doubt insist on __uN. We might as well do it now as change it
> later.
>
> Ian.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>   
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel