#225 Function to get XML_Memory_Handling_Suite

Feature Request
closed-fixed
nobody
None
5
2003-01-21
2002-12-11
Artyom Bolgar
No

It is not a bug report, it is a feature request. What do
you think of adding the function, that returns the pointer
to XML_Memory_Handling_Suite for passed
XML_Parser? It is necessary for me, I am developing an
extension for Expat and I would like to use the same
allocation/reallocation/free function as the current
XML_Parser uses. Since XML_Parser struct defined
inside .C-file, I can't get an access to
XML_Memory_Handling_Suite struct for the parser.
Please add this function, since it will be very simple.

Sincerely,
Artyom Bolgar.

Discussion

  • Karl Waclawek
    Karl Waclawek
    2002-12-11

    Logged In: YES
    user_id=290026

    Are you creating the parser using XML_ParserCreate?
    In that case - without supplying an external memory handler,
    Expat just uses the standard C runtime functions
    malloc, realloc and free.

    If you use XML_ParserCreate_MM however, then *you*
    are supplying the memory handler yourself.

    In both cases you don't need the requested function.

    Is your situation different from what I described?

     
    • milestone: --> Feature Request
    • summary: Feat req: get XML_Memory_Handling_Suite --> Function to get XML_Memory_Handling_Suite
     
  • Artyom Bolgar
    Artyom Bolgar
    2002-12-11

    Logged In: YES
    user_id=657326

    Of course, I know about this. But in my case, I use
    XML_Parser passed by user (and it is created by him), and I
    don't know how it was created, either by
    XML_ParserCreate_MM or not. That is why I requested this
    function.

     
  • Logged In: YES
    user_id=3066

    Can you explain why you need the memory handler they've
    asked Expat to use? The requirements aren't clear, so more
    explanation of the use case should help.

    Thanks.

     
  • Karl Waclawek
    Karl Waclawek
    2002-12-11

    Logged In: YES
    user_id=290026

    Once you set an element declaration handler you need
    to free the content model passed to the handler, so
    you will need to know the memory handler in use.

    It is just a rare case that the code that sets the handlers
    has no control over the code that creates the parser.
    But it is not too far fetched, so IMO that feature
    request makes some sense, unless I am overlooking
    the obvious.

     
  • Logged In: YES
    user_id=3066

    Karl: Artyom didn't say he was setting a handler on an
    XML_Parser object someone else passed him, nor did he say he
    wasn't. The only specific I see here is that he wants to
    use the same resource handlers as the parser; it's not clear
    that this is a real requirement. I'll follow up with a
    discussion on expat-discuss.

     
  • Karl Waclawek
    Karl Waclawek
    2002-12-11

    Logged In: YES
    user_id=290026

    Fred:
    I know that, but I just pointed out an example
    where it would make sense.

    I have another reason too that has to do with
    writing wrappers/bindings for Expat, but I will
    mention it in a reply to your upcoming message
    on expat-discuss.

     
  • Karl Waclawek
    Karl Waclawek
    2002-12-11

    Suggested patch

     
    Attachments
  • Karl Waclawek
    Karl Waclawek
    2002-12-11

    Logged In: YES
    user_id=290026

    Attached is a potential patch MemSuite.diff.
    Includes changes to expat.h, xmlparse.c
    and the DEF files for Windows builds.

    This is just a suggestion.
    For the content model example all one would need,
    however, is a FreeContentModel API.

     
  • Artyom Bolgar
    Artyom Bolgar
    2002-12-11

    Logged In: YES
    user_id=657326

    I am developing an extension to Expat API that provides
    ability of parsing from any source, from file, network, etc. Of
    course, I have to make some memory allocations. For
    example, the function name EXML_CreateFileInputSource
    (XML_Parser, const char* filename). I don't know how
    XML_Parser was created, with mem suite or without. But I
    need to use the same memory functions as parser uses,
    because user might overload them.

     
  • Karl Waclawek
    Karl Waclawek
    2002-12-11

    Logged In: YES
    user_id=290026

    Artyom:
    I am still not clear what you mean with overloading.
    I don't think you need the same memory handler
    functions as Expat as long as you don't have to free
    memory that Expat allocates.

     
  • Artyom Bolgar
    Artyom Bolgar
    2002-12-11

    Logged In: YES
    user_id=657326

    Karl,
    Why user overloads memory allocation functions? Because
    he don't want to use malloc/realloc/free for some reasons, for
    example performance or compatibility (some embedded
    platforms do not support malloc/realloc/free functions). As far
    as I develops the extension of Expat and it will be linked
    together with Expat library I want to use the same memory
    functions as are used by parser.

     
  • Karl Waclawek
    Karl Waclawek
    2002-12-11

    Logged In: YES
    user_id=290026

    Artyom,

    I think I understand now.
    From a proper design perspective your use case should
    not involve Expat. This is a matter between your code
    and the user's application. It should provide you with
    the necessary information to use it properly.

    However, I still think that there is a reason
    for having an API like the one you suggested:

    There is one use case where the application has to
    free memory allocated by the parser (in the element
    declaration handler). If Expat is not accessed from
    C/C++, then there may not be a way to do so
    from languages that can access Dlls, but have different
    memory allocation implementations.

    In my case, I am lucky that Delphi's memory manager
    is basically identical to C/C++, so I can create the
    parser with the Delphi memory management functions.

    However, I would have preferred if there was an API like
    you suggested, or at least a function to free the content
    model passed to the element declaration handler.

     
  • Karl Waclawek
    Karl Waclawek
    2003-01-16

    Logged In: YES
    user_id=290026

    Applied a patch with two solutions:

    1) Added XML_FreeContentModel API
    2) Exposed all three memory handling functions as
    XML_MemMalloc, XML_MemRealloc, XML_MemFree

    Check out xmlparse.c rev. 1.102 and expat.h rev. 1.50

     
  • Karl Waclawek
    Karl Waclawek
    2003-01-16

    • status: open --> open-fixed
     
  • Logged In: YES
    user_id=3066

    Since a sufficient API enhancement has been committed and
    documented, this issue is closed.

     
    • status: open-fixed --> closed-fixed