[
https://issues.apache.org/jira/browse/DAFFODIL-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17352734#comment-17352734
]
Steve Lawrence commented on DAFFODIL-2473:
------------------------------------------
Agreed with Mike.
But one thing we need to specify is what happens if the two argument types for
andBits/orBits/xorBits are different. For example, xs:int and xs:long have
different widths (32 vs 64 bits), so what is the result if we attempt one of
these bitwise functions on them? Everything is strongly typed, so we must have
a rule to figured out what the resulting type is.
Maybe the obvious option is to say that the result is the larger of the two
types. So say we have something like this:
{code}
dfdlx:andBits(xs:int(3), xs:long(5))
{code}
The larger of the two types is xs:long, so we implicitly cast the xs:int(3) to
an xs:long(3), and then andBits the xs:long(3) and xs:long(5), which results in
xs:long(1). Seems fine.
But it is maybe less obvious if the different arguments are signed vs unsigned.
For example, what should the result be of this:
{code}
dfdlx:andBits(xs:unsignedLong(-1), xs:long(1))
{code}
Is the result an xs:unsignedLong or an xs:long? I'm not sure if there's an
obvious answer. We could look at what other languages do, but maybe we should
just be strict and and assert that the types must be the same? So both examples
above would not be allowed?
> Need bit-wise AND, OR, NOT, and shift operations
> ------------------------------------------------
>
> Key: DAFFODIL-2473
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2473
> Project: Daffodil
> Issue Type: New Feature
> Components: Back End, Front End
> Affects Versions: 3.0.0
> Reporter: Mike Beckerle
> Assignee: Samarth Sah
> Priority: Major
>
> There are a number of data representations DFDL cannot handle because it
> cannot manipulate numbers with sufficient flexibility in expressions.
> We need AND, OR, NOT, maybe XOR, and shift left, shift right, and probably
> arithmetic shift right (which does sign-extension of signed numbers). We
> should add functions for the whole set of them.
> On signed numbers with specific sizes (long, int, short, byte) these should
> behave as if the data was binary in 2s complement representation, i.e., as if
> the most-significant-bit was playing the role of 2s complement sign.
> These operations should all be undefined (Schema Def Error) on decimal,
> integer, and non-negative integer values, as well as float and double.
> Specifically, these operations are defined on long and its subtypes, and
> unsignedLong and its subtypes only.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
