Hello everyone.
I just subscribed to this list. My name's Luke and I'm a perl
devotee. And I'm starting out with a bang. Here goes:
I have just read through exegesis 3, and I found the bit about
defining your own new operators (eg. operator:*#@&) to be a little
strange. Not confusing, but esoter
On Mon, 11 Mar 2002, Simon Glover wrote:
>
> For more fun in the same vein, try this:
>
> length S0
> end
>
> In both cases the problem is that we're not checking the STRING*
> pointer passed to the function before we start trying to dereference it.
> This seems to be a fairly generic pro
On Mon, Mar 11, 2002 at 05:02:45PM -0500, Simon Glover wrote:
>
> On Mon, 11 Mar 2002, Nicholas Clark wrote:
>
> > On Sat, Feb 16, 2002 at 10:32:10PM +, Simon Glover wrote:
> >^
> > Should I apply the revised patch as appended?
> >
>
> Looks like a few bits have already
On Tue, Feb 12, 2002 at 08:37:43PM +, Simon Glover wrote:
>
> Most of the PerlUndef tests in pmc.t appear to have been added twice.
> Enclosed patch removes the duplicates.
>
> Simon
>
> --- t/pmc/pmc.t.old Tue Feb 12 15:23:30 2002
> +++ t/pmc/pmc.t Tue Feb 12 15:25:07 2002
On M
This is a repost of another rather ancient patch, but should be
uncontroversial - basically, the PerlUndef tests appear to have
been committed twice; the patch just removes the duplicates.
Simon
--- t/pmc/pmc.t.old Tue Feb 12 15:23:30 2002
+++ t/pmc/pmc.t Tue Feb 12 15:25:07 2002
@@ -1,
On Mon, 11 Mar 2002, Nicholas Clark wrote:
> On Sat, Feb 16, 2002 at 10:32:10PM +, Simon Glover wrote:
>^
> Should I apply the revised patch as appended?
>
Looks like a few bits have already been patched. Try the attached
instead.
Simon
--- core.ops.oldMon
On Mon, Mar 11, 2002 at 03:24:56PM -0500, Simon Glover wrote:
>
> For more fun in the same vein, try this:
>
> length S0
> end
>
> In both cases the problem is that we're not checking the STRING*
> pointer passed to the function before we start trying to dereference it.
> This seems to
On Sat, Feb 16, 2002 at 10:32:10PM +, Simon Glover wrote:
^
How many more of these unapplied beauties are there?
I've got several in my mailbox that I'm finally finding time to work back to,
but I'm not convinced that I can find them all, or that some haven't been
applied w
For more fun in the same vein, try this:
length S0
end
In both cases the problem is that we're not checking the STRING*
pointer passed to the function before we start trying to dereference it.
This seems to be a fairly generic problem in the string functions,
unfortunately - a brief lo
- Forwarded message from "Clinton A. Pierce via RT"
<[EMAIL PROTECTED]> -
From: "Clinton A. Pierce" via RT <[EMAIL PROTECTED]>
Subject: [netlabs #423] Fwd: Parrot segfaults on substr
To: 'AdminCc of netlabs Ticket #423': ;
X-RT-Loop-Prevention: netlabs
RT-Originator: [EMAIL PROTECTED]
Ma
One of them takes a FILE*, one takes a file descriptor...
--
At Friday's meeting I did get a chance to call a spade an earth-moving
bloody implement of damn-and-blasted wood and bastard metal
construction.
- Red Drag Diva
Hi. We need one of these, very soon. Even I'm getting confused as to
what we're supposed to be doing with the encoding and chartype structures.
Anyone volunteer to take this on?
--
Microsoft - We put the "backwards" into backwards compatibility.
Melvin Smith <[EMAIL PROTECTED]> wrote:
> This is my only nitpick with the coding standards.
>
> I never cared for the style of putting return type on a
> separate line above the function declaration header.
>
> I like it just as the prototype.
>
> I vote for non-enforcement of this one.
perso
Brent Dax:
> What about the C-level compiler? Will this still be included in the
> core?
It'll be in the core, but it won't be linked in with the interpreter that
we're playing around with. I'm expecting we'll come up with a separate
compiler library of Useful Things to be used by people writing
Simon Cozens:
> I didn't object. :) But I do think that patching the current interpreter
> is slightly futile
I mean assembler, but I hope you guessed that. :)
--
"Which you then convert to gold, non-perishable food, firearms, good liquor &
a secluded hideaway in the last of the internet offic
On 10 Mar 02 at 11:14:26PM, Uri Guttman wrote:
> i really think that the printf format spec is so standard and ingrained
> that changing it with # for % or requiring \% is not a good idea.
>
> but then again, backwards compatibility is not a rule you must always
> obey. i just think in this case
On 10 Mar 02 at 11:14:26PM, Uri Guttman wrote:
> i really think that the printf format spec is so standard and ingrained
> that changing it with # for % or requiring \% is not a good idea.
>
> but then again, backwards compatibility is not a rule you must always
> obey. i just think in this case
17 matches
Mail list logo
