gEDA-dev: _Other_ code problems

[DJ Delorie]

I'm not going to try to apply and test these tonight; it's too late
for me for that kind of stuff.  Comments I can do though..

> There's a typo in an assert() in rtree.c.  The fix is to compare Y with
> Y, not X, in the last >:

OK.

> The batch HID won't even build, because it's missing file watch and
> block hook functions, and its progress function return type is wrong.

I use it for the web server, so it doesn't get rebuilt often.  I'll
look into it unless Dan beats me to it.

> (I found this before discovering I don't want to build it because it
> claims to be a GUI HID, even though there's nothing G about its UI, and
> thus, depending on order in the list in hidlist.h, likes to preempt my
> GUI HID.)

Well, "gui" in this case means "the primary interface with the user"
as opposed to, for example, export/import/printing HIDs.

I'm surprised the configury let you select it.  I don't think it's
supposed to allow more than one gui hid, although it would be cool if
you could select them at runtime.

> autoroute.c has an assert() referring to "region", which is not
> declared anywhere I could find:

Unusual.  I guess we don't test with assertions enabled.

> There are some more things which aren't really bugs, but are things I
> had to change, because the compiler I'm using didn't like them.

Which compiler?

> Several places have object declarations following executable code.

That's bad and should be fixed.

> macro.h uses an unrecognized #pragma.  If this is doing what it looks
> like, it could perhaps be more portably done by #defining them to
> something that will produce a syntax error.

It's not quite the same.  Poisoning only affects uses of the token in
the source, not uses of the token as the expansion of a previous macro
definition.

But the #if should have kept it out, perhaps we need to test gcc's
version number too.

> I ripped out hid_load_dir() in hid/common/hidinit.c because it would
> prevent me from linking static;

Yeah, that change isn't useful in general unless you can come up with
a ./configure option for it.

> I ripped out the calls to bindtextdomain and bind_textdomain_codeset
> in main.c because I couldn't find them anywhere (presumably they
> come from some facility "everyone" has but I don't);

libintl.  You can get it from the FSF's gettext package.  A patch to
test for it in configure and conditionalize it would be OK though.

> and I changed the varargs DEBUGP macros in polygon1.c to match my
> compiler's varargs macro syntax.

Probably needs to be conditionaled on a gcc version check.