[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-bugs
Subject:    [Bug 131273] New: Kdevelop shouldn't try to dereference entire char[]
From:       Joseph Garvin <k04jg02 () kzoo ! edu>
Date:       2006-07-24 1:20:30
Message-ID: 20060724032028.131273.k04jg02 () kzoo ! edu
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=131273         
           Summary: Kdevelop shouldn't try to dereference entire char[]
                    arrays when debugging
           Product: kdevelop
           Version: unspecified
          Platform: Ubuntu Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: kdevelop-bugs kdevelop org
        ReportedBy: k04jg02 kzoo edu


Version:           3.4 beta 1 (using KDE KDE 3.5.3)
Installed from:    Ubuntu Packages
Compiler:          gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) 
OS:                Linux

There's a ton of old C style code out there that creates really big char arrays to \
hold strings when the programmer just wanted enough room to type whatever the user \
might type in. Yes, I know, this is not a secure practice, it's bad code, but \
nonetheless there's a lot of code out there that does this, and I have to hack on it.

Anyway, when you're debugging, if you have kdevelop show the value of the array (you \
click the + next to its name in the variable view) kdevelop will freeze for a long \
period because it's looking up every single element of the array. It would be a MUCH \
more convenient behavior in most cases if it did what C does, and stopped at the \
first \0 null byte it encountered. After that null byte is encountered, another + \
could appear to have kdevelop show the rest of the elements, if that's what the \
programmer desires.

Or you could look into massively speeding up reading the elements in gdb... but the \
above alternative seems like a lot less work ;)


[prev in list] [next in list] [prev in thread] [next in thread]