Pike-devel May 2008

pike-devel@lists.lysator.liu.se

10 participants
55 discussions

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

Error: Cannot encode overloaded functions (yet).
by Peter Bortas ＠ Pike developers forum 23 May '08

23 May '08

If you handle it yourself you may put it on the blocker list and treat it as a todo, but it might get removed in June if it's not done by then.

1 0

Error: Cannot encode overloaded functions (yet).
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 23 May '08

23 May '08

At least half of the Roxen modules fail to be dumped in 7.7 due to this error. Bad enough to warrant an entry on the blocker list?

2 1

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

23 May '08

Hello, Disclaimer: I'm experiencing a bug in Caudium that makes Parser.HTML to crash. Sorry, i wasn't able to reproduce it with a standalone Pike program due to my lack of full understanding of entities handling in Parser.HTML. There may be a bug in Caudium in this area i'd be happy to solve, but even in this case i guess Pike shouldn't crash. Story: An RXML entity whose return string ends with an XML entity, called with the :none encoding, placed in a tag attibute makes Parser.HTML to crash. For example, if "&myscope.myentity:none;" returns " " the following would crash: <a href='mailto:&myscope.myentity:none;'>foo</a> It won't if "&myscope.myentity:none;" returns "  ". Here's gdb output (Pike 7.6.112): ----8<----8<----8<----8<---- Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000004 [Switching to process 24147 thread 0x2303] scan_forward (feed=0x2a1cbb8, c=0, destp=0xf0080b38, d_p=0xf0080b3c, look_for=0x133d21c, 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:1736 in /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/modules/Parser/h tml.c (gdb) bt #0 scan_forward (feed=0x2a1cbb8, c=0, destp=0xf0080b38, d_p=0xf0080b3c, look_for=0x133d21c, 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:1736 #1 0x013349dc in scan_forward_arg (this=0x2af6790, feed=0x2, c=0, destp=0xf0080b38, d_p=0xf0080b3c, what=SCAN_ARG_ENT_BREAK, finished=1, quote=0xf0080b50) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/modules/Parser/h tml.c:2051 #2 0x0133a448 in try_feed (finished=44157880) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/modules/Parser/h tml.c:3537 #3 0x0133b278 in html_finish (args=-267908296) 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=4027059000, args=-267908296, arg1=0x0, arg2=0xf0080b38) 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=-267908292) at /home/peter/hack/Pike/7.6-distmaker/src/interpret_functions.h:1957 #6 0x0358583c in ?? () #7 0x00019738 in o_catch (pc=0x358a3d4) 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 0x0358a3c8 in ?? () #10 0x00019738 in o_catch (pc=0x297dfdc) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/interpret.c:2051 #11 0x00019814 in jump_opcode_F_CATCH () at /home/peter/hack/Pike/7.6-distmaker/src/interpret_functions.h:1239 #12 0x0297dfd0 in ?? () #13 0x00019738 in o_catch (pc=0x286a5d0) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/interpret.c:2051 #14 0x00019814 in jump_opcode_F_CATCH () at /home/peter/hack/Pike/7.6-distmaker/src/interpret_functions.h:1239 #15 0x0286a5c4 in ?? () #16 0x0001708c in mega_apply (type=44157880, args=0, arg1=0xf0080b38, arg2=0x133d21c) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/interpret.c:2006 #17 0x000d7c18 in new_thread_func (data=0xbfffe3d8) at /sw/src/fink.build/pike7.6-7.6.112-10/Pike-v7.6.112/src/threads.c:868 #18 0x9002bd08 in _pthread_body () ---->8---->8---->8---->8---- Thank you, -- Bertrand LUPART http://bertrand.gotpike.org/

2 1

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

22 May '08

The unused variables warning really finds a lot in Roxen. However, it misses cases with initial assignments, e.g: void main() { int foo = 453; return 0; } Would it be possible to extend it to catch these too? Ideally it should only count non-lvalue references so e.g. even this one would count as an unused variable: void main() { string foo; write ("hello world\n"); foo = Stdio.stdin->gets(); return 0; }

3 4

7.8 blockers
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 22 May '08

22 May '08

Perhaps. That's natural in old code that has been in production a long time, otherwise the bug would have been found and fixed by now. Another case is this from the Search module: private mapping(string:int) query_profile_names = ([]); /.../ void flush_profile(int p) { m_delete(value_cache, p); foreach(indices(db_profile_names), string name) if(db_profile_names[name]==p) m_delete(db_profile_names, name); m_delete(query_profile_names, p); foreach(indices(entry_cache), string id) { array ids = array_sscanf(id, "%d:%d"); if(ids[0]==p || ids[1]==p) m_delete(entry_cache, id); } } Here m_delete(query_profile_names, p) is causing a compilation error in 7.7 since the mapping isn't declared to allow ints as indices. Assuming that's correct, the m_delete is just a NOP at runtime. What the intended behavior is here I don't know, but from a compatibility perspective there's a bit of difference when code just has no effect at runtime and when it doesn't get through the compiler. Furthermore, even if the bug renders a specific function completely dysfunctional, the module should continue to compile; the function might not even be used at all in the end. So there's no real point in discussing how likely the code is to work in spite of the error; a new compilation error introduces a compatibility problem regardless. That's why I'm convinced compatibility checks needs to be done for each and every new error added to the compiler. If that's too cumbersome then we could instead reduce all errors to warnings in compat mode (that is, all errors where the compiler still can generate output). That might be a bit unfriendly to those who are forced to develop in compat mode, but it's better than the alternative (i.e. that the compat system doesn't work).

1 0

7.8 blockers
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 22 May '08

22 May '08

I agree that better error checks are good, but the design goal of the #pike construct is to be able to keep running code that is de facto running on older pike versions. Granted, the old code is not bug free, and it will probably misbehave in some corner cases. But the fact remains that the code is working good enough in practice, and so it shouldn't loudly stop working when a new pike is used in compat mode. All the test cases I've committed so far are condensed from code like that. For example, here's a real case: mapping find_file(string file, object id) { string cache_id; string result; int menunum; string menutype; string imagetype; if(sscanf(file,"%s/%s/%s/_.%s", cache_id,menunum,menutype,imagetype)<4) return 0; object f=Stdio.File(); if(!f->open(get_cache_dir()+"/"+cache_id+"/"+menutype+menunum+"."+imagetype,"r")) { return 0; } return http_file_answer(f,"image/"+imagetype); } menunum has the wrong type here. During runtime a string will be stored there. That usually works just fine in this function. The only problem might be that it doesn't fail correctly in case the input string is incorrectly formatted and doesn't contain a formatted integer after the first "/" (that's assuming that the type is correct and the sscanf format is wrong; it could be the other way around too). This code is flawed, but it has been working good enough. In compat mode it should continue to do so. The errors may still be reported as warnings, though.

3 2

Roxen, Pike or by design?
by cschalkwijk 22 May '08

22 May '08

When defining (in a roxen modue) a function private void Check(int time) { bla, bla, bla int newTime = time(1); more bla bla } trying to call the function time(1) (to get the time) results in an error: Calling non function value. Renaming the method parameter to tme 'solves' the problem. FAFAIK this is strange behaviour, or is it? Greetings Coen __________________________________________________________ Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken wij u dit direct door te geven aan de verzender door middel van een reply e-mail en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren, te verspreiden, bekend te maken aan derden noch anderszins te gebruiken. The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Please notify us immediately if you have received it in error by reply e-mail and then delete this message from your system. __________________________________________________________

5 9

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 May 2008