Re: PARROT_ASSERT considerations

2008-03-11 Thread Bob Rogers
From: Andy Lester <[EMAIL PROTECTED]> Date: Tue, 11 Mar 2008 20:10:19 -0500 On Mar 11, 2008, at 8:08 PM, Bob Rogers wrote: > 0xdeadbeef is odd, so it doesn't even have word alignment on > byte-addressable machines. So you don't even have to check on most > architectures. True?

Re: PARROT_ASSERT considerations

2008-03-11 Thread Andy Lester
On Mar 11, 2008, at 8:08 PM, Bob Rogers wrote: 0xdeadbeef is odd, so it doesn't even have word alignment on byte-addressable machines. So you don't even have to check on most architectures. True? The word "most" frightens me. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:

Re: PARROT_ASSERT considerations

2008-03-11 Thread Bob Rogers
From: Andy Lester <[EMAIL PROTECTED]> Date: Tue, 11 Mar 2008 20:01:07 -0500 On Mar 11, 2008, at 6:12 PM, Geoffrey Broadwell wrote: > I'm confused here. My understanding of the difference between > PARROT_ASSERT and the PARROT_ASSERT_POINTER suggestion is that the > former check

Re: PARROT_ASSERT considerations

2008-03-11 Thread Andy Lester
On Mar 11, 2008, at 6:12 PM, Geoffrey Broadwell wrote: I'm confused here. My understanding of the difference between PARROT_ASSERT and the PARROT_ASSERT_POINTER suggestion is that the former checks for truth, and the other would check for lack of obvious insanity. A pointer of 0 is always,

Re: PARROT_ASSERT considerations

2008-03-11 Thread Geoffrey Broadwell
On Tue, 2008-03-11 at 23:01 +0100, Ron Blaschke wrote: > Andy Lester wrote: > > > > On Mar 11, 2008, at 2:43 PM, Ron Blaschke wrote: > > > >> It ties pointers to INTVALs, which I guess it shouldn't. > > > > > > As I read the mail, it seems like the only problem we have is in casting > > the po

Re: PARROT_ASSERT considerations

2008-03-11 Thread Ron Blaschke
Andy Lester wrote: On Mar 11, 2008, at 2:43 PM, Ron Blaschke wrote: It ties pointers to INTVALs, which I guess it shouldn't. As I read the mail, it seems like the only problem we have is in casting the pointer to an int to find its truthiness. I'd say use the !!(x) and be done with it.

Re: PARROT_ASSERT considerations

2008-03-11 Thread Leopold Toetsch
Am Dienstag, 11. März 2008 22:39 schrieb Ron Blaschke: > >     if (!x) \ There were of course some parens missing ... if (!(x)) \ leo

Re: PARROT_ASSERT considerations

2008-03-11 Thread Ron Blaschke
Leopold Toetsch wrote: Am Dienstag, 11. März 2008 20:43 schrieb Ron Blaschke: void Parrot_assert(INTVAL condition, ARGIN(const char *condition_string), ARGIN(const char *file), unsigned int line) ... PARROT_ASSERT is used to assert pointers too, for example in src/string.c: What abou

Re: PARROT_ASSERT considerations

2008-03-11 Thread Leopold Toetsch
Am Dienstag, 11. März 2008 20:43 schrieb Ron Blaschke: > void > Parrot_assert(INTVAL condition, ARGIN(const char *condition_string), >          ARGIN(const char *file), unsigned int line) > ... > > PARROT_ASSERT is used to assert pointers too, for example in src/string.c: What about making Parrot_

Re: PARROT_ASSERT considerations

2008-03-11 Thread Andy Lester
On Mar 11, 2008, at 2:43 PM, Ron Blaschke wrote: It ties pointers to INTVALs, which I guess it shouldn't. As I read the mail, it seems like the only problem we have is in casting the pointer to an int to find its truthiness. I'd say use the !!(x) and be done with it. The PARROT_ASSERT_

PARROT_ASSERT considerations

2008-03-11 Thread Ron Blaschke
PARROT_ASSERT is currently defined as: #ifdef NDEBUG # define PARROT_ASSERT(x) ((void)0) #else # define PARROT_ASSERT(x) Parrot_assert((INTVAL)(x), #x, __FILE__, __LINE__) #endif with void Parrot_assert(INTVAL condition, ARGIN(const char *condition_string), ARGIN(const char *file),