Pike-devel

pike-devel@lists.lysator.liu.se

1 participants
3045 discussions

Start a nNew thread

Void expressions in arguments
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 31 May '08

31 May '08

Why?

1 0

Blocks inside expressions
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 31 May '08

31 May '08

Try it yourself. It introduces two new shift/reduce conflicts only, which are benign: One is for a TOK_LEX_EOF error production, and the other is for comma_expr (as part of statements). The second gets cleared up when end_block is shifted.

1 0

Blocks inside expressions
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 31 May '08

31 May '08

Because a block is always a void expression: statement_with_semicolon: unused2 expected_semicolon ; /.../ unused2: comma_expr { $$=mkcastnode(void_type_string, $1); } ;

1 0

precompile.sh
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 30 May '08

30 May '08

Currently precompile.sh will continue testing different methods, even if it succeeds in running a pike script, if that pike script then fails for some reason. This hides some errors during the build process. Is there any way of getting around this?

1 0

Parsing RXML entities result (was: Re: [Bug] Parser.HTML crash)
by bertrand.lupart＠linkeo.com 25 May '08

25 May '08

> It *is* a bit odd, but it used to be the default behaviour, so it was > made like that for compatibility reasons, iirc. These things are > old... :) One can expect that an RXML entity can output another RXML entity, which would then be parsed. I'm not fond of RXML as a programming language, but out of curiosity, what is the expected behaviour? -- Bertrand LUPART http://bertrand.gotpike.org/

2 1

Re: [Bug] Parser.HTML crash
by bertrand.lupart＠linkeo.com 24 May '08

24 May '08

Martin Stjernholm, Roxen IS @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > I think you need to isolate how the Parser.HTML object is being set up > to be able to debug that (callbacks, flags, etc). I assume it's not > the Roxen RXML parser we're talking about here. We are indeed talking about Pike's Parser.HTML. Here's a standalone Pike program that triggers the problem: ----8<----8<----8<----8<---- #!/usr/bin/env pike int main(int argc, array(string) argv) { object my_parser = Parser.HTML(); my_parser->_set_entity_callback(entity_callback); string to_parse = "<a href=\"mailto:&foobar;\"></a>"; string foo = my_parser->finish(to_parse)->read(); werror("%O\n", foo); return 0; } int|string entity_callback(object parser, string entity, object id, mixed ... extra) { if(entity=="&foobar;") { // return string ending with XML entity will crash: // " " will crash // "  " won't crash return " "; } return 0; } ---->8---->8---->8---->8---- Here's what i get: ----8<----8<----8<----8<---- $ gdb /sw/bin/pike7.6 GNU gdb 6.3.50-20050815 (Apple version gdb-563) (Wed Jul 19 05:17:43 GMT 2006) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries ..... done (gdb) run parser.pike Starting program: /sw/bin/pike7.6 parser.pike Reading symbols for shared libraries ................... done Reading symbols for shared libraries .. done Reading symbols for shared libraries . done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000008 0x007a7fcc in scan_forward (feed=0x111ad68, c=0, destp=0xbfffec78, d_p=0xbfffec7c, look_for=0x7b621c, num_look_for=2) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/modules/Parser/h tml.c:1672 1672 /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/modules/Parser/h tml.c: No such file or directory. in /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/modules/Parser/h tml.c (gdb) bt #0 0x007a7fcc in scan_forward (feed=0x111ad68, c=0, destp=0xbfffec78, d_p=0xbfffec7c, look_for=0x7b621c, num_look_for=2) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/modules/Parser/h tml.c:1672 #1 0x007ad9dc in scan_forward_arg (this=0x111ca50, feed=0x2, c=0, destp=0xbfffec78, d_p=0xbfffec7c, what=SCAN_ARG_ENT_BREAK, finished=1, quote=0xbfffec90) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/modules/Parser/h tml.c:2051 #2 0x007b3448 in try_feed (finished=17935720) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/modules/Parser/h tml.c:3537 #3 0x007b4278 in html_finish (args=-1073746824) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/modules/Parser/h tml.c:3936 #4 0x000168e4 in low_mega_apply (type=3221220472, args=-1073746824, arg1=0x0, arg2=0xbfffec78) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/apply_low.h:214 #5 0x0001888c in jump_opcode_F_CALL_OTHER (arg1=-1073746820) at /home/peter/hack/Pike/7.6-distmaker/src/interpret_functions.h:1957 #6 0x00750390 in ?? () #7 0x00019738 in o_catch (pc=0x5ea360) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/interpret.c:2051 #8 0x00019814 in jump_opcode_F_CATCH () at /home/peter/hack/Pike/7.6-distmaker/src/interpret_functions.h:1239 #9 0x005ea354 in ?? () #10 0x0001708c in mega_apply (type=17935720, args=0, arg1=0xbfffec78, arg2=0x7b621c) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/interpret.c:2006 #11 0x0009384c in main (argc=2, argv=0xbffff808) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/main.c:841 ---->8---->8---->8---->8---- -- Bertrand LUPART http://bertrand.gotpike.org/

3 3

Re: [Bug] Parser.HTML crash
by bertrand.lupart＠linkeo.com 24 May '08

24 May '08

> Thank you. Fixed in 7.4 and later. Thank you for fixing it. -- Bertrand LUPART http://bertrand.gotpike.org/

1 0

Re: [Bug] Parser.HTML crash
by bertrand.lupart＠linkeo.com 24 May '08

24 May '08

> A workaround is perhaps to do > > return ({" "}); > > instead. That way you don't get the entity reparsed and save another > call to your entity callback. Right, works. > The reparsing behavior that you get when returning strings is imho a > bit odd. The RXML parser in Roxen always returns arrays to avoid it > (which could explain why this bug has remained undiscovered for so > long). I'm looking forward this way. Every saved CPU cycle helps. Thank you, -- Bertrand LUPART http://bertrand.gotpike.org/

1 0

Re: Unused variables
by Mirar ＠ Pike developers forum 23 May '08

23 May '08

Take it from the other viewpoint: What kind of errors do you detect with that warning? I don't see many that is worth that warning. Warnings about unused function-local variables, though. That catches many errors and they don't fill any function unused.

5 6

Unused variables
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 23 May '08

23 May '08

You mean people would feel forced to leave out the argument name just to silence the compiler? I can only see that happening for functions in interface classes that defines some kind of callback, and that for some reason need to have a (more or less) dummy body (the warning should of course be disabled for pure declarations). In such cases I'd be fairly satisfied with the option of providing a more complete function declaration using @decl in a refdoc comment. If worst comes to worst, it's always possible to give a name in a comment instead: string chop_chop (object /*context*/, string data) {return data;}

6 15

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel