Is the lcl_LocalFunction naming convention useful?

[Lubos Lunak]

On Tuesday 09 of October 2012, Tor Lillqvist wrote:
> Where did this lcl_ convention come from? The lcl_ prefix has no
> meaning to a compiler or linker. If the intent is to make such
> functions file-local, why not use the static keyword, or an anonymous
> namespace instead, so that they actually *are* local also to the
> tool-chain? (You can still keep the lcl_ prefix if you love it.)
...
> (I am complaining because when attempting to link shitloads of LO code
> into one executable / shared library, whicih I am experimenting with
> for Android and which is necessary for iOS, such functions that have
> identical mangled names, from separate modules, *will* clash. Sure,
> it's trivial for me to then change the functions into static, but a
> bit tedious.)

 For the record, I wanted to give you a patch from a compiler plugin adding 
static before every lcl_ where it was missing, but since those 1000+ places 
made the patch quite big, I've pushed it directly after fixing the few cases 
where the lcl_ function actually wasn't local at all ('few' was a silly 
assumption on my part BTW, there were even a number of lcl_ functions that 
actually had extern declarations in headers, so much for there being much 
point in this convention).

-- 
 Lubos Lunak
 l.lunak at suse.cz