[cfe-dev] [libclang] fprintf usage cleanup ?

[Sean Silva]

A lot of libraries that I have seen generally deal with this by having
a "handle" object, which serves as a "global" context in which to deal
with these things. You then have two basic functions "has_error" and
"strerror" (or the equivalents), which respectively provide an
indication that an error has occurred and give a descriptive string
about the error. If the strings are non-constant, their lifetime can
be tied to the "handle" object.

In this case, since you don't want to change the API, It would
probably be best to make each "major" object be a "handle", with its
own error state, and introduce new "has_error" and "strerror"
functions.

--Sean Silva

On Wed, Jul 4, 2012 at 12:53 PM, Arnaud de Grandmaison
<arnaud.adegm at gmail.com> wrote:
> One comment from Doug on my patch adding CompilationDatabase to libclang was
> about fprinf which should not be used.
>
> I intend to clean this. I however found out that libclang is using fprintf in
> several places. I am proposing to clean this up as well while I am at it.
>
> I am asking here for advices / thoughts / preferences so that I can propose a
> patch which at least goes in the right direction :)
>
> The requirement : no api change to libclang. Existing code should continue to
> work as is.
>
> What are our available options ?
>
>  #1 just rip it off. Not very friendly, starting with ourselves, as those
> messages help diagnosing the error cause.
>
>  #2 implement something `a la` errno / strerror
>     Questions :
>        - how do we want to handle thread safety ? TLS ?
>        - do we only provide static const strings the user does not need to
> free or dynamically generated messages (the case today), requiring user
> actions to cleanup.
>
>  #3 have the user (optionnaly) register a callback function which is used to
> convey more information than a simple error code. I like this one as the user
> does not pay for what he does not use.
>
>  # other scheme ?
>
> Thoughts ?
>
> Cheers,
> --
> Arnaud de Grandmaison
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev