public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Nate Lawson <nate-Y6VGUYTwhu0@public.gmane.org>
To: "Moore, Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Alex Williamson <alex.williamson-VXdhtT5mjnY@public.gmane.org>,
	acpi-devel
	<acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: NO_RETURN_VALUE w/ 20040715
Date: Mon, 23 Aug 2004 14:26:35 -0700	[thread overview]
Message-ID: <412A610B.90300@root.org> (raw)
In-Reply-To: <37F890616C995246BE76B3E6B2DBE05501C71EF2-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>

I don't think that approach will be helpful.  Instead, I think it should 
be "if argument types differ and any arg is an integer, convert the 
other to an integer."  If not, error AE_TYPE.  We have something like 
this in FreeBSD where we found on older systems many methods that are 
supposed to return an integer returned a buffer instead.  So many that 
we added an automatic conversion for this to acpi_GetInteger().  Also, I 
found a system that uses a package of integers for _FDE instead a buffer 
of integers.

In summary, I've seen a lot of buffers used where integers were expected 
but never an integer expected to be converted to a buffer.

-Nate

Moore, Robert wrote:
> I will prototype this using the existing internal mechanisms for
> implicit object conversion.
> 
> However, I'm not sure how or if this statement will work as expected:
> 
> 
>>>>>If (LEqual (Local0, 0x00))
>>>>>{
> 
> 
> since Local0 is a buffer, 0x00 will be converted to a buffer before the
> compare.
> 
> 
> 
>>-----Original Message-----
>>From: Alex Williamson [mailto:alex.williamson-VXdhtT5mjnY@public.gmane.org]
>>Sent: Monday, August 23, 2004 1:34 PM
>>To: Moore, Robert
>>Cc: acpi-devel
>>Subject: RE: [ACPI] NO_RETURN_VALUE w/ 20040715
>>
>>Bob,
>>
>>  Great, I was looking through the history of the LEqual operator
> 
> across
> 
>>the ACPI specs and it got rather convoluted, this seems like a good
>>compromise.  Will there be a CA update to support this (preferably in
>>Linus' tree before 2.6.9 is tagged)?  I'd be happy to test on this box
>>if needed.  Thanks,
>>
>>	Alex
>>
>>On Mon, 2004-08-23 at 13:22 -0700, Moore, Robert wrote:
>>
>>>We are going to update the ACPI spec to something like this:
>>>
>>>*	For the following operators, the data type of the first operand
>>>dictates both the required type of the second operand and the type
> 
> of
> 
>>>the result object.  (The second operator is converted, if necessary,
> 
> to
> 
>>>match the type of the first operand.)
>>>    Concatenate
>>>    LEqual
>>>    LGreater
>>>    LGreaterEqual
>>>    LLess
>>>    LLessEqual
>>>    LNotEqual



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

  parent reply	other threads:[~2004-08-23 21:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-23 20:46 NO_RETURN_VALUE w/ 20040715 Moore, Robert
     [not found] ` <37F890616C995246BE76B3E6B2DBE05501C71EF2-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-08-23 21:26   ` Nate Lawson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-08-23 22:05 Moore, Robert
2004-08-23 21:54 Moore, Robert
     [not found] ` <37F890616C995246BE76B3E6B2DBE05501C72022-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-08-23 22:01   ` Nate Lawson
2004-08-23 20:22 Moore, Robert
     [not found] ` <37F890616C995246BE76B3E6B2DBE05501C71E7A-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-08-23 20:34   ` Alex Williamson
2004-08-20 21:07 Moore, Robert
     [not found] ` <37F890616C995246BE76B3E6B2DBE05501C19B93-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-08-20 23:17   ` Alex Williamson
2004-08-20 20:31 Moore, Robert
2004-08-20 20:11 Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=412A610B.90300@root.org \
    --to=nate-y6vguytwhu0@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=alex.williamson-VXdhtT5mjnY@public.gmane.org \
    --cc=robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox