On Thu, May 17, 2007 at 11:13:45AM -0700, jerry gay wrote:
> then what the heck does c89 compliance mean for parrot, if it's beyond
> our control because we can't change system headers? i mean, how do you
The Parrot code itself can be C89 compliant, such that Parrot contains no
issues that preven
On 5/17/07, Mark Glines <[EMAIL PROTECTED]> wrote:
On Thu, 17 May 2007 11:13:45 -0700
"jerry gay" <[EMAIL PROTECTED]> wrote:
> char *s = s_key;
> *s = 0;
> however... why is 's' nulled out, directly after it's initialized to
> 's_key'? that looks funny.
The first line d
On Thursday 17 May 2007 11:13:45 jerry gay wrote:
> On 5/17/07, chromatic <[EMAIL PROTECTED]> wrote:
> > Unfortunately, our headers (and even some system headers) don't follow
> > C89:
> then what the heck does c89 compliance mean for parrot, if it's beyond
> our control because we can't change
On Thu, 17 May 2007 11:13:45 -0700
"jerry gay" <[EMAIL PROTECTED]> wrote:
> char *s = s_key;
> *s = 0;
> however... why is 's' nulled out, directly after it's initialized to
> 's_key'? that looks funny.
The first line declares a pointer, pointing to s_key. The second lin
On 5/17/07, chromatic <[EMAIL PROTECTED]> wrote:
On Thursday 17 May 2007 09:32:01 jerry gay wrote:
> this revision breaks parrot on msvc (and i suspect other c89-compliant
> compilers--sometimes i wonder if there are any others!)
I doubt even MSVC is C89-compliant, to be honest. It just barfs
On Thursday 17 May 2007 09:32:01 jerry gay wrote:
> this revision breaks parrot on msvc (and i suspect other c89-compliant
> compilers--sometimes i wonder if there are any others!)
I doubt even MSVC is C89-compliant, to be honest. It just barfs more often
than GCC on certain things.
> this sit
this revision breaks parrot on msvc (and i suspect other c89-compliant
compilers--sometimes i wonder if there are any others!)
in particular, in the following chunk (snipped from overall patch for
brevity) the UNUSED(foo) macro is used before variables are declared
in the body of the find_outer()
