Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Base64 unsigned/signed char

Reply
Thread Tools

Base64 unsigned/signed char

 
 
Sam
Guest
Posts: n/a
 
      08-02-2007
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?


 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      08-02-2007
"Sam" <(E-Mail Removed)> 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.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
 
 
 
Richard Urich
Guest
Posts: n/a
 
      08-02-2007
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

 
Reply With Quote
 
Karl Malbrain
Guest
Posts: n/a
 
      08-02-2007
"Richard Urich" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> 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

 
Reply With Quote
 
Richard Urich
Guest
Posts: n/a
 
      08-02-2007
On Aug 2, 8:24 pm, "Karl Malbrain" <(E-Mail Removed)> wrote:
> "Richard Urich" <(E-Mail Removed)> 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

 
Reply With Quote
 
David Thompson
Guest
Posts: n/a
 
      08-26-2007
On Thu, 2 Aug 2007 16:01:35 +0530, "Sam" <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(const char *cp) and (char *p) are consistent type, (const char **cpp) and (char **pp) are not consistent lovecreatesbeauty C Programming 1 05-09-2006 08:01 AM
/usr/bin/ld: ../../dist/lib/libjsdombase_s.a(BlockGrouper.o)(.text+0x98): unresolvable relocation against symbol `std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostre silverburgh.meryl@gmail.com C++ 3 03-09-2006 12:14 AM
char *fred; char * fred; char *fred; any difference? Ben Pfaff C Programming 5 01-17-2004 07:37 PM
The difference between char a[6] and char *p=new char[6] ? wwj C Programming 24 11-07-2003 05:27 PM
the difference between char a[6] and char *p=new char[6] . wwj C++ 7 11-05-2003 12:59 AM



Advertisments