svn commit: r194538 - head/sys/sys

[Bruce Evans]

On Tue, 23 Jun 2009, David Schultz wrote:

> On Wed, Jun 24, 2009, Kostik Belousov wrote:
>> On Tue, Jun 23, 2009 at 06:12:48PM -0400, David Schultz wrote:

>>> [... excessive quoting deleted]

>>> Applications are not supposed to use such symbols, but we use them
>>> pervasively in system headers specifically to avoid conflicting
>>> with symbols an application might define.  (Effectively, we
>>> consider system headers to be part of the language implementation.)
>>
>> My interpretation is that we use freestanding environment for the kernel,
>> and appropriate requirements shall be fullfilled by kernel code.

Freestanding reserves fewer symbols for the implementation.  Perhaps this
mainly affects library symbols, so we can use printf(9) without having
pure namespace conflicts with printf(3).

> If that's the case, then how do you propose we cope with the
> boilerplate preface to virtually every header file, i.e., like the
> following?
>
> 	#ifndef _SYS_PRIV_H_
> 	#define _SYS_PRIV_H_

Use he reserved namespace where needed only.  This doesn't include the
names of system's own macros and variables, at least at the top
level (lower level declarations need some protection, and ones used
in application headers like __size_t need to be in the implementation
namespace).

Normal spelling for spare struct members is s_sparefoo where 's' is
short for the struct name.  struct siginfo in sys/signal.h uses __spare__
(without even the si prefix :-().  Even this shouldn't be an exception.
Names beginning with si_ are reserved if <signal.h> is included, and
such a name should be used for the spare field too.

Bruce