|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
|
Leading 0 where forbidden after a brief
discussion.
As for unlikely to be used - I could argue for the
contrary - as in the examples I gave in a previous notes.
Many string copied from humanly readable documents
tend to be decimal-encoded.
Julo
|
Here's the heart of what I dislike about decimal-encoded binary strings:
how do you convey the length of the binary string when you have leading
zero bits?
-14 says:
"When used to encode binary strings decimal constants have an implicit
byte-length that is the minimum number of bytes needed to represent the
base2 encoding of the decimal number."
How do leading zeros impact the "base2 encoding .."?
Consider "012". Obviously the number is 12. The question is how many bytes
are in the binary string? Is it one, since a number of three decimal digit
numbers fit in one byte (up to "255"), or is it two bytes in the string
since other three-decimal-digit numbers won't fit in one byte ("256"
through "999")?
The spec isn't clear, at least not to me.
Ok, so one or two-byte strings aren't that likely. The problem though is
that all of the byte sizes don't line up nicely with decimal digits (since
2^x = 10^y only works for x=0, y=0 AFAIK).
Since we can't force that binary strings don't start with a zero-byte (or
two), we need to support some way of communicating how long such a string
is.
Two suggestions:
1) Rip out the decimal binary strings bit
2) Come up with a table saying if you have so many digits which contain
leading zeros, you have a binary string of so many bytes.
Examples:
String: Bytes in binary string:
00000000000000000012 8
00072057594037927935 8
00000000000000012 7
00281474976710655 7
000000000000012 6
001099511627775 6
0000000000012 5
0004294967295 5
0000000012 4
0016777215 4
00000012 3
00065535 3
00012 2
00255 2
The advantage of such a method is that you can easily force the right
number of leading zeros with printf format strings. For instance,
printf("%010d", an-int32-type) will do the right thing.
But we need to communicate that in the spec, and we don't.
Thoughts?
Take care,
Bill
P.S. I will be on vacation starting tomorrow through the weekend.
Bill,
There is an additional thing I don't like about decimal-encoded binary strings. We will have to put in support for a feature that is unlikely to be used. The only items defined as binary-values are CHAP and SRP binary strings which usually will be too long for decimal encoding anyway.
Take CHAP for instance. It C and R are defined as binary-values. R is 16 bytes so it can't be decimal encoded. C shorter than 8 bytes seems unlikely.
My preference would be to replace the definition of binary-value with the current definition of large-binary value, replace large-binary-value with binary-value (in 10.2 and 10.3) and get rid of regular-binary-value and large-binary-value.
Regards,
Pat
-----Original Message-----
From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
Sent: Tuesday, July 02, 2002 2:56 PM
To: ips@ece.cmu.edu
Subject: iSCSI: leading zeros and decimal-encoded binary strings
Here's the heart of what I dislike about decimal-encoded binary strings:
how do you convey the length of the binary string when you have leading
zero bits?
-14 says:
"When used to encode binary strings decimal constants have an implicit
byte-length that is the minimum number of bytes needed to represent the
base2 encoding of the decimal number."
How do leading zeros impact the "base2 encoding .."?
Consider "012". Obviously the number is 12. The question is how many bytes
are in the binary string? Is it one, since a number of three decimal digit
numbers fit in one byte (up to "255"), or is it two bytes in the string
since other three-decimal-digit numbers won't fit in one byte ("256"
through "999")?
The spec isn't clear, at least not to me.
Ok, so one or two-byte strings aren't that likely. The problem though is
that all of the byte sizes don't line up nicely with decimal digits (since
2^x = 10^y only works for x=0, y=0 AFAIK).
Since we can't force that binary strings don't start with a zero-byte (or
two), we need to support some way of communicating how long such a string
is.
Two suggestions:
1) Rip out the decimal binary strings bit
2) Come up with a table saying if you have so many digits which contain
leading zeros, you have a binary string of so many bytes.
Examples:
String: Bytes in binary string:
00000000000000000012 8
00072057594037927935 8
00000000000000012 7
00281474976710655 7
000000000000012 6
001099511627775 6
0000000000012 5
0004294967295 5
0000000012 4
0016777215 4
00000012 3
00065535 3
00012 2
00255 2
The advantage of such a method is that you can easily force the right
number of leading zeros with printf format strings. For instance,
printf("%010d", an-int32-type) will do the right thing.
But we need to communicate that in the spec, and we don't.
Thoughts?
Take care,
Bill
P.S. I will be on vacation starting tomorrow through the weekend.
On Tue, 2 Jul 2002 pat_thaler@agilent.com wrote:
> Bill,
>
> There is an additional thing I don't like about decimal-encoded binary
> strings. We will have to put in support for a feature that is unlikely
> to be used. The only items defined as binary-values are CHAP and SRP
> binary strings which usually will be too long for decimal encoding
> anyway.
>
> Take CHAP for instance. It C and R are defined as binary-values. R is
> 16 bytes so it can't be decimal encoded. C shorter than 8 bytes seems
> unlikely.
>
> My preference would be to replace the definition of binary-value with
> the current definition of large-binary value, replace
> large-binary-value with binary-value (in 10.2 and 10.3) and get rid of
> regular-binary-value and large-binary-value.
That's my prefered choice.
Take care,
Bill
- Follow-Ups:
- Re:
- From: Martins Krikis <mkrikis@yahoo.com>
Home
Last updated: Fri Jul 05 10:19:07 2002
11123 messages in chronological order
|
