From owner-freebsd-hackers Sun Oct 5 16:16:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA15559 for hackers-outgoing; Sun, 5 Oct 1997 16:16:41 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from usr05.primenet.com (tlambert@usr05.primenet.com [206.165.6.205]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA15554 for ; Sun, 5 Oct 1997 16:16:35 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA22821; Sun, 5 Oct 1997 16:16:25 -0700 (MST) From: Terry Lambert Message-Id: <199710052316.QAA22821@usr05.primenet.com> Subject: Re: devfs / cdevsw To: mike@smith.net.au (Mike Smith) Date: Sun, 5 Oct 1997 23:16:24 +0000 (GMT) Cc: mdean@best.com, julian@whistle.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199710040801.RAA00530@word.smith.net.au> from "Mike Smith" at Oct 4, 97 05:31:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > What does __P() do to a function declaration? I see it in the lkm examples. > > And also in .h files for c library calls apparently (pointing?) to the > > kernel syscalls. > > It's archaic junk left over from the days of pre-ANSI compilers. Use > it if you are adding to an existing source file (ie. maintain > consistency), but do not use it in new code. Unless you want the code to be portable to archaic pre-ANSI compilers, either becuase you own an older system, or you want someone who owns an older system to someday be able to use your code. It's a result of the gratuitous addition of prototypes to function declarations, really. A object file format that contained argument attribution for function arguments (unlike C++ symbol munging) would have spared us the need to declare the functions as prototypes, and would still have caught prototype forward declaration vs. function declaration mismatches at link time, as well as catching usage without a forward declaration prototype in scope. Ideally, you would delay actual code generation to link time, and save quads (or similar intermediate compilatation data) in the object files. This would, at the same time, have solved the "near/far" problem, since the memory reference could have been resolved to a near or far call at code generation time. Basically, compiler writers are lazy, even though compiler users outnumber them 1000 or more to 1. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.