On Sun, 2 Jun 2013 20:28:20 -0400, "Galen Charlton via RT"
<bug-Text-CSV_XS@rt.cpan.org> wrote:
Show quoted text> The error_input () method segfaults after a (successful) parse ().
> Here is some code that invokes the segfault:
I probably need more information about your perl version and your
system architecture, as I tried that snippet on a plethora of perl
versions on different architectures and did not get a segfault.
Show quoted text> If one tries this with version 0.96 of Text::CSV_XS, the test
> program doesn't segfault; instead, $bad_input is undefined.
The documentation makes no assumption on what the function should
return when no error occurred. The reason is that I don't want to
take action on success, as that will slowdown parsing. The intent
is to only return some documented value on failure. core-dumps
however are not acceptable, but I cannot reproduce.
Show quoted text> The documentation implies but doesn't (to my reading) explicitly
> state that error_input () should be called only if parse () returns
> an error status.
I could make the docs clearer, but I still would not like core-dumps.
For now, following the docs, and my mindset, *any* value would do as
return value after success. C<undef> would be the most logical value
of choice though, but I won't if that costs parsing speed.
Show quoted text> It would be better if error_input () either reverted to its original
> behavior or if it threw an exception when called after a successful
> parse, as that could be caught by an eval block while a segfault
> simply terminates the script.
I feel that would be as overdesigning for failure.
--
H.Merijn Brand
http://tux.nl Perl Monger
http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
