Subject: RE: (spell) A couple of clarifications
From: Henrik Berg (henrik@lansen.se)
Date: Sun Feb 13 2000 - 06:33:39 CST
> I am trying to clean up warnings in the debug build
> on Linux/Alpha. I was successful in cleaning up
> some files in abi/src/other/spell/. Can someone
> kindly clear up the following for me, please.
In these files (spell) I wouldn't use so much time to take away warnings. It's C code, it's old and it's (as long as we don't mess to much) comparable to the original ispell code.
This should not stop you from makeing it work in a 64 bit pointer world.
> 1. I notice Rcs_Id is ifndef'ed as a global static
> variable in several files like
> abi/src/other/spell/good.c and
> abi/src/other/spell/lookup.c
> and is not used. Wat is the purpose of this
> variable? What is the define variable lint
> supposed to do?
Who knows, it's inherited code. Since ispell don't have a clear cut library interface, there is much in these files that has nothing to do with our implementation. Don't mess to much, but comment out those variables that are not used.
> 2. The global variable hashstrings is a char *.
> In linit():abi/src/other/spell/lookup.c
> it is accessed as an array using dp->word
> as index (where dp is of type struct dent).
> dp->word is a char * (see struct
> dent in ispell.h) and it is cast as an int.
> Can we clean up this requirement for casting
> a char * to int? This downcast, I believe,
> is particularly going to be harmful on an
> Alpha (64-bit m/c) where sizeof(int) is 4 and
> sizeof(char *) is 8. I did not yet look deep into
> the use/semantics of hashstrings variable but
> my first thought is to make it a char ** and
> make dp->word an unsigned long (size_t probably?).
As I said, it C code, I don't like it, too 32-bit only. My suggestion is that you make it work on your platform, in a way you think will work on 32-bit too. If it doesn't we handle that then.
Have in mind if a variable size is internal or come from the fileformat. If it is 32-bit in the dictionaryfile, it might be good to have it 32-bit internally. And then again maybe not :)
--hb
This archive was generated by hypermail 2b25 : Sun Feb 13 2000 - 07:09:03 CST