On Wednesday 08 August 2007 14:16:17 [EMAIL PROTECTED] wrote:
> +Do not specify a return type for Cs -- the true
> signature of the return is specified inside the method using C,
> described below.
+1. Great change. Would buy again from this seller.
-- c
On 8/8/07, Andy Lester <[EMAIL PROTECTED]> wrote:
>
> On Aug 8, 2007, at 10:58 AM, [EMAIL PROTECTED] wrote:
>
> > -INTVAL get_integer_keyed(PMC* key) {
> > +INTVAL get_integer_keyed(PMC *key) {
>
> As you go through these, please check to see if you can NOTNULL or
> NULLOK the parms that yo
On Aug 8, 2007, at 10:58 AM, [EMAIL PROTECTED] wrote:
-static PMC* undef(Interp* interp)
+static PMC *undef(Interp *interp)
And this should get changed to
static PMC *undef(PARROT_INTERP)
xoxo,
Andy
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
On Aug 8, 2007, at 10:58 AM, [EMAIL PROTECTED] wrote:
-INTVAL get_integer_keyed(PMC* key) {
+INTVAL get_integer_keyed(PMC *key) {
As you go through these, please check to see if you can NOTNULL or
NULLOK the parms that you're changing. For example this one:
-PMC* get_pmc_keye
On Wednesday 08 August 2007 02:54:37 Joshua Hoblitt wrote:
> I hate to sound like the nag here but why don't we just not write code
> in form 'real_exception(string_from_cstring(foo))'. Part of living with
> dynamic memory allocating is dealing with the line bloat of shoving that
> free() call in
Author: coke
Date: Wed Aug 8 10:18:45 2007
New Revision: 20564
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Changes in other areas also in this revision:
Modified:
trunk/docs/imcc/imcfaq.pod
Log:
[docs]
- avoid invalid '.local' syntax
- avoid deprecated 'new' syntax
Modified: trunk
> What about a real_exception variant that accepts STRING*'s as arguments?
>
> On the other hand, as you said, there will be other functions which
> don't return control (functions that call real_exception etc.). But
> then char* is not the only problem, any malloced data can leak.
>
> void f() {
>
On 8/8/07, via RT chromatic <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by chromatic
> # Please include the string: [perl #44499]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=44499 >
>
>
> The string_from_cstring()
On Tue Aug 07 20:00:03 2007, millerlf at telus.net wrote:
> when I ran "make test" I get 1 failure. Looks like this ...
>
> not ok 16 - examples/shootout/regexdna.pir
> # Failed test (t/examples/shootout.t at line 103)
> [...]
> # Segmentation fault (core dumped)
> [...]
> I am running kubutu
On 8/8/07, Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 08, 2007 at 12:17:17AM -0700, chromatic wrote:
> > The string_from_cstring() function has a slight flaw, in that it has to
> > allocate a piece of memory and create a C-style string from a nice happy
> > STRING. It's the responsibi
# New Ticket Created by Lloyd Miller
# Please include the string: [perl #44495]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44495 >
when I ran "make test" I get 1 failure. Looks like this ...
not ok 16 - examples/shooto
On Wed, Aug 08, 2007 at 12:17:17AM -0700, chromatic wrote:
> The string_from_cstring() function has a slight flaw, in that it has to
> allocate a piece of memory and create a C-style string from a nice happy
> STRING. It's the responsibility of the caller to discard the C string
> appropriately
# New Ticket Created by chromatic
# Please include the string: [perl #44499]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44499 >
The string_from_cstring() function has a slight flaw, in that it has to
allocate a piece o
13 matches
Mail list logo
