Re: iSCSI: RE: iSCSI 4.1 & 4.2

[Luben Tuikov <luben@splentec.com>]

Martins Krikis wrote:
> 
> > How do you unambiguously
> > represent the 8-bit
> > pattern 00000100 in decimal?  4?  04?  004?
> 
> All very good points by the way, let me just add this:
> 
> Can we please prohibit decimal representations
> starting with 0, because an outsider would naturally
> assume that they are octal? Even strtoul (with 0 base)
> would treat them as octal. I know this isn't terribly
> important, but it would just make the specification
> a tiny bit clearer.
> 
> If we can't, I would like to see a big warning that
> numberical values described by 0[0-9]+ are decimal
> and _not_ octal.

Why not just address the core issue:
Why need extra 0 in the string representation
of an integer? (NOT a numerical/binary/what-not ITEM).

Unless to denote that it is an octal integer.

Let's specify that representations of
integers should always be normalized (no extra
0's at the beginning), unless the 0 is part
of the base identifier.

4 is ok, 044 is also ok, since it is octal,
but 09 is unnacceptable, as is 0044.
Similarly for hexadecimal representations
of the integers. I know 0x0f looks pleasing,
but there is no real need for the extra 0.
(i.e. the width is determined by the key name,
NOT by the key value!)

Also let the sign precede the base identifier,
e.g. -0x1F. If a sign is missing `+' is assumed.

Ok, the regular expressions will be a bit more
complicated, but it is worth it for the clarity.

Regarding binary _items_, which are
(0b){1}[01]+, since those are items and not
integers, they are left alone.

-- 
Luben