[Mono-dev] Big Arrays, Many Changes --- Request for Advice

Luis F. Ortiz LuisOrtiz at Verizon.Net
Thu Sep 6 07:36:42 EDT 2007

On Sep 5, 2007, at 5:37 AM, Robert Jordan wrote:
> Luis F. Ortiz wrote:
>> But at least now there is only one method to change, though I  
>> suspect it
>> will take
>> more than a few minutes for me to get the SVN version to compile from
>> scratch.
> The big array support leads to an API breakage on 64 systems:
> Unlike other API structs, MonoArray's internals are publicly exposed
> by macros. Since its "max_length" member has to be extended to 64 bit,
> the ABI will change and all applications using libmono have to be
> recompiled.
> IMO, this cannot be done before Mono 2.0, especially when the benefits
> are so tiny, but feel free to provide patches.

You are quire correct, API breakage is to be avoided, thanks for  
pointing out this issue. I'm not sure what release/branching  
structure is used by the mono project, but I suspect it is a live  
trunk with branches used to record releases.  Thus these changes  
could be set up to work off off a ./configure option (say --with- 
large-objects) which could result something like MONO_LARGE_OBJECTS  
being defined and conditional compiles used while the 1.2.X series is  
being worked on.  That way, the API breakage will be restricted to  
those who want to experiment.  Then, when 2.0.0 is in active  
development, the default condition for the configure switch can be  
flipped to ON and then later, once everyone is comfy with the  
changes, the conditional code can be ripped out.


More information about the Mono-devel-list mailing list