SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: Section 4.1 clarifications




    I am not sure that a loop is complex code but we could limit ourselves to 128 bit integers to cover at least some addresses.

    Julo


    "Michael Krueger" <michael.krueger@windriver.com>

    04/26/2002 12:41 AM
    Please respond to "Michael Krueger"

           
            To:        "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>, "Julian Satran" <Julian_Satran@il.ibm.com>
            cc:        <ips@ece.cmu.edu>, "iSCSI Team" <iscsiteam@windriver.com>
            Subject:        RE: Section 4.1 clarifications

           


    Pat,

    > I think Michael's point is that the decimal encoding for a 1024
    > byte binary is around 2500 characters (if I've done the math
    > right) while the hexadecimal encoding is 2050 characters and
    > someone anticipating the binary might not have made wherever they
    > store the string before conversion big enough for the extra ~450
    > characters.
    >
    > The extra storage is small compared to the amount of data one may
    > be moving later once the connection is up, but I also don't see
    > the readability argument as applying to these large constants.

    Actually, I'm concerned neither with storage space nor with speed, but
    rather with code complexity.  Unlike hexadecimal and base-64 encoding, there
    is not a simple correspondence between decimal digits in the string
    representation and bit locations in the binary item.  Most implementation of
    decimal-to-binary conversion functions like strtoul() do integer arithmetic
    to obtain the binary representation, but this isn't feasible for binary
    items larger than 4 (or, at an absolute maximum, 8) bytes.  Show me a simple
    algorithm or a widely available library function for converting a
    2,467-digit string to its 1024-byte binary representation, and I'll use it;
    otherwise, support for decimal encoding of large binary items seems like a
    needless complication that pays back very little added value.

    Michael

    --
    Michael J. Krueger              mailto:michael.krueger@windriver.com
    Wind River Networks                         http://www.windriver.com
    500 Wind River Way                               phone: 510-749-2130
    Alameda, CA  94501                                 fax: 510-749-2010





Home

Last updated: Fri Apr 26 13:18:22 2002
9811 messages in chronological order