From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nate Lawson Subject: Re: NO_RETURN_VALUE w/ 20040715 Date: Mon, 23 Aug 2004 14:26:35 -0700 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: <412A610B.90300@root.org> References: <37F890616C995246BE76B3E6B2DBE05501C71EF2@orsmsx403.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <37F890616C995246BE76B3E6B2DBE05501C71EF2-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org> Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: "Moore, Robert" Cc: Alex Williamson , acpi-devel List-Id: linux-acpi@vger.kernel.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