[E-devel] bug in libast's memset for 64bit+ architectures

2004-07-09 Thread Mike Frysinger
http://bugs.gentoo.org/show_bug.cgi?id=52634

users were noticing weird results while using Eterm and they tracked it back 
to libast's MEMSET() macro in eterm/libast/include/libast.h:

if (((unsigned long) count) >= 4 * sizeof(long)) { \
/* fill l with c. */ \
l = (c) | (c)<<8; \
l |= l<<16; \
MEMSET_LONG();

the problem being that on 64 bit archs, you'll need a little more << 
loving ... the patch provided by Jason McCarver is to add another line:
l |= l<<32; \
right before the MEMSET_LONG() call
http://bugs.gentoo.org/attachment.cgi?id=34976&action=view

perhaps the MEMSET_LONG() call itself will need updating ?
-mike


---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bug in libast's memset for 64bit+ architectures

2004-07-14 Thread Michael Jennings
On Friday, 09 July 2004, at 21:38:43 (-0400),
Mike Frysinger wrote:

> http://bugs.gentoo.org/show_bug.cgi?id=52634
> 
> users were noticing weird results while using Eterm and they tracked
> it back to libast's MEMSET() macro in eterm/libast/include/libast.h:
> 
> if (((unsigned long) count) >= 4 * sizeof(long)) { \
> /* fill l with c. */ \
> l = (c) | (c)<<8; \
> l |= l<<16; \
> MEMSET_LONG();
> 
> the problem being that on 64 bit archs, you'll need a little more << 
> loving ... the patch provided by Jason McCarver is to add another line:
> l |= l<<32; \
> right before the MEMSET_LONG() call
> http://bugs.gentoo.org/attachment.cgi?id=34976&action=view
> 
> perhaps the MEMSET_LONG() call itself will need updating ?

If SIZEOF_LONG is set to 8, meaning that a long is a 64-bit value,
MEMSET_LONG() is defined to be "l |= l<<32".  So the question becomes,
what is SIZEOF_LONG being set to?

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
---
 "Nerds make the best lovers.  That's why I'm in Speed School." 
   -- Angela Smith


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bug in libast's memset for 64bit+ architectures

2004-07-14 Thread Mike Frysinger
On Wednesday 14 July 2004 03:49 pm, Michael Jennings wrote:
> If SIZEOF_LONG is set to 8, meaning that a long is a 64-bit value,
> MEMSET_LONG() is defined to be "l |= l<<32".  So the question becomes,
> what is SIZEOF_LONG being set to?

configure output:
checking size of char... 1
checking size of short... 2
checking size of int... 4
checking size of long... 8
checking size of long long... 8

config.h:
amd64 libast-0.5 # grep SIZEOF_ config.h
#define SIZEOF_CHAR 1
#define SIZEOF_INT 4
#define SIZEOF_LONG 8
#define SIZEOF_LONG_LONG 8
#define SIZEOF_SHORT 2
-mike


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bug in libast's memset for 64bit+ architectures

2004-07-14 Thread Michael Jennings
On Wednesday, 14 July 2004, at 19:35:36 (-0400),
Mike Frysinger wrote:

> > If SIZEOF_LONG is set to 8, meaning that a long is a 64-bit value,
> > MEMSET_LONG() is defined to be "l |= l<<32".
> 
> #define SIZEOF_LONG 8

Okay, then I have to wonder why the #if isn't working

Check the cpp output and see if MEMSET_LONG() is being defined
properly.  If not, why not?  If so, then why is another line of the
same thing needed?

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
---
 "I am the only one to blame for this.  Somehow it all ends up the
  same.  Soaring on the wings of selfish pride, I flew too high, and
  like Icarus I collide with a world I tried so hard to leave behind.
  To rid myself of all but love, to give and die."
   -- Jars of Clay, "Worlds Apart"


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bug in libast's memset for 64bit+ architectures

2004-07-14 Thread Mike Frysinger
On Wednesday 14 July 2004 08:46 pm, Michael Jennings wrote:
> Okay, then I have to wonder why the #if isn't working
>
> Check the cpp output and see if MEMSET_LONG() is being defined
> properly.  If not, why not?  If so, then why is another line of the
> same thing needed?

i'm going to take a stab here ... feel free to mark me wrong on this :)

in libast, the size checks are run and the SIZEOF_* defines are added to the 
local config.h ... great, so when you actually build libast, it has the 
proper MEMSET_LONG() macro because it pulls in the local config.h ...

however, when Eterm is built, it does not do similar size checks from the 
configure script and thus has no SIZEOF_* defines ... and since the original 
config.h from libast was not saved ...
when you include libast.h from eterm, SIZEOF_LONG is not defined thus the 
MEMSET_LONG() macro and the 32 bit shift voodoo is lost :(
-mike


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bug in libast's memset for 64bit+ architectures

2004-07-14 Thread Michael Jennings
On Wednesday, 14 July 2004, at 22:36:27 (-0400),
Mike Frysinger wrote:

> in libast, the size checks are run and the SIZEOF_* defines are
> added to the local config.h ... great, so when you actually build
> libast, it has the proper MEMSET_LONG() macro because it pulls in
> the local config.h ...
> 
> however, when Eterm is built, it does not do similar size checks
> from the configure script and thus has no SIZEOF_* defines ... and
> since the original config.h from libast was not saved ...  when you
> include libast.h from eterm, SIZEOF_LONG is not defined thus the
> MEMSET_LONG() macro and the 32 bit shift voodoo is lost :(

Well, shit.  See, in libast 0.6, sysdefs.h takes care of making sure
these things are defined.  libast 0.5, however, doesn't (IIRC).  Can
you see if this patch fixes the problem?


Index: include/libast.h
===
RCS file: /cvsroot/enlightenment/eterm/libast/include/libast.h,v
retrieving revision 1.51
diff -u -r1.51 libast.h
--- include/libast.h29 Jun 2004 21:18:07 -  1.51
+++ include/libast.h15 Jul 2004 02:55:40 -
@@ -1137,7 +1137,7 @@
 #endif
 
 /* Fast memset() macro contributed by vendu */
-#if (SIZEOF_LONG == 8)
+#if !defined(SIZEOF_LONG) || (SIZEOF_LONG == 8)
 /** UNDOCUMENTED */
 # define MEMSET_LONG() (l |= l<<32)
 #else




Thanks,
Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
---
 "No weapon formed against us shall prosper.  All those who rise
  against us shall fall.  I will not fear what the devil may bring
  me; I am a servant of God." -- Petra


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bug in libast's memset for 64bit+ architectures

2004-07-14 Thread Mike Frysinger
On Wednesday 14 July 2004 10:59 pm, Michael Jennings wrote:
> Well, shit.  See, in libast 0.6, sysdefs.h takes care of making sure
> these things are defined.  libast 0.5, however, doesn't (IIRC).  Can
> you see if this patch fixes the problem?

i only have access to a headless amd64 server :)

i'll get feedback from some users but chances are it works ... patch is simple 
enough :)
-mike


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bug in libast's memset for 64bit+ architectures

2004-07-14 Thread Mike Frysinger
On Wednesday 14 July 2004 10:59 pm, Michael Jennings wrote:
> Well, shit.  See, in libast 0.6, sysdefs.h takes care of making sure

oh, forgot to ask ... any idea on release dates for next libast/eterm ?  ive 
been watchin cvs commits like a hawk ;)
-mike


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bug in libast's memset for 64bit+ architectures

2004-07-15 Thread Michael Jennings
On Wednesday, 14 July 2004, at 23:44:12 (-0400),
Mike Frysinger wrote:

> i only have access to a headless amd64 server :)

