Re: XML_LARGE_SIZE binary compatibility problem

Bruno Haible wrote:
> 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?
>   
I would think that such seasoned programmers would realize that this is 
a breaking change.
Anyway, I have also added a short paragraph in the README pointing this out.
>   
>> 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).
>   
OK, just added to CVS. New enum value XML_FEATURE_LARGE_SIZE, new return 
value for
XML_GetFeatureList(). Not sure however, if anonymous CVS is currently in 
sync with developer CVS
on SourceForge.
> 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.
>
>   
Isn't that something you would have to ask the"builder"?

Karl