svn commit: r228495 - head/sys/sys

[David Schultz]

On Thu, Dec 15, 2011, Ed Schouten wrote:
> Hello Bruce,
> 
> * Bruce Evans <brde at optusnet.com.au>, 20111215 15:12:
> >    - recently broken for K&R since it now uses signed instead of __signed
> >    - broken for longer for K&R and C90 since it uses long long.  In working
> >      versions, the __int64_t declarations were hacked for 32-bit machines
> >      on to make them compile (but not work).  Non-hacked versions should
> >      simply not declare the 64-bit types if the compiler doesn't support
> >      them.
> 
> Well, the dependency is circular, as <machine/_types.h> depends on
> <sys/cdefs.h> as well, so that's not a real solution.
> 
> This is a bit blunt, but maybe we should simply use "unsigned long"
> there, under the assumption that on all architectures we support it is
> equal in size, and if not likely big enough to store the result.
> 
> > CTASSERT() has regressed for compilers that don't support __COUNTER__,
> > since it uses this.  Previously:
> > - CTASSERT() never worked for K&R compilers, since it uses C90 token pasting
> > - CTASSERT() worked for all C90 and later compilers.
> 
> Yes. I am considering merging back the __COUNTER__ fix to FreeBSD 9
> after it has been released, so it shouldn't be too bad. Basically we
> have to make a trade-off:
> 
> - Make it possible to use CTASSERT() and _Static_assert() in more places
>   throughout the tree (headers), or
> - support CTASSERT() and _Static_assert() for non-default compilers that
>   are older than GCC 4.3.
> 
> I suspect that if people switch to non-default compilers to build
> FreeBSD sources, they aren't doing it because they want to use an older
> version of GCC.

It's useful to have standard headers that don't blow up in C90
mode, but my sense is that we ought to be beyond caring about K&R
C compilers.  (FWIW, my first C compiler was a pre-ANSI compiler
from the 80's, and it still supported the features at issue here.)