Re: [Evolution-hackers] camel-folder-summary.c - 64bit-ness ...

[Jeffrey Stedfast <fejj novell com>]

Michael Meeks wrote:
> Hi guys,
>
> 	I was just trying to reproduce some migration performance tests with my
> mbox and summary data rsync'd from a 32bit machine to a 64bit machine.
>
> 	Surprisingly this appears to crash immediately.

that's not good :(

>  Looking at the
> camel-file-utils.c code I was surprised to see simultaneously an
> apparent concern for network byte ordering:
>
> camel_file_util_encode_fixed_int32 (FILE *out, gint32 value)
> {
> 	guint32 save;
>
> 	save = g_htonl (value);
> 	if (fwrite (&save, sizeof (save), 1, out) != 1)
> 		return -1;
> 	return 0;
> }
>
> 	and also things like:
>
> CFU_ENCODE_T(time_t)
>
> 	that appear to generate data based on the sizeof the platform's time_t
> - on my 64bit machine time_t is 8 bytes, on 32bit it is only 4.
>   

yea, unfortunately the old summary format wasn't designed with 32/64 bit
compat. Now that a lot of people are moving from 32bit to 64bit as they
upgrade to 64bit x86's, it would probably be good to look into.
Although, to be fair, summary files can be re-generated pretty easily.
Unfortunately, for IMAP, while it may be "easy", it's not very fast :(

> 	Presumably this summary code is made obsolete by the new SQLite summary
> code - and modulo some data as to what architecture a file was written
> by it's perhaps less than obvious how to fix this.

nod. the only idea I can come up with is having some logic in the
loading code that tries to figure out why loading failed and to see if
it might have something to do with 32bit vs 64bit int sizes in the
summary file.

Not sure how doable it is.

>  Also - why we're not
> using fgetc_unlocked in these tight loops I don't know.
>   

isn't that a GNUism? To be honest, I didn't even know the function
existed until a year or so ago when I was looking into Mono vs Java I/O
performance based on the Debian Language Shootout tests. I happened to
look at the C implementation and saw fgets_unlocked() and looked into
it. IIRC, replacing it with fgets() didn't make any noticeable
difference in performance. I just figured it was a soptimization ;-)

> 	I guess I need an old evo. version to re-build all my summaries for
> 64bit now; or am I barking up the wrong tree ?
>   

I would imagine so, yea.

Jeff