>> 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 [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user