Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[perl #42110] [PATCH] Returning values from void functions

0 views
Skip to first unread message

Steve Peters

unread,
Mar 26, 2007, 11:55:48 PM3/26/07
to bugs-bi...@rt.perl.org
# New Ticket Created by Steve Peters
# Please include the string: [perl #42110]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42110 >


A couple of functions in XX are trying to return values from void functions.
To some compilers, such as the standard HP-UX compilers, this is a big
no-no. The patch below fixes this problem.

Steve Peters
st...@fisharerojo.org

Index: src/pmc/parrotobject.pmc
===================================================================
--- src/pmc/parrotobject.pmc (revision 17781)
+++ src/pmc/parrotobject.pmc (working copy)
@@ -207,8 +207,10 @@
PMC *sub = Parrot_find_vtable_meth(interp, SELF, meth_v);
if (PMC_IS_NULL(sub))
sub = find_meth(interp, SELF, meth);
- if (PMC_IS_NULL(sub))
- return Parrot_set_attrib_by_num(INTERP, SELF, idx, value);
+ if (PMC_IS_NULL(sub)) {
+ Parrot_set_attrib_by_num(INTERP, SELF, idx, value);
+ return;
+ }
(PMC*) Parrot_run_meth_fromc_args(interp, sub,
SELF, meth, "vIP", idx, value);
}
@@ -219,8 +221,10 @@
PMC *sub = Parrot_find_vtable_meth(interp, SELF, meth_v);
if (PMC_IS_NULL(sub))
sub = find_meth(interp, SELF, meth);
- if (PMC_IS_NULL(sub))
- return Parrot_set_attrib_by_str(INTERP, SELF, idx, value);
+ if (PMC_IS_NULL(sub)) {
+ Parrot_set_attrib_by_str(INTERP, SELF, idx, value);
+ return;
+ }
(PMC*) Parrot_run_meth_fromc_args(interp, sub,
SELF, meth, "vSP", idx, value);
}

Andrew Dougherty

unread,
Mar 27, 2007, 8:30:53 AM3/27/07
to perl6-i...@perl.org
On Mon, 26 Mar 2007, Steve Peters wrote:

> # New Ticket Created by Steve Peters
> # Please include the string: [perl #42110]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42110 >
>
>
> A couple of functions in XX are trying to return values from void functions.
> To some compilers, such as the standard HP-UX compilers, this is a big
> no-no. The patch below fixes this problem.

Yes. I sent in this same patch last week. I didn't send it to RT since I
thought it was so obvious that someone would apply it right away and I'd
spare that same someone the nuisance of closing the RT ticket. My
mistake. I shouldn't have assumed.

Anyway, it's worth noting that although one of functions actually doesn't
return anything, it is documented as returning a PMC *. So either the
documentation or the function is wrong in parrotobject.pmc and should be
fixed.

--
Andy Dougherty doug...@lafayette.edu
Dept. of Physics
Lafayette College, Easton PA 18042

Steve Peters via RT

unread,
Mar 27, 2007, 8:42:12 AM3/27/07
to perl6-i...@perl.org
On Tue Mar 27 05:32:41 2007, doughera wrote:
> On Mon, 26 Mar 2007, Steve Peters wrote:
>
> > # New Ticket Created by Steve Peters
> > # Please include the string: [perl #42110]
> > # in the subject line of all future correspondence about this issue.
> > # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42110 >
> >
> >
> > A couple of functions in XX are trying to return values from void
> functions.
> > To some compilers, such as the standard HP-UX compilers, this is a
> big
> > no-no. The patch below fixes this problem.
>
> Yes. I sent in this same patch last week. I didn't send it to RT
> since I
> thought it was so obvious that someone would apply it right away and
> I'd
> spare that same someone the nuisance of closing the RT ticket. My
> mistake. I shouldn't have assumed.
>
> Anyway, it's worth noting that although one of functions actually
> doesn't
> return anything, it is documented as returning a PMC *. So either the
> documentation or the function is wrong in parrotobject.pmc and should
> be
> fixed.

Unfortunately, I can't find a gcc warning flag that would seem to catch this sort of situation
either.

Chromatic

unread,
Mar 27, 2007, 2:32:10 PM3/27/07
to perl6-i...@perl.org, Steve Peters, bugs-bi...@rt.perl.org
On Monday 26 March 2007 20:55, Steve Peters wrote:

> A couple of functions in XX are trying to return values from void
> functions. To some compilers, such as the standard HP-UX compilers, this is
> a big no-no. The patch below fixes this problem.

Thanks, applied as r17791.

-- c

Chromatic

unread,
Mar 27, 2007, 2:49:03 PM3/27/07
to perl6-i...@perl.org, Steve Peters, bugs-bi...@rt.perl.org

> Thanks, applied as r17791.

I mean r17793. r17791 was the casting cleanups patch.

-- c

Nicholas Clark

unread,
Mar 28, 2007, 2:41:25 PM3/28/07
to Steve Peters via RT, perl6-i...@perl.org
On Tue, Mar 27, 2007 at 05:42:12AM -0700, Steve Peters via RT wrote:

> > Anyway, it's worth noting that although one of functions actually
> > doesn't
> > return anything, it is documented as returning a PMC *. So either the
> > documentation or the function is wrong in parrotobject.pmc and should
> > be
> > fixed.
>
> Unfortunately, I can't find a gcc warning flag that would seem to catch this sort of situation
> either.

