Re: gEDA-user: What to do with some bugs?

[der Mouse <mouse@xxxxxxxxxxxxxxxxxxxxxx>]

>> to my environment, which means writing a new HID
> What environment?  Curious minds want to know...

"Mine".  I'm not sure which aspect(s) of it you're interested in.  It's
X11R6.4p3 on NetBSD/sparc 1.4T plus a bunch of local hacks - all of
which is irrelevant to my decision to build my own HID.

I would rather write a new HID than subject myself to the pain of
fetching and building either GTK or lesstif - and then the additional
pain of using the resulting interface.  I have fairly sharp UI
preferences in many regards, and as far as I can tell they are such
outliers that any toolkit that's achieved reasonable popularity will
result in an interface that's somewhere between irritating and
intolerable to me for more than trivial use.  (Not that this means
there's anything wrong with GTK or lesstif per se, just that they're
wrong for my use.)

I don't expect any significant number of people will like the resulting
HID's style, but anyone who wants is certainly welcome to a copy of the
code.  Once I _have_ code, that is; at the moment it's almost entirely
printf() stubs.

>> (The concealment condition is basically that all nil pointers have
>> the same size and bit pattern, in a varargs argument list, as
>> integer zero.  [...])
> We already test on both 32 and 64 bit hosts; all such null pointers
> should use the NULL macro.

[The following applies to the 20080202 snapshot, .tar.gz MD5 
933eda642f3838b24d417224693f8386.  For all I know some/all of them may
have been fixed since then.]

Well, they don't; most of the calls to the HID's confirm_dialog use a
bare 0 as a terminator.  If memory serves, two more calls have no
terminator at all, and a third call sometimes is two (varargs) args
plus a terminator and sometimes three with no terminator, depending on
a run-time test (it's got a ?: in the third variable arg).

But the real problem is that using NULL is simply _wrong_ in a context
which provides no type - and there aren't many such contexts in C, but
a varargs argument that's in the variable part of the arglist is one.
C implementations are permitted to define NULL as an integer constant
expression with value zero, or such an expression cast to void *.
Because of the first option, bare 0 is suitable anywhere NULL is (from
a code-correctness point of view, that is; in many cases there is some
slight value in the implicit comment that the author thinks of it as a
pointer), so using 0 is no worse than NULL...but it's wrong in this
case, because the argument needs to be a char *.  (void * is acceptable
in this particular case, because there is special language in the C
spec requiring char * and void * to have identical size and
representation, but in general the actual argument type must match the
formal argument type, except for qualifiers.)

hid_actionl() has similar issues.  Others might too; those are the only
ones I've noticed so far.

However much some people might wish otherwise, C simply does not have a
generic nil pointer suitable for use in contexts that, like varargs
arglists, don't provide a type.  I believe it - NULL, that is - simply
should never be used.  The confusion it produces just isn't worth the
tiny additional pseudo-comment that the coder thinks of the value as a
pointer, which is all it provides over a bare 0 (indeed, all it _can_
provide, since bare 0 is one of the blessed definitions for NULL).

>> Any recommendations?  Is this an appropriate place to report such
>> things, or should I write to someone specific, or what?
> geda-dev is slightly better.

I've sent in a subscribe request, and will take the code discussion
there.  (There are some other bugs as well; the NULL issues are not the
only thing I've found.)

>> And, if there's anyone with the time, inclination, and knowledge to
>> answer some internals questions, [...]
> Mostly, that's me.  Again, geda-dev is the best place for that.

Again, I'll take those there, then.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@xxxxxxxxxxxxxxxxxxxxxx
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user