From owner-freebsd-current Tue Aug 27 14:55:12 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7087037B400 for ; Tue, 27 Aug 2002 14:55:09 -0700 (PDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 937BD43E72 for ; Tue, 27 Aug 2002 14:55:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0470.cvx21-bradley.dialup.earthlink.net ([209.179.193.215] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 4.10) id 17joIf-0000Y3-00; Tue, 27 Aug 2002 14:55:01 -0700 Message-ID: <3D6BF4E6.9B441A6B@mindspring.com> Date: Tue, 27 Aug 2002 14:53:42 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Moore, Robert" Cc: 'Mitsuru IWASAKI' , yb@sainte-barbe.org, acpi-jp@jp.FreeBSD.org, current@freebsd.org, "Grover, Andrew" Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Moore, Robert" wrote: > Well, the *real* problem is that there is no Return AML opcode in the > control method and the interpreter therefore does not return a value. > > However, to answer your question with a question: > > Would you ask a C compiler, or any other compiler for that matter, to > actually *GUESS* at what you had intended to be the return value of a > function? Is this a trick question? If I had to write my source code to read-only media, with no way to tell whose compiler was going to be used on it, and had no way to fix it afterwards, I think the answer would have to be "yes". 8-) 8-). FWIW, there's historical precedent for this: the DEC VAX/VMS C compiler would imply semicolons for the programmer that forgot them, and a couple of other similar "fixups", issue a warning, but the resulting code would run "as the programmer most likely intended", rather than not generating a running program at all. The issue here is one of syntactical vs. grammatical ambiguity; if the only choices are between two possible outcomes, and one of them is a failure to operate at all, while the other is to operate, but potentially incorrectly. The upshot is that ir can't hurt, and it might help: assumption? no yes --------------------------------- grammar error | FAILS | FAILS | ------------------------------------------------| syntax error | FAILS | WORKS | ------------------------------------------------- So the worst possible outcome in the failure case is that it fails -- which it already does, without the assumption -- and the best possible outcome is that it succeeds when it wouldn't have. "Anything that works is better than anything that doesn't" -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message