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 <jema...@gnu.org>:
>
> 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.
>
>
