#define OBJ_MEMBER_UINT(obj,offset) (*(t_CKUINT *)OBJ_MEMBER_DATA(obj,offset)) ... #define t_CKUINT t_CKDWORD ... #define t_CKDWORD unsigned long
There's also this: #define OBJ_MEMBER_DATA(obj,offset) (obj->data + offset)
On Fri, Apr 27, 2007 at 06:00:10PM +0200, Michel Koppelaar wrote:
Hi,
I seem to be having the same problem. I've been trying to get ChucK to run on AMD64/Linux these last few days. Tried alsa, oss and jack build options: segfaults in each case. More details: <snip>
Hopefully this can be sorted out. I'm really interested in trying out ChucK.
Hmm, I dug around a bit, not really knowing what I'm doing, but I suspect that the culprit is probably an assumption about the size of UINTS... a 32-bit vs 64-bit issue. My eye was drawn to that OBJ_MEMBER_UINT() macro, and I took a shimmering journey into the
Speaking as a professional C++ programmer.... 1) In defense of Ge, few of us get the opportunity to work on code that doesn't have legacy. Even when we do, few of us manage to produce code that ages well, in retrospect. 2) 32 to 64 bit ports are non-trivial. 3) The analysis given is incorrect. The code in question is fine, as long as none of your classes exceed 16GB in size. Whatever the problem is, it's not in the cited code. 4) Although C++ inline functions are preferrable to macros, sylistically speaking, the functionally equivalent C++ inline functions are not, in fact, any safer than the macros in this case. In this particular case, I believe your friend is right. The code in question would not be rewritten because there's not actually a compelling improvement that can be made at this point. Robin Davies Lead Software Developer Quest Web Reports Quest Software 613.270.1569 Identity Management for the Windows Enterprise: See how Quest helps you leverage your existing investment to solve the identity management challenge! -----Original Message----- From: chuck-users-bounces@lists.cs.princeton.edu [mailto:chuck-users-bounces@lists.cs.princeton.edu] On Behalf Of Ken Restivo Sent: Saturday, April 28, 2007 1:56 PM To: ChucK Users Mailing List Subject: Re: [chuck-users] Anyone else running ChucK dual-core in 64-bitmode? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Apr 27, 2007 at 11:09:50AM -0700, Ken Restivo wrote: through-the-looking-glass world of defines on top of defines on top of defines:
#define OBJ_MEMBER_UINT(obj,offset) (*(t_CKUINT
... #define t_CKUINT t_CKDWORD ... #define t_CKDWORD unsigned long
There's also this: #define OBJ_MEMBER_DATA(obj,offset) (obj->data + offset)
So, if offset just happens to be a 32-bit value, that smells to me
*)OBJ_MEMBER_DATA(obj,offset)) like a likely source of a segfault. Offset probably needs to be a long long, doesn't it?
I asked a friend who does a lot of C++ work to take a brief look at this. He shook his head sadly at the use of macros instead of inline functions, the use of casts to obliterate type safety, of #define's instead of typedefs, and the obscuring of the likelihood that ->data is a struct. He said, basically, this is C, not C++, regardless of what the file extension says. I poked around some more and it looks like a lot of the Ugen code was lifted from another, older project-- maybe that was C code? He also didn't hold out much hope that any of its developers would show any interest in fixing this stuff either. The OBJ_MEMBER_UINT's are all over the filter, osc, xxx(?!), and stk ugens, as well as the Std lib. The obj->data stuff is in chuck_instr.cpp but nowhere else. But it's hard to tell how much stuff like this is lurking elsewhere in the code. I'd be willing to do the gruntwork of search-and-replacing code, if someone who knows what they're doing wants to tell me pretty much exactly what to do. If nobody jumps up to do that over the next day or two, it'd probably be a better use of time to start learning CSound instead, and maybe have another look at ChucK in a few years if anyone gets it 64-bit safe by then. - -ken -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD4DBQFGM4qSe8HF+6xeOIcRAllFAJ9VjIJ8C1UYwQZKeqYragR9CE2UIwCVEhRC xcHaCfclv2oU2g0ermIGsw== =mpph -----END PGP SIGNATURE----- _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users