Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| >>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Ben Cazzolato <[EMAIL PROTECTED]> writes: | JM, | |
| Lars> > Could you do something like | > | > frame 6 | > print
| Lars> *(name.rep) | > | > I'd be interested to see what the string
| Lars> from which the extension | > sought is. I suspect that rfind is
| Lars> to blame, however. | | | (gdb) frame 6 | #6 0x81d3111 in
| Lars> GetExtension (name=@0x84b3d18) at filetools.C:985 | 985 in
| Lars> filetools.C | (gdb) print *(name.rep) | $1 = {sz = 0, ref =
| Lars> 3019, res = 1, s = 0x836e988 ""} | (gdb)
|
| Lars> I give GetExtension the blame...
|
| Lars> | Does this help?
|
| Lars> Yes, it seems that GetExtension cannot handle finding the
| Lars> extension in an empty string.
|
| In fact, it seems that lyxstring::rfind(char, size_type=npos) is to
| blame (as you can see in the trace, it returns large values which are
| not string::npos).
I must admit that I cannot see how rfind fails.
lyxstring::size_type lyxstring::rfind(value_type c, size_type i) const
{
size_type ii = min(rep->sz - 1, i);
for (size_type t = ii; t != 0; --t) {
if (rep->s[t] == c) return t;
}
return npos;
}
Hmm, well actually I see how it can fail... and we are lucky that it
does not crash.
When running rfind on an empty string with i == npos, ii wil be set to
-1. -1 != 0 so the loop runs... and then som unknown negative value is
converted into an unsigned char and we have a large value that looks
almost like npos.
I guess the fix is to have "...; t > 0; ..." in the test.
Do we have the same problem in the other rfind's?
Lgb
