Re: ASN.1 bit string alignment

["Neil Piercy" <Neil.Piercy () ipaccess com>]

Looking at the changes in packet-per.c, it looks like the changes were
deliberate to remove leading pads and return a tvb which had trailing
bits padded - which sounds reasonable to me: I suspect the tvb
bit-offset code assumes no leading bit pads: correct?

If so, it becomes just a display problem.

Given that the bit string is of arbitrary length, and not necessarily
interpreted as an integer, how would we _want_ the example below to be
displayed?

I think the basic problem is the attempt to display a bit string in hex
- would it be better to display it in binary (if say <=32 bits) and have
its (unpadded) integer value (hex or dec?) included too if small enough
- e.g.

dl-HFN: 0000000000000000000000100 (0x4) [bit length 25]

Neil

> -----Original Message-----
> From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-
> bounces () wireshark org] On Behalf Of Anders Broman
> Sent: 26 March 2010 20:53
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] ASN.1 bit string alignment
>
> Looks like a bug, please make a bug report and attach a sample trace.
> Regards
> Anders
>
> -----Original Message-----
> From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-
> bounces () wireshark org] On Behalf Of Neil Piercy
> Sent: den 22 mars 2010 19:31
> To: Developer support list for Wireshark
> Subject: [Wireshark-dev] ASN.1 bit string alignment
>
> In 1.0.x PER ASN.1 bit strings used to be padded in the MSBs, (e.g.
> extract from an RRC message):
>
> dl-HFN: 00000004 [bit length 25]
>
> Since 1.2.x they appear to be padded in the LSBs (e.g. the same
> extract):
>
> dl-HFN: 00000200 [bit length 25]
>
> The value carried in both cases above is meant to be 4.
>
> Is this a deliberate change?
>
> I know bit strings are of arbitrary length, therefore a "natural"
> representation is challenging, but I find the above counter-intuitive.
>
> Neil
>
>
>
>
>
> This message contains confidential information and may be privileged.
> If you are not the intended recipient, please notify the sender and
> delete the message immediately.
>
> ip.access Ltd, registration number 3400157, Building 2020, Cambourne
> Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
_______________________________________________________________________
> ____
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-
> request () wireshark org?subject=unsubscribe
_______________________________________________________________________
> ____
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-
> request () wireshark org?subject=unsubscribe






This message contains confidential information and may be privileged. If you are not the intended recipient, please 
notify the sender and delete the message immediately.

ip.access Ltd, registration number 3400157, Building 2020, 
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe