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

[Albert Meroño Peñuela]

Aleksander pointed a c.1) option: this header

const char * pdf_uuid_string (pdf_uuid_t uuid, char
ascii_rep[PDF_UUID_CHAR_LENGTH]);

is thread-safe and working well. The function returns the same pointer
it gets as input parameter (ascii_rep). The user is still required to
initialize the char array, but the size he or she specifies seems to
have no effect; the following testing code worked fine to me, writing
PDF_UUID_CHAR_LENGTH chars in stdout:

pdf_uuid_t t;
char t_a[1];

pdf_uuid_t t = pdf_uuid_generate (PDF_UUID_TIME);

printf("Generated UUID, time 1: %s\n", pdf_uuid_string (t, t_a));

However, the following crashes (as the t_a string is not being
initialized at all):

pdf_uuid_t t;
char * t_a;

pdf_uuid_t t = pdf_uuid_generate (PDF_UUID_TIME);

printf("Generated UUID, time 1: %s\n", pdf_uuid_string (t, t_a));

So, regarding the first case, is gcc re-allocating the char array when
it reads the function header?

Albert


2011/3/21 Albert Meroño Peñuela <address@hidden>:
> 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.
>>
>>
>