Front page | perl.perl5.porters |
Postings from June 2013
On Tue Jun 25 18:56:25 2013, tonyc wrote:
> On Mon Jun 24 23:02:26 2013, pcm wrote:
> > Similar to RT 118623, Perl_cv_ckproto_len_flags is sensitive to spaces
> > when doing its checks for warnings.
> >
> > For example,
> >
> > perl -MScalar::Util=set_prototype -e 'BEGIN { set_prototype \&foo, "
> > \$ "; } sub foo($){}'
> > Prototype mismatch: sub main::foo ( $ ) vs ($) at -e line 1.
> >
> > Which doesn't match the behavior if toke.c throws away the spaces:
> >
> > perl -e 'sub foo( $ ); sub foo($){}' # No issues
> >
> > Patch attached. The current ckproto is some code to produce the
> > warning inside of a 13 line if statement; instead of trying to nest
> > the cleanup in there, I broke those 13 lines into separate if () {
> > return; } blocks. If that's too much churn inside the function, I'll
> > redo it with fewer lines of code changed.
>
> The UTF8f changes have been reverted, which means this patch no longer
> applies.
>
> One issue with your patches - could you please keep the Subject of the
> patch itself short, for example, this patch has a subject of:
>
> Perl_cv_ckproto_len_flags should disregard spaces This included breaking
> down the original large if block into smaller, more manageable chunks.
>
> (all one line)
>
> Ideally a git commit should have a short subject describing the change,
> with any other notes after a blank line.
>
Hm, I must be doing something wrong with git. The subject was meant to be just the first bit,
"Perl_cv_ckproto_len_flags should disregard spaces". Is that too long? I'm generating the
patches by "git format-patch blead".
Sorry for the trouble, and I'll rebase.
---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=118629
Thread Previous
|
Thread Next