Hi Thomas and Alexey
See my comments below. I remember asking this several years ago
from Tobies and we didn't find any mention on this in the standard.
// Antti Hyrkkänen @ Plenware
//
www.plenware.fi/en
>
Original Message
> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> [
This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Thomas Deiss
> Sent: 15. marraskuuta 2007 16:52
> To:
This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: TRI : padding within BinaryString
>
> Hello together,
>
> Part 5 (TRI) of the standard defines Binarystring. A binarystring in the
> C language mapping is defined as a structure containing a pointer to
> char (to hold the actual data) and an integer number to indicate the
> number of bits. See the definitions below, taken from the standard:
>
> typedef struct BinaryString
> {
> unsigned char* data;
> long int bits;
> void* aux;
> } BinaryString;
>
> NOTE 1: data is a non null terminated string.
> NOTE 2: bits is the number of bits used in data. bits value -1 is used
> to denote omitted value.
> NOTE 3: The aux field is for future extensibility of TRI functionality.
>
> The question came up whether data is padded to the left or to the right
> in case that the number of bits is not a multiple of 8. I have not been
> able to find a statement in the standard answering this question. Did I
> miss something? Or how should padding be done?
Should data that does not have length 8 x n bits be supported at all?
If you look at the Java mapping of TriMessageType, it does not have a
method with which you could get the bit length.. It deals with full
bytes only I think. If Java does not have this, should C have either?
// TRI IDL TriMessageType
package org.etsi.ttcn.tri;
public interface TriMessage {
public byte[] getEncodedMessage();
public void setEncodedMessage(byte[] message);
public boolean equals(TriMessage message);
}
What comes to the left and right, if I remember right Tau had the padding
3 years ago on the MSB side of the byte.. so it was on the "left" side.
Telelogic people can correct me if I'm wrong.
> Alexey Wrote:
> Do you mean (a) padding in the beginning or in the end of the unsigned
> char* buffer, or do you mean (b) padding in the leftmost or the
> rightmost bits of the last octet of this buffer?
[snip]
> Now should the padding be in the leftmost or in the rightmost bits of
> the last octet? Usually bits are ordered from left to right, so
> according to common practice padding should be in the rightmost (least
> significant) bits.
If you want to read the bits as bytes, and if the padding is done with
zero bits (this not required by the standard though), and you have the
padding on the MSB, then you can get the right bit "value" of the last
byte _without_ shifting its bits from MSB to LSB by the padding amount,
so that is kind of handy.. But does one really want to know or interpret
the "value" of the last bits, as they don't need to mean anything when
taken out of context of the full bit string.
I would personally go for the padding on LSB side on the byte as it
somehow feels more natural to think.
What feels more natural I think depends one how you have used to think
bytes in memory. If you draw your memory dump from left to right and
top to bottom with the address increasing in that order, then the bits
look as consecutive region when padding is in the LSB of the last byte,
the byte that is in the highest address.
But if you draw the memory dump from right to left and bottom to top
with the address increasing in that order, then padding in the MSB
of the last byte (again in the highest address) might feel more natural.
// Antti Hyrkkänen @ Plenware
//
www.plenware.fi/en <
www.plenware.fi/en>
________________________________
From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [
This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Alexey Mednonogov
Sent: 16. marraskuuta 2007 10:06
To:
This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TRI : padding within BinaryString
Hi,
Do you mean (a) padding in the beginning or in the end of the unsigned char* buffer, or do you mean (b) padding in the leftmost or the rightmost bits of the last octet of this buffer?
If (a), I would say adding padding to the beginning of the buffer will greatly and unnecessarily complicate data processing, so it should be in the end of the buffer according to common sense (one of the variants of case (b) then).
Now should the padding be in the leftmost or in the rightmost bits of the last octet? Usually bits are ordered from left to right, so according to common practice padding should be in the rightmost (least significant) bits.
Hope this helps,
Alexey
Thomas Deiss <
This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:
Hello together,
Part 5 (TRI) of the standard defines Binarystring. A binarystring in the
C language mapping is defined as a structure containing a pointer to
char (to hold the actual data) and an integer number to indicate the
number of bits. See the definitions below, taken from the standard:
typedef struct BinaryString
{
unsigned char* data;
long int bits;
void* aux;
} BinaryString;
NOTE 1: data is a non null terminated string.
NOTE 2: bits is the number of bits used in data. bits value -1 is used
to denote omitted value.
NOTE 3: The aux field is for future extensibility of TRI functionality.
The question came up whether data is padded to the left or to the right
in case that the number of bits is not a multiple of 8. I have not been
able to find a statement in the standard answering this question. Did I
miss something? Or how should padding be done?
Best regards
Thomas
