This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

gdb/testsuite/gdb.code/*.exp


(It's the silly season back home.  Figuring out where my ``home'' is and
why it's called the silly season is left as an exercise to the reader
:-)

I'm looking at something of a comedy of errors related to a change and
then a cleanup.

Briefly, long ago, the function strsave() was added to GDB. It
duplicates a string using a buffer allocated using xmalloc() (xmalloc()
calls error if the malloc() fails).

Since then, newer coders have been using strdup() (which first appeared
in 4.4BSD) and I've just went through and changed that to xstrdup().  It
too ``duplicates a string using a buffer allocated using xmalloc() ...''
:-)

So?

Well apart from cleaning up the code and eliminating either strdup() or
strsave() I'm wondering if there is anything else that can help stop new
(and old :-) coders make this mistake again :-)

It occurs to me that adding a set of tests that check for trivial but
common coding/style mistakes might offer a solution.  Clearly such tests
would have to be very careful (1).  However, I do think it would help,
hopefully it would catch many of those trivial issues before a patch was
even submitted. (Other things to do would be a web page clearly
explaining what is expected from a coder when submitting a patch :-).

	enjoy,
		Andrew

(1) Projects can easily get bogged down with pedantic details such as
internal coding standards.  There, always, needs to be a balance.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]