[fpc-devel] Bug in Gettext?

[Michael Van Canneyt]

On Fri, 9 Jan 2009, Klaus Reimer wrote:

> Michael Van Canneyt wrote:
> > I meant: but based on what does GNU gettext calculates the hash code ?
> > Is it on:
> > String
> > Context+String
> > Context+#4+String ?
> 
> That's exactly my problem. Lazarus only passes "String" to gettext and
> this fails (And the reason is clear). My plan was to change this so if
> gettext says "I don't have anything for 'String'" then the
> DefaultTranslator asks again but this time also passes the context. But
> Context+String and Context+#4+String also does not work so I have no
> idea how I can modify DefaultTranslator so it gets the correct answer
> from the gettext unit.
> 
> My current theory is that the hash algorithms of Free Pascal and msgfmt
> are nearly the same but not exactly the same so a simple character like
> #4 kills the compatibility.
> 
> The GNU gettext documentation only says this: "The hash table contains
> indices to the sorted array of strings in the MO file. Conflict
> resolution is done by double hashing. The precise hashing algorithm used
> is fairly dependent on GNU gettext code, and is not documented here."
> 
> This sounds like the algorithm isn't "specified" and therefor may change
> in future versions. So maybe it's better if the gettext unit created
> its own hash table when the MO file is parsed?

Currently it reads the hash table from the .mo file.
The reason it is stored there is speed. I think it would be unwise to
recalculate the hash value.

I don't think GNU gettext will change it's hash algorithm: it would mean
that newer programs can no longer read old .MO files (or vice versa) so
I think it is better to find out why the hash values are different.

A simple routine calculating the hash value of all ascii values both in
C and Pascal should do it, no ?

Michael.