Re: Fribidi not 64-bit friendly?

Oops.  Attached.
Also CC to FriBidi list.

On Thu, 22 Jul 2004, Behdad Esfahbod wrote:

> On Sat, 17 Jul 2004, Mark Gilbert wrote:
>
> > I already did this, btw, against 0.10.4.  you want my patch or...?
> >
> > I used AC_SIZEOF checks and have the same in abi (tomas had some really
> > silly typedef to match fribidi which didnt work when I changed fribidi
> > so I replaced that with something more correct).
>
> Hehe, exactly what I did.  I've attached my patch, you may want
> to adapt.  Well, not sure, but should work with 0.10.4 tree too.
>
> You may want to try the CVS version from freedesktop.org too, I'm
> running AbiWord with it successfully. (with a line of patch to
> abi/includes.mk to not include ../wv/glib-wv, since new FriBidi
> includes Glib if available, and the two of them don't go with
> eachother.)
>
> Later,
> behdad
>
> > On Sat, 2004-07-17 at 18:26, Behdad Esfahbod wrote:
> > > Hi Mark,
> > >
> > > Ok, seems like you are right.  You can temporarily solve the
> > > problem by putting some preprocessor stuff to find the correct
> > > 32bit integer.  In the new FriBidi code (available in CVS
> > > accessible from http://freedesktop.org/Software/FriBidi) I've put
> > > enough stuff to solve the problem.
> > >
> > > behdad
> > >
> > >
> > > On Sat, 17 Jul 2004, Mark Gilbert wrote:
> > >
> > > > We have a bit of a problem here in AbiWord.  It is manifesting several
> > > > ways, including footnote fields (see assert log below).  It is starting
> > > > to look as though it may originate or at least be related to fribidi not
> > > > being 64-bit friendly (I don't know, the bug is beyond my expertise,
> > > > seeking your help).  Following is excerpts from a conversation on irc,
> > > > after I asked plam if I could paste an assert to see if it was relevant:
> > > >
> > > > <mgF> DEBUG: !!!Populate:InsertObject:Field: BlockOffset 104
> > > > <mgF> **** (92) Assert ****
> > > > <mgF> **** (92) sizeof(UT_UCS4Char) == sizeof(FriBidiChar) at
> > > > ../../../../../abi/src/af/util/xp/ut_string.cpp:1601 ****
> > > > <mgF> **** (92) Continue ? (y/n) [y] :
> > > > <mgF> DEBUG: fl_DocListener::populateStrux for 'SectionFootnote'
> > > > <plam> yes, it's relevant.  however, i don't get it.
> > > > <mgF> plam: there's about 60-80 like that, plus others with slightly
> > > > different context but same assert
> > > > <mgF> plam: what should I do from here to track down the problem, if you
> > > > can't repro it?
> > > > <plam> why don't you md5sum the file?
> > > > <plam> the rtf
> > > > <plam> 49ca69ed1073245c96a3aa7e9b5cc271  bug7081.rtf
> > > > <mgF> it matches
> > > > <plam>  // if this assert fails, we have a serious problem ...
> > > > <plam>  UT_ASSERT_HARMLESS( sizeof(UT_UCS4Char) == sizeof(FriBidiChar)
> > > > );
> > > > * mgF gets that weird premonition in the back of his head of martin
> > > > telling him yet again that it's one of Tomas' unsafe 0xffffffff values
> > > > or something causing problems on 64bit archs
> > > > <mgF> plam: eep
> > > > <plam> are you running on a 64bit arch?
> > > > <mgF> yes
> > > > <plam> that would probably do it, i bet.
> > > > <mgF> one of those two is probably a 4byte like my int (UCS4Char?),
> > > > while the other is 8byte like my long and pointer
> > > > <plam> uhhhh...
> > > > <plam> long is 64 bit, huh.
> > > > <plam> fribidi says that an in32 is long.
> > > > <mgF> plam: so, any ideas on how to fix it?  I have about 8 large
> > > > serious sets of regressions pending for tomas when he gets back, I'd
> > > > like to not count on waiting for him to fix the 9th as well /-:
> > > > <plam> is fribidi 64-bit friendly?  it seems to not be.
> > > > <mgF> wouldnt surprise me, but I couldn't tell you for sure not being at
> > > > all familiar with the code
> > > > <mgF> .oO(I wonder if that guy...the guy...damn what's his name from
> > > > fribidi, if he could provide some insight)
> > > > [Referring to you]
> > > > <mgF> plam: suggestion(s) on how to proceed?
> > > > * plam is looking up google and fribidi and 64 bits.
> > > > <plam> why don't i delegate that to you?
> > > > <mgF> heh, sure thing
> > > > * mgF is pretty good at googling
> > > > <plam> yeah, i suspect the rest of the problem may have to do with
> > > > fribidi not being 64-bit friendly.  you might want to mail the fribidi
> > > > devs or something.
> > > > <plam> #define FRIBIDI_INT32   long
> > > > <plam> doesn't quite seem correct.
> > > >
> > > > Naturally it does not, long being 64 bits over here.
> > > >
> > > > Anyway, I was wondering if you could help me out.  I am running 0.10.4,
> > > > willing to test patches, we think (for the moment) that fribidi + x86_64
> > > > == disaster and would like to fix that.
> > > >
> > > > Regards
> > > > -MG
> > > >
> > > > (feel free to drop in on #abiword again, we've talked in there before,
> > > > which is how I remembered you)
> > > >
> > > >
> > > >
> > >
> > > --behdad
> > >   behdad.org
> > >
> >
> >
>
> --behdad
>   behdad.org
>

--behdad
  behdad.org

_______________________________________________
fribidi mailing list
[email protected]
http://freedesktop.org/mailman/listinfo/fribidi

diff -u -p -r1.74 ut_string.h
--- src/af/util/xp/ut_string.h	23 Apr 2004 15:26:50 -0000	1.74
+++ src/af/util/xp/ut_string.h	22 Jul 2004 16:14:59 -0000
@@ -250,11 +250,10 @@ ABI_EXPORT UT_UCS4Char       UT_UCS4_tou
 */
 ABI_EXPORT const char*  std_size_string(float f);
 
-// for now we do this to match def. of FriBidiCharType; after 2.2, we will migrate to platform specific definitions ...
-typedef long UT_BidiCharType;
-
 #include <fribidi.h>
 
+typedef FriBidiCharType UT_BidiCharType;
+
 #define UT_BIDI_LTR FRIBIDI_TYPE_LTR
 #define UT_BIDI_RTL FRIBIDI_TYPE_RTL
 #define UT_BIDI_WS FRIBIDI_TYPE_WS
@@ -275,8 +274,8 @@ typedef long UT_BidiCharType;
 #define UT_BIDI_ON FRIBIDI_TYPE_ON
 
 
-#define UT_BIDI_UNSET FRIBIDI_TYPE_UNSET
-#define UT_BIDI_IGNORE FRIBIDI_TYPE_IGNORE
+#define UT_BIDI_UNSET (FRIBIDI_TYPE_PRIVATE+1)
+#define UT_BIDI_IGNORE (FRIBIDI_TYPE_PRIVATE+2)
 
 #define UT_BIDI_IS_STRONG FRIBIDI_IS_STRONG
 #define UT_BIDI_IS_WEAK FRIBIDI_IS_WEAK