[libclang] fprintf usage cleanup ?

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 :slight_smile:

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,

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 :slight_smile:

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.

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