On Wed, Dec 3, 2008 at 7:25 PM, Will Coleda via RT <
[EMAIL PROTECTED]> wrote:
> On Tue Jan 09 06:43:10 2007, particle wrote:
> > compilers\imcc\imclexer.c(4310) : warning C4018: '<' : signed/unsigned
> > mismatch
> > compilers\imcc\imcc.l(662) : warning C4090: 'function' : different
> > 'const' q
# New Ticket Created by Stephane Payrard
# Please include the string: [perl #60288]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60288 >
warnings compiling in 10.5.5 Core 2 Duo unibody macbook.
Seems that some stuff
The warning of inconsistent dll linkage no longer occurs on microsoft
visual studio, which resolves this issue.
kjs
On Dom. 19 Oct. 2008 13:47:11, kjs wrote:
> I think the issue of inconsistent dll linkage has been resolved
recently
> by adding the YYMALLOC and YYFREE #defines to imcc source.
>
> Can other windows people confirm this? Then this ticket can be closed.
> Thank you very much,
Confirmed. Parrot r
I think the issue of inconsistent dll linkage has been resolved recently
by adding the YYMALLOC and YYFREE #defines to imcc source.
Can other windows people confirm this? Then this ticket can be closed.
Thank you very much,
kjs
hey don't tell us anything about what warnings are
being emitted one phase earlier during 'make'. Such warnings are
presumably not causing Parrot to fail to build, but they may be
useful in diagnosing test failures. And, in any event, from a
scientific point of view they w
On Thursday 10 July 2008 10:44:51 NotFound wrote:
> On Wed, Jul 9, 2008 at 9:33 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote:
> > The other warnings I get on Solaris are just these:
> >
> > "src/stm/backend.c", line 969: warning: statement not reached
>
On Thursday 10 July 2008 13:12:41 NotFound wrote:
> On Thu, Jul 10, 2008 at 7:44 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote:
> >> Except the src/pmc/nci.pmc line 486, there is not such line in the
> >> file, and I'm unable to locate the problem.
> >
> > If you look in the generated src/pmc/nci.c
On Thu, Jul 10, 2008 at 7:44 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote:
>> Except the src/pmc/nci.pmc line 486, there is not such line in the
>> file, and I'm unable to locate the problem.
>
> If you look in the generated src/pmc/nci.c file at line 486, it has a #line
> directive that purports
On Wed, Jul 9, 2008 at 9:33 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote:
> The other warnings I get on Solaris are just these:
>
> "src/stm/backend.c", line 969: warning: statement not reached
> "./src/pmc/nci.pmc", line 486: warning: statement not reach
On Wednesday 09 July 2008 12:03:19 chromatic wrote:
> On Wednesday 09 July 2008 08:27:35 Andrew Johnson wrote:
> > Confirmed, those warnings have gone. I'm still getting loads of
> > "warning: statement not reached" but I'll work out how to suppress those
>
Closing ticket
On Wednesday 09 July 2008 08:27:35 Andrew Johnson wrote:
> > Done in r29179, please confirm that gives no warning now.
>
> Confirmed, those warnings have gone. I'm still getting loads of "warning:
> statement not reached" but I'll work out how to suppress those
th adding a comment into parrot.h to clarify that
> > PARROT_const_cast should *only* be used for c/v qualifier changes, and
> > that additional casting may be necessary.
>
> Done in r29179, please confirm that gives no warning now.
Confirmed, those warnings have gone. I'm s
On Mon, Jun 23, 2008 at 4:37 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote:
>> Here is the patch. It avoids the warning both in C and C++ with gcc.
> Works fine for me, no warning.
> It might be worth adding a comment into parrot.h to clarify that
> PARROT_const_cast should *only* be used for c/v q
# New Ticket Created by Will Coleda
# Please include the string: [perl #56532]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56532 >
We get a lot of tickets regarding build warnings; we'd like to
eventually have
On Mon Apr 09 01:17:50 2007, pcoch wrote:
> In the file src/ops/io.ops there is the todo item:
>
> "all results from string_to_cstring() need freeing
> but this generates ugly warnings WRT discarding the const
> qualifier"
>
> free the results but also
On Monday 23 June 2008 09:08:07 NotFound wrote:
> Here is the patch. It avoids the warning both in C and C++ with gcc.
Works fine for me, no warning.
It might be worth adding a comment into parrot.h to clarify that
PARROT_const_cast should *only* be used for c/v qualifier changes, and that
addi
know how to write it without a long explanation of
the rationale that avoids people takes it as an invitation to add more
casts, 'just in case'. I like better to have these warnings and
carefully review each case than to hide them.
Maybe a comment that says 'Check each usage of thi
Here is the patch. It avoids the warning both in C and C++ with gcc.
--
Salu2
Index: src/packfile.c
===
--- src/packfile.c (revisión: 28668)
+++ src/packfile.c (copia de trabajo)
@@ -348,7 +348,7 @@
#ifdef PARROT_HAS_HEADER_SYSMMAN
On Sat, Jun 21, 2008 at 11:10 AM, chromatic <[EMAIL PROTECTED]> wrote:
> On Friday 20 June 2008 10:53:55 Andrew Johnson wrote:
>
>> I'm concluding that these warnings are due to incorrect casting inside of
>> packfile.c.
>>
>> In both cases, the cod
On Friday 20 June 2008 10:53:55 Andrew Johnson wrote:
> I'm concluding that these warnings are due to incorrect casting inside of
> packfile.c.
>
> In both cases, the code generating the warnings looks like this:
>
> munmap(PARROT_const_cast(opcode_t *, pf->src),
"src/packfile.c", line 878: warning: argument #1 is incompatible with
> prototype:
> prototype: pointer to char : "/usr/include/sys/mman.h", line 161
> argument : pointer to long
I'm concluding that these warnings are due to incorrect casting inside of
pa
On Thursday 19 June 2008 13:33:13 Andrew Johnson wrote:
> These warnings occur when compiling on Solaris, both x86 and sparc:
>
> "src/packfile.c", line 351: warning: argument #1 is incompatible with
> prototype:
> prototype: pointer to char : "/usr
# New Ticket Created by Andrew Johnson
# Please include the string: [perl #56110]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56110 >
These warnings occur when compiling on Solaris, both x86 and sparc:
"src/pa
On Tuesday 10 June 2008 12:05:18 NotFound wrote:
> This patch solves the casting problems that breaks or generates
> warnings in src/io/io_unix.c allowing clean compiling with C or C++,
> with or without --optimize.
Applied in r28251.
> Also drops the const in argv in several m
# New Ticket Created by NotFound
# Please include the string: [perl #55590]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55590 >
This patch solves the casting problems that breaks or generates
warnings in src
On Monday 09 June 2008 22:26:10 Geoffrey Broadwell wrote:
> > This is on a Gentoo linux amd64 machine, with Parrot trunk r28204, and an
> > unstable (git) version of mesa built from the "x11" overlay.
> >
> > Is this normal?
>
> Nope, not normal.
>
> Try the attached patch. It's an update of the p
> This is on a Gentoo linux amd64 machine, with Parrot trunk r28204, and an
> unstable (git) version of mesa built from the "x11" overlay.
>
> Is this normal?
Nope, not normal.
Try the attached patch. It's an update of the patch in #55228; I'll
update that RT in a moment.
-'f
diff --git a/co
On Mon, Jun 9, 2008 at 8:36 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> On Mon Jun 09 17:23:40 2008, coke wrote:
>
>>
>> I think the goal is to eliminate warnings from the default build,
>> while turing on as many warnings as possible. (like with the coding
&
On Mon Jun 09 17:23:40 2008, coke wrote:
>
> I think the goal is to eliminate warnings from the default build,
> while turing on as many warnings as possible. (like with the coding
> standard tests; as more pass, we should run them by default.)
>
So does this mean I should no
On Mon Jun 09 17:13:32 2008, infinoid wrote:
>
> Update: these warnings are gone, looks like D2FPTR has been removed from
> the above lines (which are now lines 361 and 370 of dynext.c).
>
> Mark
Thanks, Mark. Running 'make' just now, I got no warnings with
src/dy
On Mon, Jun 9, 2008 at 8:16 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> Since we're always going to have some build warnings on different
> OS/platform combinations, I think we can resolve this ticket.
I think the goal is to eliminate warnings from the default build,
w
I'm not on Gentoo, but on Debian. Running 'perl Configure.pl' at
r28211, I don't get any of these warnings.
$ uname -a
Linux li11-226 2.6.23.1-linode36 #1 Sun Nov 4 12:03:06 EST 2007 i686
GNU/Linux
Since we're always going to have some build warnings on different
OS/platform combinations, I think we can resolve this ticket.
If, on a particular OS, we have a pattern of warnings emerging --
particularly if those are warnings not previously observed -- then we
can open new tickets
; 315:load_func = (PMC * (*)(Interp *))D2FPTR(Parrot_dlsym(handle,
> cload_func_name));
>
>
> 322:init_func = (void (*)(Interp *, PMC
> *))D2FPTR(Parrot_dlsym(handle,
> cinit_func_name));
Update: these warnings are gone, looks like
Jerry, Mark, anyone: Can someone provide an update on the status of
issues raised in this ticket?
Thank you very much.
kid51
# New Ticket Created by Mark Glines
# Please include the string: [perl #55530]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55530 >
Hi,
Generating OpenGL bindings...In OpenGL header '/usr/include/GL/amesa.h', found
a no
On Friday 30 May 2008 15:12:31 NotFound wrote:
> On Fri, May 30, 2008 at 5:56 PM, Geoffrey Broadwell <[EMAIL PROTECTED]>
wrote:
> > Nit: three of those lines look like they've either got a real tab at the
> > front, or some other spacing oddity that makes them not line up
> > properly.
>
> Sorry,
tetragon:
Patch applied to trunk in r27953, along with tests to cover that
condition. Let me know if this doesn't do the trick. Thanks.
kid51
On Fri, May 30, 2008 at 5:56 PM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote:
> Nit: three of those lines look like they've either got a real tab at the
> front, or some other spacing oddity that makes them not line up
> properly.
Sorry, forgot to cross-copy to the list the fixed version.
http:
On Thu, 2008-05-29 at 09:41 -0700, NotFound wrote:
> +# Dirty way of checking if compiling with c++
> + my $nocpp = index($conf->data->get('cc'), '++') < 0;
> +
> -$self->set_result("set for gcc");
> + if ($nocpp) {
> +for my $maybe_warning
> (@{ $self->{pote
# New Ticket Created by "Seneca Cunningham"
# Please include the string: [perl #55074]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55074 >
_handle_darwin_for_macports doesn't check to see if the value of
$ports_include_d
# New Ticket Created by NotFound
# Please include the string: [perl #55050]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55050 >
Recent versions of g++ warns when gcc warnings that makes no sense in
c++ are used,
];
return \%data;
}
@@ -145,6 +148,9 @@
print "\n" if $verbose;
if ( defined $conf->data->get('gccversion') ) {
+# Dirty way of checking if compiling with c++
+my $nocpp = index($conf->data->get('cc'), '++') <
I have seen now that the functions if'ed out by DO_LOOP_OPTIMIZATION
are mentioned and proposed for deletion in #46291, this ticket can be
merged with him or closed.
--
Salu2
On May 12, 2008, at 3:11 AM, NotFound wrote:
Maybe the solution is to avoid the problem, that is, put the
declarations outside of the HEADERIZER block. What's the point of
having static functions inside one?
So that declaration and definition are always in sync.
--
Andy Lester => [EMAIL PRO
On Mon, May 12, 2008 at 4:34 AM, Andy Lester via RT
<[EMAIL PROTECTED]> wrote:
> This won't work because it modifies the sections in between HEADERIZER
> BEGIN & END sections. As of this writing, there is no solution for this
> problem.
Maybe the solution is to avoid the problem, that is, put t
# New Ticket Created by NotFound
# Please include the string: [perl #53990]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53990 >
Hello.
In recent revisions there are warning about unused static functions in
compilers/imc
On Friday 25 April 2008 10:36:02 Will Coleda wrote:
> a default build on feather is generating the following warnings:
>
> src/jit_emit.h:1725: warning: cast discards qualifiers from pointer target
> type src/jit_emit.h:1764: warning: cast discards qualifiers from pointer
>
On Monday 28 April 2008 14:00:28 NotFound wrote:
> The attached patch redoes the changes in these files with the new name.
Thanks! Applied in r27223.
-- c
chromatic wrote
> What if the PMC passed in isn't a Key PMC, but has an integer value?
Ah (sound of scales falling from my eyes) - the reason for the
test/switch:
if (VTABLE_isa(interp, key, CONST_STRING(interp, "Key"))) {
switch (PObj_get_FLAGS(key) & KEY_type_FLAGS) {
...
is to handl
The attached patch redoes the changes in these files with the new name.
--
Salu2
Index: src/encodings/utf16.c
===
--- src/encodings/utf16.c (revisión: 27222)
+++ src/encodings/utf16.c (copia de trabajo)
@@ -708,7 +708,7 @@
On Mon, Apr 28, 2008 at 10:05 PM, chromatic <[EMAIL PROTECTED]> wrote:
> I renamed it to STRUCT_COPY_FROM_STRUCT (but that's only a little better than
> your version) and applied it as r27222.
Thanks, but in 27222 looks like only include/parrot/parrot.h reflects
the changes, not the files in sr
On 26 April 2008 chromatic wrote:
> src/key.c:306: warning: switch missing default case
Fixed in 27195.
Just a query, wouldn't:
Index: src/key.c
===
--- src/key.c (revision 27216)
+++ src/key.c (working copy)
@@ -329,12 +329,14
On Monday 28 April 2008 11:15:56 NotFound wrote:
> The attached patch adds the macro STRUCT_COPY_ST, and uses it in the
> src/charset charset init functions.
>
> All test pass with 27216 in my system (Ubuntu 8.04)
I renamed it to STRUCT_COPY_FROM_STRUCT (but that's only a little better than
your
On Mon, Apr 28, 2008 at 8:15 PM, NotFound <[EMAIL PROTECTED]> wrote:
> All test pass with 27216 in my system (Ubuntu 8.04)
Sorry, I mean 27219, 27216 was from the modified files.
--
Salu2
On Sat, Apr 26, 2008 at 8:16 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > A possible solution is to add another macro taking as second argument
> > the struct instead of a pointer.
> That seems cleaner to me; want to try that patch?
The attached patch adds the macro STRUCT_COPY_ST, and uses it
On Monday 28 April 2008 10:40:02 [EMAIL PROTECTED] wrote:
> Just a query, wouldn't:
> Index: src/key.c
> ===
> --- src/key.c (revision 27216)
> +++ src/key.c (working copy)
> @@ -329,12 +329,14 @@
> }
> case
On Sat, Apr 26, 2008 at 8:16 PM, chromatic <[EMAIL PROTECTED]> wrote:
> That seems cleaner to me; want to try that patch?
I'm out for the weekend, tomorrow I will work on it.
--
Salu2
On Fri Jul 07 09:05:57 2006, particle wrote:
> compilers\imcc\imcparser.c
> imcparser.c
> compilers\imcc\imcparser.c(878) : warning C4273: 'malloc' :
> inconsistent dll linkage
> compilers\imcc\imcparser.c(885) : warning C4273: 'free' : inconsistent
> dll linkage
>
> compilers\ast\astparser.c
> as
On Sat, Apr 26, 2008 at 7:39 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Friday 25 April 2008 10:50:24 Will Coleda wrote:
>
> > Miscellaneous build warnings that need to be cleaned up.
> >
> > src/key.c:306: warning: switch missing default case
>
> Fix
On Friday 25 April 2008 10:50:24 Will Coleda wrote:
> Miscellaneous build warnings that need to be cleaned up.
>
> src/key.c:306: warning: switch missing default case
Fixed in 27195.
> compilers/imcc/imclexer.c:4288: warning: switch missing default case
> compilers/imcc/imclexer.
On Saturday 26 April 2008 09:03:12 NotFound wrote:
> I'v taken a look a those warnings some days ago. The macro STRUCT_COPY
> is generic and asserts his two parameter as non null, but is used in
> several places with arguments that the compiler knows is not, making
> the asserti
Hello
> The following lines that use the STRUCT_COPY macro are generating
> build warnings.
>
> src/charset/ascii.c:792: warning: the address of 'base_set' will
> always evaluate as 'true'
(snip)
> For example, the last line here is:
>
>
# New Ticket Created by Will Coleda
# Please include the string: [perl #53356]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53356 >
Miscellaneous build warnings that need to be cleaned up.
src/key.c:306: warning: swi
# New Ticket Created by Will Coleda
# Please include the string: [perl #53352]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53352 >
The following lines that use the STRUCT_COPY macro are generating
build warnings.
# New Ticket Created by Will Coleda
# Please include the string: [perl #53350]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53350 >
a default build on feather is generating the following warnings:
src/jit_emit.h:1
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #51990]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51990 >
Fixed two compiler warnings in src/io/io_win32.c, and updated a
> # http://rt.perl.org/rt3/Ticket/Display.html?id=51984 >
>
>
> The file src/utils.c was producing a number of compile-time warnings
> involving possible loss of data in conversions from const int to
> unsigned char. This stemmed from the macro "move_reg", which passed
&
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #51984]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51984 >
The file src/utils.c was producing a number of compile-time warni
James Keenan via RT wrote:
This thread petered out after January 30, which was fine with me because
we couldn't diagnose why Allison's proposed patch was causing
Configure.pl to throw warnings on Darwin (OS X 10.4.11, ppc, gcc-3.3) at
config/auto/readline.pm. Configure.pl quietly did
On Sunday 16 March 2008 09:19:47 Matt Kraai wrote:
> The attached patch fixes the following warnings:
>
> make[1]: Entering directory `/home/kraai/src/parrot/languages'
> Makefile:352: warning: overriding commands for target `dotnet.realclean'
> Makefile:242: warning:
# New Ticket Created by Matt Kraai
# Please include the string: [perl #51798]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51798 >
Howdy,
The attached patch fixes the following warnings:
make[1]: Entering direct
This thread petered out after January 30, which was fine with me because
we couldn't diagnose why Allison's proposed patch was causing
Configure.pl to throw warnings on Darwin (OS X 10.4.11, ppc, gcc-3.3) at
config/auto/readline.pm. Configure.pl quietly did its thing for me for
the ne
Thanks, applied as r25875.
-- c
# New Ticket Created by Steve Peters
# Please include the string: [perl #51004]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51004 >
Index: src/exec.c
===
--
On Thursday 14 February 2008 21:25:35 Andrew Whitworth wrote:
> ..forgot the patch, again. I'll get better at this, i swear.
Thanks, applied with tweaks as r25863.
I removed the commented-out lines, for two reasons. First, we stick with C89
which doesn't allow C++-style comments. Second, ther
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #50884]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50884 >
I fixed a few compile-time warnings in src/spf_vtable.c,
src/threa
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #50886]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50886 >
..forgot the patch, again. I'll get better at this, i swear.
--Andrew Whitworth
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #50882]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50882 >
Fixed two compile-time warnings in spf_render.c.
1) redefinitio
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #48286]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48286 >
In compilers/imcc/cfg.c:propagate_need() there is the todo item (with some
context):
On Thursday 01 November 2007 11:23:32 Klaas-Jan Stol wrote:
> attached a patch that removes 2 warnings about locals being
> intialized, but not referenced.
>
> Not sure if this makes sense, because the locals also could be removed I
> think.
Let's remove the locals, if they&#
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #47089]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47089 >
hi,
attached a patch that removes 2 warnings about locals being
intialized, but
XXX This is the behavior of Parrot 0.4.3
# It looks like core PMCs never emit warning.
# Look in perlundef.t for a more sane test of 'warningson' in subs
Looking at the following test it seems as if the core PMCs aren't supposed
to emit warnings. Is this the correct behaviour?
On Sun, Oct 21, 2007 at 07:57:24PM -0700, Will Coleda via RT wrote:
> On Wed Aug 22 09:19:49 2007, pmichaud wrote:
> > For the 0.4.15 release a note was added to README regarding the
> > large number of compiler warnings in the release:
> >
> > + As of the 0.4.15
On Wed Aug 22 09:19:49 2007, pmichaud wrote:
> For the 0.4.15 release a note was added to README regarding the
> large number of compiler warnings in the release:
>
> + As of the 0.4.15 release you may see a large number of compiler
> + warnings throughout the make process -- this
arser.c
> astparser.c
>
>
> Is that sufficient to close this issue, or should I provide a patch to
> disable the C4102 warning?
Is this ticket still relevant? Are we still seeing these warnings with
msvc?
Paul
worth it atm (unless you want to join the cage
cleaners! ;-) ) as I've added a whole lot of new code to autodetect
the warnings flags that the compiler can handle, so such errors that
you detected should hopefully not happen in future. Well spotted
though :-)
Best regards,
Paul
Just a following followup - I looked ath changes in rev 21619 and noticed
that the troublesome warning flags are still in the "cage" settings for
the default. Should they be moved to a v3.4 section also for the cage
cleaners?
a
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
VOICE: (608
Paul wrote:
> This should be corrected as of revision 21619. Could you confirm that
this works for you?
Yep, make smoke worked last night. Thanks.
> Have you been using the parrotbug script? If so, it is known that it
doesn't work properly.
Yeah, I tried that twice and then went to the email.
Andy,
Thanks for the bug report! This is good info to know :-)
> A nightly cvs update and make smoke and I've been seeing failures for
> about a week. I tried parrotbug but got no response. Here's the failing
> call
Have you been using the parrotbug script? If so, it is known that it
doesn't
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #45783]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45783 >
A nightly cvs update and make smoke and I've been seeing failures for
about a week
, I cleaned a file of the headerizer warnings as noted in RT 45593, because this is my first patch i only changed one file (to keep it simple).
Hi,
welcome to the vibrant world of Parrot.
I have a question regarding your patch. Are you sure about
@@ -87,7 +89,7 @@
PARROT_API
void
-imc_clea
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #45703]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45703 >
As a start of contributing to parrot, I cleaned a file of the headerizer
warni
on r21432. these warnings must
all be cleaned up. it's a good job for somebody with a tiny bit of C
experience (someone who can parse the source and understand, for
example, if a function argument can ever be null, or if a function can
return null, etc.)
~jerry
$ make headerizer
/usr/bin/pe
of compiler warnings in the release:
+ As of the 0.4.15 release you may see a large number of compiler
+ warnings throughout the make process -- this is normal. The configure
+ system now enables a lot of additional compiler warning options, and
+ we're still in the process of reviewing/cle
this problem. The test could either be made to only work
> > for gcc > 3.3, or it could try parsing the gcc-3.3 warning output (being
> > careful to handle localization issues appropriately, and avoiding false
> > positives for unrelated warnings)
>
> The attribute sn
it could try parsing the gcc-3.3 warning output
(being
careful to handle localization issues appropriately, and avoiding
false
positives for unrelated warnings)
The attribute sniffer looks at the compiler's output and says if it
sees "warning" or "error", that t
been nice if gcc simply rejected the attribute
so that testing the exit status of gcc would be sufficient. gcc-3.4
doesn't have this problem. The test could either be made to only work
for gcc > 3.3, or it could try parsing the gcc-3.3 warning output (being
careful to handle localization issues appropriately, and avoiding false
positives for unrelated warnings).
--
Andy Dougherty [EMAIL PROTECTED]
1 - 100 of 426 matches
Mail list logo
