[XForms] New pre-release: xforms-1.0.92pre3

[Jens Thoms Toerring]

To subscribers of the xforms list

Hi Joel,

On Mon, May 18, 2009 at 09:45:38AM -0500, JOEL.MOOTS at L-3com.com wrote:
> >   Another thing I am rather unhappy with is the prototypes for
> > callback functions. Some callbacks take a 'long' as the second
> > argument, others a void pointer. There doesn't seem to be any
> > obvious reason why one of them is used. And in some situations
> > a 'long' value is quite useful, but in others a void pointer
> > is much better and when there's only a 'long' that can be passed
> > to the callback there's the temptation to use casts between
> > pointer and integer types (that work on a lot of architectures
> > but aren't correct C and may fail on some architectures). IMHO
> > it would be best if each callback would receive both a long and
> > a void pointer. But that would break a lot of existing code. If
> > anybody has a good idea on how to deal with that I would be de-
> > lighted to hear about it!
> 
> I've always wondered about this too. I suppose I'm ignorant when it
> comes to many architecture issues, but the only reason I can think of
> for using some long type rather than always void *  would be to allow
> use of data in some cases without a cast. Personally, I think it should
> always be void *, but that would obviously break existing code that does
> not cast. I don't see how casting from void * to integer types is not
> 'correct' C (which probably just says something of my programming);
> isn't that pretty much the standard way all Xt stuff works? So, I don't
> really see any value in adding an additional arg.

The problem with casting between (object) pointers and integers
(be it normal ints or long ints) is that the C standard doesn't
allow it - or at least declares it as only "implementation defined".
I.e. it's not forbidden to work but also not guaranteed to work
everywhere. On most architectures it indeed does work, but there
seem to be some where it doesn't (I don't remember which ones that
are, I would have to ask the guys in comp.lang.c, but there are
some really weird architectures in the wild;-) and I guess that
is why it's not allowed in general by the C standard.

Perhaps POSIX requires it to work (like it requires that you
can convert between void and function pointers, that the C
standard sees as undefined behaviour but which is needed for
dlsym(3) to work) but I am not aware of that...

> I don't have much 64-bit experience, but I could see how using a long
> might fail (if long were no longer large enough to hold all pointer
> types), in which case, switching to void * would necessary, since it is
> guaranteed to be large enough.

On the 64-bit architecture I am just using it does work - a long
has also 64 bits but I don't know if that can be taken for granted.
Admittedly, I am a bit pedantic  when it comes to C and thus I
would normally not cast between pointers and integers. But what
I am also not too happy with is that it looks rather random for
which kind of callback functions a long is used and for which a
void pointer, at least I wasn't able yet to find any system be-
hind it...

> Or we could possibly use a typedef
> somewhere (akin to the XtPointer) and always use that type. Then most
> folks, if they desired a long type everywhere, could probably use it
> with little to no compile errors..

I don't see at the moment how to get around the casting issue with
typedefs. I am currently pondering if it would be possible to use
a union with a long and a void pointer and perhaps to get it to work
by use of some macros without breaking existing code (or at least
not requiring extensive rewrites), but I haven't figured out any-
thing that would work and isn't too ugly;-)

                              Best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      jt at toerring.de
   \_______________________________      http://toerring.de
_______________________________________________
To unsubscribe, send any message to
xforms-leave at bob.usuhs.mil or see: 
http://cweblog.usuhs.mil/mailman/listinfo/xforms
List Archive: http://bob.usuhs.mil/pipermail/xforms and
http://bob.usuhs.mil/mailserv/list-archives/
XForms Home: http://savannah.nongnu.org/projects/xforms