[Expat-discuss] XML_LARGE_SIZE binary compatibility problem

Bruno Haible bruno at clisp.org
Fri Apr 7 22:59:43 CEST 2006


Karl Waclawek wrote:
> The standard build is without XML_LARGE_SIZE defined. Therefore your
> program should rely on that ABI. We introduced this compile option only for special
> needs, where one needs to get the line/column number when processing extremely
> large files.

This compile option is so prominently mentioned in the README that it's likely
that some distributor (Linux distributor, mingw, fink, netbsd, freebsd, openbsd,
openpkg, ...) will turn it on. Remember that FreeBSD made 'off_t' a 64-bit type
a few years ago, at a time when this seemed totally unreasonable?

> In this case you would create a custom build of libexpat and you would know
> that you need to define XML_LARGE_SIZE when compiling your application to get
> the correct header files.

The question is: How would an application know this? In the current state,
it cannot know it by looking at expat.h. The only way I can distinguish the
two ABIs - as a human - is to disassemble selected functions of libexpat.so.

> We could add a new return value to XML_GetFeatureList(), so that you can
> dynamically detect if XML_LARGE_SIZE was used. Would that help you?

Thank you, yes, such a function returning, say, a 'const char * const *' pointing
to a NULL-terminated array of feature strings, would fix the second case (loading
via dlopen).

For the first case, #include <expat.h>, I would suggest that in a build with
XML_LARGE_SIZE, the lines

    #ifndef XML_LARGE_SIZE
    # define XML_LARGE_SIZE 1
    #endif

be inserted at or near the beginning of expat_external.h. Then #include <expat.h>
can be used without prior knowledge, and the expat.m4 macro does not need to be
modified.

Bruno



More information about the Expat-discuss mailing list