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

Jens Thoms Toerring jt at toerring.de
Wed May 20 00:07:11 CEST 2009


To subscribers of the xforms list

Hi Joel,

On Tue, May 19, 2009 at 10:34:37AM -0500, JOEL.MOOTS at L-3com.com wrote:
> > 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.
>  
> Wow. Can't believe I've been living such an ignorant (and lucky) life so
> far; I figured it said something about my programming.

I think it's rather common that people assume that there's no
problem with casting between integers and pointers - for the
most common platforms it works well. I guess you must either
have been bitten by such problems or learned about them in
places like comp.lang.c to become aware of them (I wouldn't
expect anyone to read the C standard just for the fun of it;-)
And there are lots of tutorials that don't mention it or even
encourage such casts. I also only became more careful after I
spend a lot of time cleaning up one of my programs that worked
nicely on one architecture but crashed badly when I had to port
it to another (due to some different but similar problem)! Only
then I started to learn that there are a lot of things in C that
usually work but aren't guaranteed to work everywhere and nowadays
try to avoid them...

> Anyway, as that is the case, wouldn't it make sense to have all the
> prototypes use 'long' since the FL_OBJECT argument member that
> fl_set_object_callback sets is 'long' anyway? It shouldn't break any
> existing code, and we'd be consistent at least. Any conversions from 'void
> *' to 'long' and back would continue to behave the same, and we could always
> switch any such unsafe code to use the extra u_ members, right?

But then you would get a lot of warnings (and perhaps even com-
pile time errors with C++) for existing programs that use correct
arguments for e.g. form callbacks which expect a void pointer in-
stead of a long. I guess I would be pretty annoyed if my cleanly
compiling code suddenly would throw lots of warnings or worse...

> > 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;-)
> 
> I can't think of *any* way (ugly or not) to allow this in C without
> breaking code. I suppose we could duplicate a lot of code/members and
> give the user the option of which type of callback to use, but, as
> someone used to tell me, the "juice is not worth the squeeze."

I haven't spend too much time thinking about this yet. If there's
a solution that uses macros to get around the issue it definitely
will require at least small changes to legacy code, like adding
a define before inclusions of <forms.h> or a call of a function
before fl_initialize(). I guess that would still be acceptable,
at least there weren't too many complaints I remember when with
version 0.89 the y-axis was switched and for older code you had
to add a call of fl_flip_yorigin() to get it to work again. But
as I already said, I haven't spend enough time on this to even
have any good idea if it might work at all...

                             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



More information about the Xforms mailing list