Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Aug 2002 14:53:42 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        "Moore, Robert" <robert.moore@intel.com>
Cc:        'Mitsuru IWASAKI' <iwasaki@jp.FreeBSD.org>, yb@sainte-barbe.org, acpi-jp@jp.FreeBSD.org, current@freebsd.org, "Grover, Andrew" <andrew.grover@intel.com>
Subject:   Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
Message-ID:  <3D6BF4E6.9B441A6B@mindspring.com>
References:  <B9ECACBD6885D5119ADC00508B68C1EA0D19B71B@orsmsx107.jf.intel.com>

next in thread | previous in thread | raw e-mail | index | archive | help
"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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D6BF4E6.9B441A6B>