Re: [xml] Some things about xmlCharEncodingHandler

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]