[DFDL-WG] Clarification: zero-bit-long integer parses to value 0, or parse-error or?

[Mike Beckerle]

Thanks, I was actually thinking this was in a table somewhere also, and I
did find it.

Table 22 says the minimum length for a binary signed integer is 2 bits, for
unsigned 1.

So definitely a parse error, and symmetrically, and unparse error if length
is 0 for an int/unsignedint when unparsing.

Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense |
www.owlcyberdefense.com
Please note: Contributions to the DFDL Workgroup's email discussions are
subject to the OGF Intellectual Property Policy
<http://www.ogf.org/About/abt_policies.php>



On Thu, Mar 19, 2020 at 7:28 PM Steve Hanson <smh at uk.ibm.com> wrote:

> This is covered by section 9.3.2 (establishing representation) and section
> 9.5 (evaluation order).
>
> Your integer is not nillable, so can't have nil rep. Assuming compliance
> with dfdl:emptyValueDelimiterPolicy it therefore has empty representation.
> Assuming this is a local element with minOccurs-=1 implicitly, and no
> default value, it is a parsing error. Section 9.5 says the assert will
> never be executed as it is lower down the evaluation order.
>
> Regards
>
> Steve Hanson
>
> IBM Hybrid Integration, Hursley, UK
> Architect, *IBM DFDL*
> <http://www.ibm.com/developerworks/library/se-dfdl/index.html>
> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
> *smh at uk.ibm.com* <smh at uk.ibm.com>
> tel:+44-1962-815848
> mob:+44-7717-378890
> Note: I work Tuesday to Friday
>
>
>
> From:        Mike Beckerle <mbeckerle.dfdl at gmail.com>
> To:        DFDL-WG <dfdl-wg at ogf.org>
> Date:        19/03/2020 22:50
> Subject:        [EXTERNAL] [DFDL-WG] Clarification: zero-bit-long integer
> parses to value 0, or parse-error or?
> Sent by:        "dfdl-wg" <dfdl-wg-bounces at ogf.org>
> ------------------------------
>
>
>
>
> Consider:
> <*xs**:element **name**="spare" **dfdl**:length**="{ $tns:WordPaddingBits
> }"*>
>  <*xs**:simpleType* *dfdl**:lengthKind**="explicit"*>
>   <*xs**:annotation*>
>    <*xs**:appinfo **source**="**http://www.ogf.org/dfdl/*
> <http://www.ogf.org/dfdl/>*"*>
>      <*dfdl**:assert **test**="{ . eq 0 }" */>
>    </*xs**:appinfo*>
>   </*xs**:annotation*>
>   <*xs**:restriction **base**="xs:unsignedInt"*>
>    <*xs**:enumeration **value**="0" */>
>   </*xs**:restriction*>
>  </*xs**:simpleType*>
> </xs:element>
>
> Now, suppose the variable tns:WordPaddingBits has value 0.
> So this padding integer will be length 0 (this binary data with
> lengthUnits bits).
> Currently, Daffodil gives a runtime SDE on this. The assert test
> expression complains that "." has no value.
> I would claim this should either provide a value of 0 for this integer, or
> it should be a parse error because you must have at least 1 bit.
>
> Thoughts?
> Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense |
> *www.owlcyberdefense.com* <http://www.owlcyberdefense.com> (Tresys is now
> part of Owl)
> Please note: Contributions to the DFDL Workgroup's email discussions are
> subject to the *OGF Intellectual Property Policy*
> <http://www.ogf.org/About/abt_policies.php>
>
> --
>  dfdl-wg mailing list
>  dfdl-wg at ogf.org
>  https://www.ogf.org/mailman/listinfo/dfdl-wg
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20200320/5e8a6fb4/attachment-0001.html>