Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Dec 1998 19:45:23 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        bf20761@binghamton.edu (zhihuizhang)
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: typedef question and __P
Message-ID:  <199812041945.MAA28830@usr01.primenet.com>
In-Reply-To: <Pine.SOL.L3.93.981204115156.22469A-100000@bingsun1> from "zhihuizhang" at Dec 4, 98 11:57:25 am

next in thread | previous in thread | raw e-mail | index | archive | help
> In file isa/isa_device.h, I find two defitions:
> 
> typedef void inthand_t __P((u_int cs, u_int ef, u_int esp, u_int ss));
> typedef void inthand2_t __P((int unit));
> 
> Usually, typedef takes the format as:
> 
> typedef newtypename existingtype  (note: only two terms follows typedef)
> 
> It gives a new name (but does not create a new type) to an existing type.
> 
> My question is how come there are three terms following typedefs above and
> where is __P defined.  Are they GNU C extenstions?

No.  They are glue to allow the kernel to be compiled with a standard
K&R compiler, like you might find on a platform not yet running BSD,
and to which the GNU tools haven't yet been ported, and for which you
are not personally interested in becoming the maintainer of a compiler
port for 3 years in order to satisfy the terms of the GPL.

In other words, machines most likely to want a BSD port because an
OS refresh from their original vendor isn't ever going to happen.
Like a Microport UNIX or Cubix or old Altos box, for which the GNU
binutils have given up support, or like the PARISC or DEC Alpha,
where the GNU tools are vastly inferior to the instruction reordering
compilers available from the vendor.

In any case, the glue is defined in:

	/usr/include/sys/cdefs.h

This file also contains wrappers for K&R vs. ANSI use of const, signed,
and volatile, whish are necessary to support the arbitrary alias
assumptions for loop unrolling and register promotion of non-local
references, which the compiler could determine were not locally
scoped, but doesn't bother to do so.  There is also BSD support
for the non-standard inline, dead, dead2, pure, pure2, unused,
__weak_reference, __warn_references, and the __IDSTRING construct
(to keep the compiler from bitching about unreferenced identification
strings, as in SCCS ID's, etc.).

It also defines mechanisms for identifier concatenation (K&R x/**/y vs.
ANSI x ## y) and conversion of manifest values to strings (K&R "x" vs.
ANSI #x).


Finally, it defines conditinals for wrapping function references,
namely __BEGIN_DECLS and __END_DECLS, such that the system header
files can be included by both C and C++ source, and still function
(this last is a result of needing semantic sugar to prevent symbol
decoration of external C function references by C++ code, since
the C++ compiler would otherwise decorate the symbol.  Mostly this
is a reaction to compiler writers to lazy to write smarter linkers
and/or use object formats that allow attribution of symbols outside
of incursions into the symbol namespace, so even though ELF doesn't
need this, the GNU toolchain for C++ still engages in decoration
instead of attribution).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812041945.MAA28830>