Re: [chris@beezer.med.miami.edu: Re: What's wrong with bluefish?]
On Mon, 12 Jul 1999, Chris Mazuc wrote:
> Item 4 seems to be what screws up the Alpha compiles. Here's how I got it
> to work the way I needed it to...
>
> Item 4 wants an int, I needed to put a string there because it would
> simplify things GREATLY. After trying various things, it somehow worked by
> casting the char* to int because it got cast back to a char* somewhere
> withing GTK. I still do not know how this worked.
>
> This is what happens without the cast to int...
>
> In file included from toolbars.c:41:
> menu.h:86: warning: initialization makes integer from pointer without a cast
>
> It still works on my system, but having appx 400 warnings pop up during a
> compile is not something I like to see, esp when it works if I do a cheesy
> hack like casting it to an int. ;)
Hmmm...well, technically, doing such casts really isn't great to do since
it's Just Not Proper(TM). But, I don't think that the cast is what's
throwing us for a loop here. It appears that the compiler itself is
ignoring the quotes and trying to interpret something like "&test" just
like it does with &test (which are obviously two seperate things). It
would be more proper, obviously, to not do such casts, though, and rather
associate the ints with the text another way. This may be the only way
that we're going to compile it on the Alpha for now, unfortunately.
> The GTK stuff says that using gint is more portable than using just
> straight int. So if someone wants to try that as a fix, then run "sed
> s/(int)/(gint)/ menu.h". I'm not sure if that will do much other than just
> cast it back to regular int. It might work, who knows.
I'll give it a shot, but I don't think it'll work. From my (very)
limited knowledge of GTK, it seems that they try to provide something akin
to a "magic box" programming model, where you give it info and it
transforms it for you (hence the cast to int working somehow), but this
behaviour may not be terribly portable, unfortunately.
> I'm pretty clueless about this as the highest bit processor I have worked
> with is 32 and I can't test for stuff like this. I really need to get an
> alpha... hehe.
Hehehehe...you should! 64-bit Linux is a wonderful thing :-) It's really
not hard to adapt to and it seems that the code is portable otherwise, so
I wouldn't worry too much. Just be careful when it comes to assumptions
about the sizes of some of the common types. On Alpha, short=2, int=4,
and long=8. Also, void=8, fyi....a big change from i386-land...
C
Reply to: