[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]