[m-dev.] for review: new debugger command set, part 2

[Fergus Henderson]

On 13-Jul-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> > In that case, it should have been
> > 
> > 	#include "mercury_getopt.h"
> 
> But the file you checked in is just getopt.h, not mercury_getopt.h.

Yes, I was talking about the existing file mercury_getopt.h.

As previously noted, use of the header file "getopt.h" is not portable.
So for Mercury, we declare the relevant stuff ourselves
in the file mercury_getopt.h, and include that instead.

> BTW, getopt.h is causing lots of warnings from the C compiler about
> missing prototypes, presumably because we don't pass the right set of
> #defines.

The problem is not really due to us not passing the right set of #defines.
The problem is a somewhat complicated interaction.

When I added getopt.h to our repository, I did not intend for it
to be actually used yet.  I was just adding it so that you could
make use of it later, for your changes to the debugger.
Unfortunately, even though *our* code does not contain any
occurrences of `#include "getopt.h"' -- our code always
uses `#include "mercury_getopt.h"' instead -- some of the
*system* header files contain `#include <getopt.h>', and
this ends up picking up the GNU getopt.h in the Mercury runtime
directory rather than the system getopt.h.

The reason that this results in a warning is that the GNU getopt.h
deliberately does not give a prototype, unless you are using the
GNU C library.  The comment says that this is because some systems
prototype it differently in <stdlib.h>, and so any prototype
in getopt.h might conflict with that.  (Actually if this comment
is true, then we might potentially run into some difficulties when
porting mercury_getopt.h, but so far we haven't.)
Our coding standard, enforced by -Wmissing-prototypes, is that all
functions should have a prototype, and the GNU getopt.h conflicts with
this.

Now we could lie, and pass -D__GNU_LIBRARY__, and that would suppress
the warning.  But I don't think this would be a good solution.

Right at the moment I'm not sure what the best fix is.
For the moment, then, please just ignore the warning.
I will fix it sometime in the near future.

> The key to the problem seems to be the use
> of the specific function strcmp in the condition of the loop; if I replace
> that with a call to another function, the bug goes away.

OK.  How about defining MR_strcmp() in the same place that MR_memcpy() is
defined, then?

> > Ah.  Why does MR_insert_module_info use a linear search rather than
> > a binary search?
> > 
> > I suppose it has to do a linear memmove() anyway, so it doesn't matter
> > to much.  But a binary search should be faster.
> 
> It would, but a binary search + linear move is slower than a one-pass
> linear search & move, because it never has to load an array element twice.
> 
> In fact, in most cases there is a binary search beforehand anyway, because
> we don't know whether we want to insert the entry into the array until we
> have checked whether it is already there. However, exploiting the information
> left around by the binary search to shortcut the linear search is not trivial.
> 
> And, as you observed, the data structures involved are all small, so
> the speed of the chosen algorithm does not really matter.

Fine.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.