Mark Kettenis on Sat, Jun 07 2025:
> The description of the comparison operators isn't very clear as it
> suggests that only the 2nd source operand will be converted. ut it
> also doesn't say that the 1st source operand must be interger, buffer
> or string. Only that it must evaluate to one of those types.
I have a whole sequence of notes where one bit of the spec seems to
imply one thing and then another bit changes the whole story. In my
report I quoted what I believe to be the relevant normative parts.
For the sake of brevity, I didn't quote the part that actually convinced
me I had gotten it right, the Concatenate example. Here it is, slightly
edited for clarity:
Store (Buffer (1) {}, Local0)
Name (ABCD, Buffer (10) {1, 2, 3, 4, 5, 6, 7, 8, 9, 0})
CreateDWordField (ABCD, 2, XYZ)
Name (MNOP, "1234")
Concatenate (XYZ, MNOP, Local0)
The Concatenate operator can take an Integer, Buffer or String
for its first two parameters and the type of the first parameter
determines how the second parameter will be converted. In this
example, the first parameter is of type Buffer Field (from the
CreateDWordField operator). [It should be converted to Integer,
Buffer or String.] According to the table Object Conversion Rules
the highest priority conversion is to Integer. Therefore, both
objects [(XYZ and MNOP)] will be converted to Integers...
I.e. they want us to implicitly convert to one of the types allowed for
the first argument, and then convert the second to that. Makes perfect
sense, but man did they take a lot of words to say it.
> So your interpretation makes sense. And the patch looks good. I have
> one minor nit. I'm not a big fan on assignments within if statements
> so I propose the diff below instead.
Perfectly fair; in fact I often avoid them myself.
pesco/Sven
