Base64 unsigned/signed char

Discussion in 'C Programming' started by Sam, Aug 2, 2007.

  1. Sam

    Sam Guest

    Hi,
    I am using some functions return a base64 encoded string.
    The functions write it into an unsigned char buffer. I am a little
    confused as to why a base64 encoded string would be using
    an unsigned char buffer instead of a signed char buffer?

    Also if I want to write this to file. Casting the buffer to
    "char *" & then using fprintf seems to work, but this doesn't
    seem right to me.

    What is the right way of doing this?
     
    Sam, Aug 2, 2007
    #1
    1. Advertising

  2. "Sam" <> writes:
    > I am using some functions return a base64 encoded string.
    > The functions write it into an unsigned char buffer. I am a little
    > confused as to why a base64 encoded string would be using
    > an unsigned char buffer instead of a signed char buffer?


    Well, using signed char wouldn't make any sense at all, but using
    plain char (which may be either signed or unsigned) would probably be
    better.

    I don't know why the function uses an unsigned char buffer. Perhaps
    you can ask the author.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Aug 2, 2007
    #2
    1. Advertising

  3. Sam wrote:
    > Hi,
    > I am using some functions return a base64 encoded string.
    > The functions write it into an unsigned char buffer. I am a little
    > confused as to why a base64 encoded string would be using
    > an unsigned char buffer instead of a signed char buffer?


    The C standard forces unsigned char to support a full 2^8 values (0 to
    255), while signed may only support 2^8 - 1 values (-127 to +127 is a
    valid implementation). If the base64 string is not wasting 2 bits (for
    an 8 bit char) of each element, then signed is potentially lossy.

    > Also if I want to write this to file. Casting the buffer to
    > "char *" & then using fprintf seems to work, but this doesn't
    > seem right to me.
    >
    > What is the right way of doing this?


    If a single base64 number is encoded in a single unsigned char
    element, it should be fine to cast (I'm guessing the base64 number
    doesn't even use 0 to +127).

    If 8 base64 numbers only consume 6 char elements (I assume this is the
    case), I would use fwrite() or something else.


    Richard
     
    Richard Urich, Aug 2, 2007
    #3
  4. "Richard Urich" <> wrote in message
    news:...
    > Sam wrote:
    >> Hi,
    >> I am using some functions return a base64 encoded string.
    >> The functions write it into an unsigned char buffer. I am a little
    >> confused as to why a base64 encoded string would be using
    >> an unsigned char buffer instead of a signed char buffer?

    >
    > The C standard forces unsigned char to support a full 2^8 values (0 to
    > 255), while signed may only support 2^8 - 1 values (-127 to +127 is a
    > valid implementation). If the base64 string is not wasting 2 bits (for
    > an 8 bit char) of each element, then signed is potentially lossy.


    Base 64 = 2^6 -- that's 2 bits less then 256 valued 2^8. No loss.

    karl m
     
    Karl Malbrain, Aug 2, 2007
    #4
  5. On Aug 2, 8:24 pm, "Karl Malbrain" <> wrote:
    > "Richard Urich" <> wrote in message
    > > valid implementation). If the base64 string is not wasting 2 bits (for
    > > an 8 bit char) of each element, then signed is potentially lossy.

    >
    > Base 64 = 2^6 -- that's 2 bits less then 256 valued 2^8. No loss.


    This is why I stated "If the base64 string is not wasting 2 bits (for
    an 8 bit char) of each element...". Perhaps you will find the
    following less confusing: If the base64 string is a buffer of 6-bit
    values concatenated with no "empty" or "wasted" bits in between each 6-
    bit value...

    Perhaps you may also think of this as a "bit-packed" buffer or
    something.

    I read the OP to mean a buffer of 6-bit values, and attempted to
    outline my assumption that it was a buffer of 6-bit values rather than
    a buffer of 6-bit values stored in 8-bit elements, even later stating
    I assumed 8 numbers were being stored in only 6 elements.

    My experience with base64 encoding involves such buffers, generally
    because a very bandwidth-limited I/O device is being sent the buffer.
    I also explained there is no risk in casting if the only valid values
    for each "unsigned char" he was receiving was within 0 to +127.

    I (perhaps incorrectly) felt all of this extra explanation and
    background was completely off-topic and useless to post.


    Richard
     
    Richard Urich, Aug 2, 2007
    #5
  6. On Thu, 2 Aug 2007 16:01:35 +0530, "Sam" <> wrote:

    > Hi,
    > I am using some functions return a base64 encoded string.
    > The functions write it into an unsigned char buffer. I am a little
    > confused as to why a base64 encoded string would be using
    > an unsigned char buffer instead of a signed char buffer?
    >

    The characters used by base64 are within the standard-defined basic
    execution character set, and thus must have positive values in plain
    char or in unsigned char. On systems using ASCII or (more likely) a
    derivative thereof, they must be positive in signed char. Thus as a
    technical matter, it doesn't matter; any of the three will work.

    But, since you normally want to treat base64 encodings as text -- that
    is after all their purpose for existing -- I agree with my "brother"
    <G> not really </> Keith that plain char makes most sense.

    > Also if I want to write this to file. Casting the buffer to
    > "char *" & then using fprintf seems to work, but this doesn't
    > seem right to me.
    >
    > What is the right way of doing this?
    >

    Given that you have array of unsigned char, yes that's a right way to
    pass it to *printf, or *puts. Casting to const char * is arguably
    better since it documents that the routine won't change it. If you
    want to write only this data, without adding other things like headers
    _in the same call_, another option is fwrite(), which similarly takes
    a preferably-const plain-char * .

    Note that these I/O routines, like many other standard-library
    routines, take a plain-char pointer for hysterical raisins but
    internally access the addressed memory as (as-if) unsigned-chars. So
    for your code to declare or manipulate it as such isn't really wrong,
    although because of the interfaces it is less convenient.

    - formerly david.thompson1 || achar(64) || worldnet.att.net
     
    David Thompson, Aug 26, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    9
    Views:
    1,818
    Peter Nilsson
    Jul 26, 2004
  2. Steffen Fiksdal

    void*, char*, unsigned char*, signed char*

    Steffen Fiksdal, May 8, 2005, in forum: C Programming
    Replies:
    1
    Views:
    607
    Jack Klein
    May 9, 2005
  3. At_sea_with_C

    char vs. signed or unsigned char

    At_sea_with_C, Mar 14, 2007, in forum: C Programming
    Replies:
    4
    Views:
    762
    Malcolm McLean
    Mar 14, 2007
  4. Ioannis Vranos
    Replies:
    11
    Views:
    776
    Ioannis Vranos
    Mar 28, 2008
  5. Ioannis Vranos

    Padding bits and char, unsigned char, signed char

    Ioannis Vranos, Mar 28, 2008, in forum: C Programming
    Replies:
    6
    Views:
    626
    Ben Bacarisse
    Mar 29, 2008
Loading...

Share This Page