The only Opteron box I have access to belongs to a customer, so you're
better off than I. :)

> i'll get feedback from some users but chances are it works ... patch
> is simple enough :)

I'm hoping so.  In any event, I can solve the issue from both sides
simply by requiring libast 0.6 for Eterm 0.9.3, but I'd hoped to avoid
that.

> oh, forgot to ask ... any idea on release dates for next
> libast/eterm ?  ive been watchin cvs commits like a hawk ;)

Well, patches have been coming in here and there, but I think they're
both ready to pop...as soon as I can find some time to tackle the
releases.

You're welcome to move to CVS libast and Eterm; honestly, I'd welcome
the advance testing, especially on 64-bit.  Rumor hasn't CVS Eterm may
not build on AMD64. :-(

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
---
 "Don't let them cry.  Don't paint me a saint, and don't let them
  cry." -- Greg Germann, "Ally McBeal"


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bug in libast's memset for 64bit+ architectures

2004-07-15 Thread Michael Jennings
On Thursday, 15 July 2004, at 15:10:56 (-0400),
I screwed the pooch when I wrote:

> Rumor hasn't CVS Eterm may not build on AMD64. :-(

That said "Rumor has it."  Move along now.  Nothing to see here.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
---
 "Don't risk more than you can afford to walk away without."
   -- Rule of Life #39


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bug in libast's memset for 64bit+ architectures

2004-07-17 Thread Mike Frysinger
On Wednesday 14 July 2004 10:59 pm, Michael Jennings wrote:
> Can you see if this patch fixes the problem?

had the original reporter confirm that your patch fixed it

thanks :)
-mike


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bug in libast's memset for 64bit+ architectures

2004-07-21 Thread Mike Frysinger
On Thursday 15 July 2004 03:10 pm, Michael Jennings wrote:
> You're welcome to move to CVS libast and Eterm; honestly, I'd welcome
> the advance testing, especially on 64-bit.  Rumor hasn't CVS Eterm may
> not build on AMD64. :-(

i tried running the autogen script from a cvs checkout on my amd64 box but i 
just hit a ton of autotool errors ...
any chance you could snapshot cvs with autogen already run so i can test it 
out for you ?
-mike


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] bug in libast's memset for 64bit+ architectures

2004-07-22 Thread Michael Jennings
On Thursday, 22 July 2004, at 00:46:07 (-0400),
Mike Frysinger wrote:

> i tried running the autogen script from a cvs checkout on my amd64
> box but i just hit a ton of autotool errors ...  any chance you
> could snapshot cvs with autogen already run so i can test it out for
> you ?

I'd be happy to.  Find me on IRC and I'll DCC you a tarball.

But I'm concerned about these auto[fuck] (*grin*) errors.  Other than
perhaps some underquoted whinings from automake 1.8, there shouldn't
be any. :(

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/   Author, Eterm (www.eterm.org)
---
 "I don't want this place to get a reputation for buggy software."
 "Where do you think Microsoft would be if they waited until their
  products actually worked before they sold them?"
  -- Mark-Paul Gosselaar and Victor Slezak, "Hyperion Bay"


---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
___
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel