Re: [bug #13028] Problem compiling on Solaris 9.

[Fred Kiefer]

Gregory John Casamento wrote:
> Update of bug #13028 (project gnustep):
>
>                   Status:                    None => Fixed                  
>              Assigned to:                    None => gcasa                  
>
>     _______________________________________________________
>
> Follow-up Comment #1:
>
> I have fixed this so that compilation works properly.
>
> As an additional not on this bug, I would like to find out why, when
> index_size is 4, the table_size is set to 2^32.  If it ever gets to this
> point, it will attempt to allocate 4GB of space.   

Hi Greg,

I will reply to this question on the mailing list only, as it is not 
relevant for the error your fixed (Thank you by the way!).

The table we are talking about is used to store the offset for all the 
objects we write to the data. Objects reference each other in the Apple 
binary property list format via an index into this offset table. The 
clever idea of some developer at Apple was that the offset, as well as 
the index, don't have to be off a fixed size. When there are only a few, 
not to big objects storing both of them in one byte will do. But when 
there are more objects or bigger ones the size of either of these may go 
up. I think 4 bytes is the limit, but in the future even bigger ones may 
be possible. I think the biggest numbers I did see out in the wild where 3.

My code now takes an optimistic approach for the index size and an 
pesimistic for the offset size. I start writing objects with 1 byte 
indexes, for this I need a table able to store up to 256 offsets. As I 
don't know the size of the objects I expect to need 4 bytes for the 
offset, giving a table of size 1024. When the code runs out of indexes 
it starts again, this time with an index size of 2 bytes and so on until 
it reaches the limit of 4 bytes. And yes, in this case the offset table 
will use a significant amount of space, but we already did try with less 
and it did not work.

A different approach could be to run over the objects to store once and 
count (and measure?) them. This would normally take a bit more time than 
my approach, but could save quite some space. Feel free to implement 
this, as soon as you run out of memory with my simple code.

Cheers
Fred