[tlbuild] lcdf-typetools-2.78 -- is hashcode() unsigned, uint32_t, or size_t

[Ken Brown]

On 4/30/2009 9:27 AM, Peter Breitenlohner wrote:
> On Thu, 30 Apr 2009, Angelo Graziosi wrote:
> 
> Hi Eddie,
> 
> here a report from an attempt to build lcdf-typetools for TeX Live.
> 
>>> On current Cygwin (1.5.25-15) it fails, without applying any 
>>> *patches*, as follow:
>>> CC='gcc-4' CXX='g++-4' CPP='cpp-4' CFLAGS='-Wno-write-strings
>>> -Wno-attributes' CXXFLAGS='-Wno-write-strings -Wno-attributes'
>>> LDFLAGS='-Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc'
>>> TL_CONFIGURE_ARGS='--disable-xetex --without-graphite' ./Build
>>> [...]
>>> g++-4 -W -Wall -DHAVE_CONFIG_H -I. 
>>> -I../../../../texk/lcdf-typetools/liblcdf -I.. 
>>> -I../../../../texk/lcdf-typetools/include    -Wno-write-strings 
>>> -Wno-attributes -MT string.o -MD -MP -MF .deps/string.Tpo -c -o 
>>> string.o ../../../../texk/lcdf-typetools/liblcdf/string.cc
>>> ../../../../texk/lcdf-typetools/liblcdf/string.cc:535: error: 
>>> prototype for 'uint32_t String::hashcode(const char*, const char*)' 
>>> does not match any in class 'String'
>>> ../../../../texk/lcdf-typetools/include/lcdf/string.hh:261: error: 
>>> candidates are: unsigned int String::hashcode() const
>>> ../../../../texk/lcdf-typetools/include/lcdf/string.hh:250: error: 
>>> static unsigned int String::hashcode(const unsigned char*, const 
>>> unsigned char*)
>>> ../../../../texk/lcdf-typetools/include/lcdf/string.hh:246: error: 
>>> static unsigned int String::hashcode(const char*, const char*)
>>> make[6]: *** [string.o] Error 1
>> [...]
>>
>> Applying only this patch, seems to solve many problems...
>> =======================================
>> diff -Naur 
>> texlive-source.orig/texk/lcdf-typetools/include/lcdf/string.hh 
>> texlive-source/texk/lcdf-typetools/include/lcdf/string.hh
>> --- texlive-source.orig/texk/lcdf-typetools/include/lcdf/string.hh 
>> 2009-03-20 10:50:07.000000000 +0100
>> +++ texlive-source/texk/lcdf-typetools/include/lcdf/string.hh 
>> 2009-04-30 10:16:19.328125000 +0200
>> @@ -243,10 +243,10 @@
>>      * @invariant If end1 - begin1 == end2 - begin2 and memcmp(begin1, 
>> begin2,
>>      * end1 - begin1) == 0, then hashcode(begin1, end1) == 
>> hashcode(begin2,
>>      * end2). */
>> -    static unsigned hashcode(const char *begin, const char *end);
>> +    static uint32_t hashcode(const char *begin, const char *end);
>>
>>     /** @overload */
>> -    static inline unsigned hashcode(const unsigned char *begin,
>> +    static inline uint32_t hashcode(const unsigned char *begin,
>>                                    const unsigned char *end) {
>>        return hashcode(reinterpret_cast<const char *>(begin),
>>                        reinterpret_cast<const char *>(end));
>> @@ -258,7 +258,7 @@
>>      * "SuperFastHash."
>>      *
>>      * @invariant  If s1 == s2, then s1.hashcode() == s2.hashcode(). */
>> -    inline unsigned hashcode() const {
>> +    inline uint32_t hashcode() const {
>>        return length() ? hashcode(begin(), end()) : 0;
>>     }
>> =======================================
> 
> Interestingly this problem show up for neither Cygwin 1.7, Linux, Solaris,
> nor Mac OS X.  The declaration, implementation, and use of hashcode() are,
> however, inconsistent but I somewhat hesitate to apply to patch above
> because the file include/lcdf/string.hh does not include any header that
> might be required to declare uint32_t.
> 
> Can you please clarify this.
> 
> Regards
> Peter

Hi Peter,

Did you ever get a response from Eddie?  I'm asking because Karl has 
asked Angelo and me to get all of our proposed patches together and send 
them to the appropriate upstream people.  But I don't know if we should 
contact Eddie about this or if it's better for you to try again.

Regards,

Ken