[cairo] return type of cairo_status_to_string ()
Daniel Goldman
dagoldman at yahoo.com
Tue Aug 17 17:37:56 PDT 2010
> On Tue, 17 Aug 2010, Daniel Goldman wrote:
>
> > What bad thing does the const keyword prevent here? If nothing bad
>prevented,
>
> > then I think it should be the simpler, more default "char *".
>
> In C, returning a const char * from a function tells the caller that
> they do not need to call free() on the returned address to reclaim
> storage. When returning a char *, the caller needs to worry about
> ownership of the returned storage and go read docs to find out what
> the policy is.
>
> > I'm not expecting a detailed off-topic discussion about the const keyword. I
>
> > would just like a real-world example showing the purpose for this particular
>
> > function.
>
> Mostly when debugging it's useful to see what the human readable
> status is like this:
>
> /* ... at the end of rendering ... */
> status = cairo_status(cr);
> if (status != CAIRO_STATUS_SUCCESS) {
> fprintf(stderr, "eek! error '%s' while rendering\n",
> cairo_status_to_string(status));
> }
>
> Cheers,
>
> Joonas
>
Thanks for the reply. I wasn't questioning the purpose of cairo_status_to_string
() function. My last sentence was implying "the purpose of *** const return
value *** for this particular function".
Are you saying that scenario A:
const char *error_str;
error_str = cairo_status_to_string (status);
is better than scenario B:
char *error_str;
error_str = cairo_status_to_string (status);
because the contents at the returned address might be overwritten or freed in
scenario B, whereas the contents are guaranteed to not be overwritten or freed
in scenario A? Is that really true? I thought strings were stored in a read-only
data segment. I know that the const keyword will not allow you to assign twice
to error_str. But if that's the only advantage, it seems like no advantage.
I looked at the source, and cairo_status_to_string () just returns a quoted
string. It does not allocate memory. So why would the caller need to call free
() for error_str pointer in either scenario?
The question is what happens to the contents of what error_str points to after
cairo_status_to_string () goes out of scope. The pointer is just a number, so it
does not go out of scope. And isn't the string stored in a read-only data
segment, so is always available at the same address? Correct me if I'm wrong. Do
some compilers not put the string in read-only data segment? But wouldn't this
also cause scenario A to crash?
A simple test program seems to work fine for both scenario A and B. I know this
does not prove that it works under all conditions. What condition would break
scenario B?
#include <stdio.h>
const char *return_constant () { return "constant"; }
char *return_non_constant () { return "non_constant"; }
int main () {
const char *constant_str = return_constant ();
char *non_constant_str = return_non_constant ();
printf ("constant_str = %s\n", constant_str);
printf ("non_constant_str = %s\n", non_constant_str);
return 0;
}
If this is getting too off-topic, just let me know. It does seem to be the
consensus to use "const char *", so maybe I should just shut up. But I like to
really understand things, and would prefer to learn from a simple example or
explanation why "const char *" return type is needed for cairo_status_to_string
().
Daniel
More information about the cairo
mailing list