Re: [xml] Some things about xmlCharEncodingHandler

["Oliver Stöneberg" <oliverst online de>]

> > I recognised several things about xmlCharEncodingHandlers.
> >
> > First, you only register a handler, you can't unregister it. It makes
> > sense, because as I see from the source there is no
> > syncronisation/protection of the handlers, so you can't assure, that
> > it's not in use at the moment you would try to free it.
>
> You can call xmlCleanupParser, that will remove the registered handlers :-)
Yes, all the registered parsers. Will this have impact in a multi-
threaded enviroment where other function might use the other 
handlers? I haven't tested it, but I am quite sure it might have...
 
> > Another thing is, that you can register several handlers with the same
> > name. And when you try to find a specific handler you only get the first
> > registered one with the name. Maybe there should be a check to prevent
> > more than one handler with the same name.
>
> You have a patch handy?

No, I didn't do any changes to the code yet, because I thought it 
might be done on purpose and wanted to ask first.
I will do a patch tomorrow ( I could do it right know, but no program 
to check it with). It should be like 
- checking if a handler with the alias exists
- if not create a new handle and register it
- if it does exist return the existing handler
 
Just wait a few hours :)

> > I also recognised, that in the function xmlFindCharEncodingHandler() in
> > encoding.c the parameter "const char *name" is changed in the function.
> > The pointer will be set to the returning pointer of
> > xmlGetEncodingAlias(). IMO it should not be altered, because you might
> > want to use that var in the calling function with the (maybe wrong)
> > name. And I guess it causes a little memory leak. After the
> > xmlGetEncodingAlias call the var "nalias" should be used and "nalias"
> > set to name if the result was NULL.
>
> The calling function will never see that change to name. Note that the 
> pointer declared as 'const char* name' is local for the function, 
> regardless wether it is declared in the parameter list or in the 
> function body. The memory pointed to by this pointer wasn't modified.

"const" D'OH! I tend to overlook these a lot in the last time.
 
> As for the leak, where is it? I am failing to see it.

There is none. I thought of a leak if you can change the poiner and 
the old content stays in memory, unfree'd, if alloc'd. But because 
it's a const pointer. Nevermind.

So long
Oliver