[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nano-devel] ready for testing: nano-1.3.8pre2
From: |
Mike Frysinger |
Subject: |
Re: [Nano-devel] ready for testing: nano-1.3.8pre2 |
Date: |
Tue, 28 Jun 2005 00:28:55 -0400 |
User-agent: |
KMail/1.8.1 |
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
- [Nano-devel] ready for testing: nano-1.3.8pre2, David Lawrence Ramsey, 2005/06/26
- Re: [Nano-devel] ready for testing: nano-1.3.8pre2, Mike Frysinger, 2005/06/27
- Re: [Nano-devel] ready for testing: nano-1.3.8pre2, Mike Frysinger, 2005/06/27
- Re: [Nano-devel] ready for testing: nano-1.3.8pre2, David Lawrence Ramsey, 2005/06/27
- Re: [Nano-devel] ready for testing: nano-1.3.8pre2,
Mike Frysinger <=
- Re: [Nano-devel] ready for testing: nano-1.3.8pre2, David Lawrence Ramsey, 2005/06/28
- Re: [Nano-devel] ready for testing: nano-1.3.8pre2, Mike Frysinger, 2005/06/28
- Re: [Nano-devel] ready for testing: nano-1.3.8pre2, David Lawrence Ramsey, 2005/06/28
- Re: [Nano-devel] ready for testing: nano-1.3.8pre2, Mike Frysinger, 2005/06/28
- Re: [Nano-devel] ready for testing: nano-1.3.8pre2, David Lawrence Ramsey, 2005/06/28
Re: [Nano-devel] ready for testing: nano-1.3.8pre2, Mike Frysinger, 2005/06/28