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

[Mike Frysinger]

On Monday 27 June 2005 04:28 pm, David Lawrence Ramsey wrote:
> Mike Frysinger wrote:
>
> <snip>
>
>  >is it just me or is the 'goto line #' feature broken ?
>  >
>  >ctrl+w -> ctrl+t -> 54
>  >nano tells me to be reasonable instead of going to line 54 :(
>
> You could try setting a breakpoint on parse_line_column() with gdb, and
> seeing what values are placed into *line and *column.  For your example,
> *line should obviously be 54, and *column should be (placewewant + 1),
> since it's unspecified.  If they don't match, please let me know.

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

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 ... 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 hacked parse_line_column a bit to work around the issue and ctrl+w -> ctrl+t 
started working again ... i dont think this is a proper fix, but it gives you 
an idea of what needs to be done ...
     if (line != NULL) {
+        ssize_t big_line = *line;
         if (comma != NULL) {
             char *str_line = mallocstrncpy(NULL, str, comma - str + 1);
             str_line[comma - str] = '\0';
 
-            if (str_line[0] != '\0' && !parse_num(str_line, line))
+            if (str_line[0] != '\0' && !parse_num(str_line, &big_line))
                 retval = FALSE;
 
             free(str_line);
-        } else if (!parse_num(str, line))
+        } else if (!parse_num(str, &big_line))
             retval = FALSE;
+        *line = big_line;
     }





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 ?
-mike