cURL / Mailing Lists / curl-library / Single Mail

curl-library

RE: external access to the curl base64 functions

From: Walter J. Mack <wmack_at_componentsw.com>
Date: Mon, 7 Oct 2002 19:24:35 -0700

My two cents..

Maybe the return for the two functions could be size_t.
If dest is NULL, the functions return the required size for the buffer (for
encode enough to include a null terminator). To make implementation easier,
the functions would be allowed to return a value that is larger than the
number of bytes actually needed.

If dest is not NULL, the return is the number of bytes actually written to
dest.
With an implementation like that the caller would always be in charge of
memory management.

With an implementation described below, the man page should advise to use
curl_free () to release the memory if it has been allocated by curl.

Walter Mack

-----Original Message-----
From: curl-library-admin_at_lists.sourceforge.net
[mailto:curl-library-admin_at_lists.sourceforge.net]On Behalf Of Andrew
Francis
Sent: Monday, October 07, 2002 7:05 PM
To: curl-library_at_lists.sourceforge.net
Subject: Re: external access to the curl base64 functions

"Daniel Stenberg" <daniel_at_haxx.se> wrote:
> > I think it would be a good idea to make them available to the
application
> > using libcurl.
>
> But... exporting them to others will require a sensible API that people
like
> and understands. The current one really has more or less ended up as it is
by
> accident, as can be seen by how they work right now:

I don't actually think they're too bad :P But if the interface were to be
done from scratch, I would favor something like the below.
s/malloc/curl_malloc/, if curl_malloc is still on the table.

The major difference between the current interface and the below is:

- user chooses whether to allocate memory themselves, or let curl_base64_*
do it for them

- the functions are expected to do error checking (make sure there's enough
space to store the output, ensure that input to base64_decode is valid
base64, etc).

I'll go ahead and implement these sometime this week if you like the idea.

======
char *curl_base64_encode(unsigned char *orig, int origlen, char *dest, int
*destlen)

Takes origlen bytes from orig and produces the base64 encoded string, null
terminated, at dest.

dest may be NULL, in which case memory will be obtained from malloc().

If destlen is not NULL, then then the length of the base64 string (not
including null terminator) will be written to *destlen before the function
returns.

If dest and destlen are both non-NULL, then *destlen going in will be the
size of the buffer, and the function will not write more than that number of
bytes to *dest.

The function returns a pointer to the base64 string (either equal to dest,
or if dest is NULL, then malloc()ed memory). Returning NULL indicates
failure.

======
unsigned char *curl_base64_decode(char *encoded, int encodedlen, unsigned
char *dest, int *destlen)

This behaves identically, except it takes base64 as input and produces raw
data. It will fail on input that is not valid base64. If encodedlen is not a
positive number, then the function will attempt to detect the end of the
input itself (equals and \0).

Examples of usage:
  /* we have input, of length inputlen, and want to get the raw data */
  #define BUF_SIZE 4000
  unsigned char *rawdata = malloc(BUF_SIZE);
  int rawsize = BUF_SIZE;
  if(!curl_base64_decode(input, inputlen, rawdata, &rawsize)) {
    fprintf(stderr, "there was an error decoding. (probably input too large,
or not valid base64)\n");
  } else {
    /* push the raw data out to stdout */
    fwrite(rawdata, 1, rawsize, stdout);
  }
  free(rawdata);

  /* this time, we don't malloc ourselves */
  int rawsize;
  char *rawdata;
  rawdata = curl_base64_decode(input, inputlen, NULL, &rawsize);
  if(rawdata) {
    printf("raw data is %d bytes\n", rawsize);
    free(rawdata);
  } else {
    printf("there was an error, probably out-of-memory, or invalid
input\n");
  }

Cheers

--
Andrew Francis
Software Developer
Family Health Network
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2002-10-08