Re: MC_ARG_ENABLE_DEVELOPER_MODE

[Pavel Roskin <proski gnu org>]

Hello, Roland!

On Thu, 2005-05-19 at 00:37 +0200, Roland Illig wrote:
> Pavel Roskin wrote:
> > I'm removing MC_ARG_ENABLE_DEVELOPER_MODE now because in my opinion, it
> > doesn't provide any useful value at all.  If you want that code
> > restored, please provide arguments and _tested_ code.  I'm also removing
> > m4/ri-gcc-warnings.m4, which is now unused.
> 
> That reminds me that I could also remove all code from you that is faulty.

OK.  Unfortunately, there isn't too much code written by me, faulty or
otherwise :-(

> I think it is more polite to ask the developer who introduced things to 
> remove them, except in urgent or very obvious ones.

It was fairly urgent.  I created the usual snapshot and the binary RPM
earlier that day, and I realized that the RPM was compiled without
optimization.  I wanted to replace it with an optimized version as soon
as possible.  I didn't want to make a snapshot from modified sources.

Besides, maint/mctest wasn't working properly.  The -Wall option doesn't
enable some warnings without optimization.  There are still warnings
with gcc 4.0 waiting to be fixed.

Please keep in ming that CVS keeps all the revisions, so the code can be
restored if necessary.  Removing incorrect code shouldn't be considered
as a rebuke.  On the other hand, if incorrect code is commented out, it
tend to stay in the sources forever, cluttering them.

As for m4/ri-gcc-warnings.m4, the idea is not to keep unused files in
the CVS (in the current branch of course, not in history).  It's very
helpful to have only used files in CVS, so one can easier locate where
particular pieces of data (compiler flags in this case) originate.

> I already admitted I 
> had introduced some bugs, but they weren't intentional. Without these 
> bugs I find the developer mode quite useful. Just look at my proposed 
> patch for the viewer, which uses that mode extensively. Perhaps you then 
> see what my intention was.
> 
> I also planned to #define NDEBUG depending on MC_ENABLE_DEBUGGING_CODE, 
> but this issue seems to have gone. :(

I don't like inverse logic, like NDEBUG, or HAVE_NO_SLANG or whatever.
It's much easier to use "positive" values consistently, even if not
having something is more remarkable than having it.

Also, NDEBUG is documented in glibc.info - it disables assert().  I
don't think it's a good idea.  Failed assertions should terminate the
program.  In my opinion, the only exception is when they are placed by
somebody with the purpose of understanding how the program works.  Then
other users wouldn't need those particular asserts to terminate the
program.

-- 
Regards,
Pavel Roskin