Re: [pdf-devel] New developer and UUID module request

[Albert Meroño Peñuela]

Hi again,

The static is there because I was loosing the ascii_rep array contents
outside the function's scope. As the returned value is a const char *,
the returned value should not be a pointer to a local char array (as
its contents may vary later, once function is popped from the stack).
AFAIK, there are only 3 possible solutions to this problem:

a) Allocate dynamic memory for the string (which I discarded to avoid
heap usage)
b) Make the string static (which was my choice)
c) Let the user allocate an array big enough and call pdf_uuid_string
with it as a parameter, with something like

pdf_uuid_t my_uuid; // suppose initialized
char * my_ascii_uuid[PDF_UUID_CHAR_LENGTH];

pdf_uuid_string (uuid, my_ascii_uuid);

But this would change the original header from

const char * pdf_uuid_string (pdf_uuid_t);

to something like

void pdf_uuid_string (pdf_uuid_t, char * ascii_rep);

I discarded this last option because it requires the user to know the
char array size to allocate, which I found uncomfortable.

I think options a) and c) make pdf_uuid_string reentrant, so if this
is a must I can change the implementation conveniently (and modify the
changelog, authors and manifest, i forgot that in this patch so my
apologies!) :-)

Albert

2011/3/16 Jose E. Marchesi <address@hidden>:
>
> Hi Albert.
>
>    Please find attached another patch with your suggested modifications
>    (pdf_uuid_t is no longer allocated in the heap).
>
> Looks good.
>
> Just one question.  In the function pdf_uuid_string:
>
>   +const char *
>   +pdf_uuid_string (pdf_uuid_t uuid)
>   +{
>   +  static char ascii_rep[PDF_UUID_CHAR_LENGTH];
>   +
>   +  uuid_unparse (uuid.uuid, ascii_rep);
>   +
>   +  return ascii_rep;
>   +}
>
> Is there a specific reason to use the static buffer 'ascii_rep' instead
> of allocating a new string?  That makes pdf_uuid_string non-reentrant.
>
>