$ gcc -ansi -pedantic -Wall -o void void.c
void.c: In function `uggh':
void.c:9: warning: `return' with a value, in function returning void

where my test program is

#include <stdio.h>

void thwape() {
puts("here!");
}

void uggh() {
puts("no, here!");
return thwape();
}

int
main () {
uggh();
return 0;
}


I don't think that it's possible to make this non-conformity a fatal heresy :-(
(gcc --spanish-inquisition)

Getting parrot to build under -ansi -pedantic is left as an exercise to the
reader. Likely to a reader on *BSD who wants to apply for a microgrant.
(Even Solaris doesn't have headers that are clean with -ansi -pedantic. Which
surprises me. Solaris is usually very clean and well engineered throughout)

Can Intel or Sun's compilers be coaxed into being suitably grumpy about this?
If so, do we have a machine capable of smoking them?
And is it viable (or good) for parrot smoke failures to reach this list, much
like most people configure their Perl 5 smokers to send the black smoke to
p5p?

Nicholas Clark

Leopold Toetsch

unread,
Mar 29, 2007, 3:51:07 PM3/29/07
to perl6-i...@perl.org, Nicholas Clark, Steve Peters via RT
Am Mittwoch, 28. März 2007 20:41 schrieb Nicholas Clark:
> Getting parrot to build under -ansi -pedantic is left as an exercise to the
> reader.

By filtering other useless and/or nonsensical warnings - yes - else no.

leo - been there, done that

Steve Peters

unread,
Mar 29, 2007, 6:38:27 PM3/29/07
to Steve Peters via RT, perl6-i...@perl.org
On Wed, Mar 28, 2007 at 07:41:25PM +0100, Nicholas Clark wrote:
> On Tue, Mar 27, 2007 at 05:42:12AM -0700, Steve Peters via RT wrote:
>
> > > Anyway, it's worth noting that although one of functions actually
> > > doesn't
> > > return anything, it is documented as returning a PMC *. So either the
> > > documentation or the function is wrong in parrotobject.pmc and should
> > > be
> > > fixed.
> >
> > Unfortunately, I can't find a gcc warning flag that would seem to catch this sort of situation
> > either.
>
> I don't think that it's possible to make this non-conformity a fatal heresy :-(
> (gcc --spanish-inquisition)

As long as this doesn't involve the "comfy chair"-type inquisition gcc seems
to like, we'd be alright.

As an aside, I've been using "-Wc++-compat", my discovery from last week
that I added to bleadperl, to help me find these issues so far. Right
now, Parrot is not ready to compile with this full time, but I'm hoping
it will be by the end of the weekend.

> Getting parrot to build under -ansi -pedantic is left as an exercise to the
> reader. Likely to a reader on *BSD who wants to apply for a microgrant.
> (Even Solaris doesn't have headers that are clean with -ansi -pedantic. Which
> surprises me. Solaris is usually very clean and well engineered throughout)
>
> Can Intel or Sun's compilers be coaxed into being suitably grumpy about this?
> If so, do we have a machine capable of smoking them?
> And is it viable (or good) for parrot smoke failures to reach this list, much
> like most people configure their Perl 5 smokers to send the black smoke to
> p5p?
>

Intel's errors do not seem sensitive enough to pick it up, although
HP-UX did. I haven't looked at Solaris yet, but I'm certain it would
pick up this failure as well.

Steve Peters
st...@fisharerojo.org

Steve Peters

unread,
Mar 29, 2007, 6:44:05 PM3/29/07
to Leopold Toetsch via RT

Sweeping dirt under the rug doesn't mean that the house has been cleaned
up. It means I've turned it into someone else's problem. I'd rather
Parrot was solid and reliable than something VM users cannot rely on.

Steve Peters
st...@fisharerojo.org

Leopold Toetsch

unread,
Mar 29, 2007, 7:05:05 PM3/29/07
to perl6-i...@perl.org
Am Freitag, 30. März 2007 00:44 schrieb Steve Peters:
> Sweeping dirt under the rug doesn't mean that the house has been cleaned
> up.

It's not related to hiding other possible errors. Some warnings are just not
appropriate to the usage of the very code, and there are a lot of them.

leo

Chromatic

unread,
Mar 29, 2007, 7:08:58 PM3/29/07
to perl6-i...@perl.org, Steve Peters

I turned on -ansi -pedantic for a compile last night and had my fill of errors
about 'long long' not being in C90 and commas at the end of enumerated lists.
Is there a way to get more meaningful error messages? (I thought we used
C99, for example).

-- c

Nicholas Clark

unread,
Mar 29, 2007, 7:18:12 PM3/29/07
to chromatic, perl6-i...@perl.org, Steve Peters

IIRC we're on C89 because it is still the only common standard.
In particular, IIRC someone sent a message to this list quoting Microsoft
policy that their C compiler was unlikely to gain any more C99
functionality because most people were interested in using C++

IIRC Perl 5 can build with few warnings under -ansi -pedantic because the
default configuration doesn't use any of the C (that is C99) type long long.

My hunch is that commas at the end of enumerated lists is likely to be
something that will hinder portability, whereas the world is resigned to
long long.

[I say resigned, because "long long" breaches one of the axioms of C89, that
"long" is the longest integer type]

Nicholas Clark

0 new messages