Re: [Nano-devel] ready for testing: nano-1.3.8pre2

[David Lawrence Ramsey]

Mike Frysinger wrote:

<snip>

>they didnt match ... but i started poking through the src and i may
>have found what's going wrong ...

Thank you.

>parse_line_column takes a pointer to an integer and then passes that
>pointer to parse_num ... parse_num takes a pointer to a ssize_t and
>then assigns to the memory pointed to by it ...
>
>i'm on amd64 and sizeof(int) = 4 while sizeof(ssize_t) = 8 ...

Ah.  I should've guessed.

>so as HTB correctly points out, if i give *int to parse_num who
>dereferences it as a *ssize_t, it will clobber 4 bytes of memory :/

I was eventually meaning to convert filestruct line numbers to ssize_t's
anyway, so I just moved that and related type changes up the timetable a
bit.  Does current CVS work for you?

<snip>

>also, while we're on the subject of weird things, this bit of code
>looks wrong to me:
>void update_history(filestruct **h, const char *s) {
>...
>    /* If this string is already in the history, delete it. */
>    p = find_history(*hage, *hbot, s, (size_t)-1);
>...
>}
>...
>filestruct *find_history(filestruct *h_start, filestruct *h_end, const 
char
>*s, size_t len) {
>    filestruct *p;
>   for (p = h_start; p != h_end->next && p != NULL; p = p->next) {
>        if (strncmp(s, p->data, len) == 0)
>...
>}
>
>if you typecast -1 as size_t (a signed value to unsigned), you get a
>really huge number ... then that number (len in find_history) is given
>to strncmp() ... it seems to me that having strncmp() run over like
>billions and billions of bytes is a bad idea ?

I do that because strncmp(s1, s2, (size_t)-1) should be equivalent to
strcmp(s1, s2).  Both of them stop running once they encounter a
differing character and/or a null terminator in either the first or both
strings (cf. glibc CVS, uClibc CVS, nstrcasecmp() and nstrncasecmp() in
chars.c), so there shouldn't be any problem, since both strings are
properly null-terminated.