[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

xwpe



Hi,

i haven't much time last week, so i made only first steps in rewritting.
First, i GNUized entire package, added automake etc. I removed nearly all
conditional compiling code, assuming that only UNIX X11 version will be
functional. This was necesarry because all the code is really messy. Some
defines which i left is a) function specific and they gone to config.h
and b) needs to be changable runtime or in config file. Then i walk through
entire code, to see what structures needs change and improvment, and to
understand how at least the structures works. I made few translations of
variables' names and comments which were in german. 

I merged WeString.c and we_hkft.c into e_string.c and rewrite almost all
functions in it to give them uniform indent, and to make them simply and
undestandable - they are simple and do not rely on any structures, so
they are good example how xwpe code could look :) Oh, and i called this 
project 'pedit' (Programmer's editor) to distinguish it from orginal
not-supported-by-its-author xwpe. I also unified copyright messages in
all source files. 

I put code in CVS in next days (probably at sourceforge.net) to get source
of all this which i done already (at least for myself :) ).

When rewriting that we_hfkt.c i saw incosistence which i believe is a bug:

in function 'e_rstrstr' there is call to regex -

 old = s[end];/* Save char */
 s[end] = '\0';
 res=regexec(regz,&s[start],len,matches,REG_NOTBOL|REG_NOTEOL);
 s[end] = old;/* Restore char */
    
- which passes to it subsection of string 's' (from 'start' to 'end'). So when
match is found, regex returns offset relative to s[start], not the begging
of s, which is probably expected - even if it is not, 

 for (i=0;i<len;i++)
  {
     start = (matches[i].rm_so<start) ? matches[i].rm_so : start;
     end = (matches[i].rm_eo>end) ? matches[i].rm_eo : end;
  }

these comparsions are nonsense, coz they compares tho unrelated numbers. 
And i believe they are not needed anyway.

 return start;
 
This should probably return (matches[i].rm_so + start) - offset in substring
plus offset of substring in main string. And so on for rm_eo and 'end'.

This all is true, of course, if i guessed the purpose and calling of this
function right. (i said, the code is *really* messy :) ). And yes, i HAVE
fun when reading some parts of this code :)

Jan Dvorak <johnydog@go.cz>