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

Matthieu Monrocq matthieu.monrocq at gmail.com
Thu Jul 5 09:39:45 PDT 2012


On Wed, Jul 4, 2012 at 9: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.
>
>
As far as cleanup is concerned, either one of:
- clean it up the next time a function returns
- clean it up right before putting a new message there
- simply use a static buffer of fixed length

Note: the callback idea will also have to deal with 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120705/07bf2d03/attachment.html>


More information about the cfe-dev mailing list