This is the mail archive of the 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]
Other format: [Raw text]

Re: [rfa/cli] s/NO_FUNCTION/NULL/

>> IMHO, someone should test this change with the latest versions of GCC,
>> including their development line: they could have their own ideas when
>> you are allowed to pass NULL, especially with all the warning options
>> we use.

My ISO C is pretty rusty, however my memory is that NULL is very very 
special.  GCC might do be doing some strange things but they won't 
extend to things like:

	cmd->function.cfunc = NULL;
	if (cmd->function.cfunc)
if (cmd->function.cfunc == NULL)

With regard to parameters, GDB is fully parameterized so that isn't a 

GDB built with GCC 3.0.3.  Using current GCC things died mysteriously 
part way through the build.

> Besides, the NO_FUNCTION documents the meaning better than NULL
> (although most people should guess). Maybe you can add a comment 
> somewhere nearby.
> Any chance Eli's concerns become true and we get a warning because
> NULL is not typed properly?  Maybe you would need a cast (in which
> case I would prefer the NO_FUNCTION def.

If we're going to have a cast NULL pointer for cfunc (NO_FUNCTION) then 
we're going to need to do similar for every single function pointer in 
GDB.  I really can't see anyone doing that.

Anyway, per my original e-mail , a quick look through the CLI code 
reveals that even the CLI doesn't follow its own convention.  The CLI uses:

	if (cmd->function.cfunc == NULL)
if (cmd->function.cfunc)

intead of:

	if (cmd->function.cfunc == NO_FUNCTION)

(the latter occures just once).  This leads me to conclude that 
NO_FUNCTION ``was simply a good idea at the time''.  One of those 
conventions that looks good but doesn't actually improve things.


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