Pike-devel

pike-devel@lists.lysator.liu.se

1 participants
3045 discussions

Over-eager type checking?
by ceder (-) Per Cederqvist ＠ Pike (-) developers forum 03 May '19

03 May '19

This seems like type-checking gone wrong: > has_value(({ "a", "b", "c" }), "d"); Compiler Error: 1: Bad argument 2 to has_value. Compiler Error: 1: Expected: string(97..99). Compiler Error: 1: Got : string(100..100). And it is not just an artifact of Hilfe. Attempting to run this program: void main() { write("%d\n", has_value(({ "a", "b", "c" }), "d")); } Gives this error message: /home/ceder/pike-fun/has-value.pike:3:Bad argument 2 to has_value. /home/ceder/pike-fun/has-value.pike:3:Expected: string(97..99). /home/ceder/pike-fun/has-value.pike:3:Got : string(100..100). Pike: Failed to compile script. If I store the array and the string in variables, everything works fine. What I really wanted to do was to read the documentation of has_value(), as I always forget if the haystack is the first or the second argument. And my browser was unresponsive, so I decided to just test it manually. Perhaps I should have used > doc has_value instead, but that seems broken too: Pike v8.0 release 807 running Hilfe v3.5 (Incremental Pike Frontend) > doc has_value Illegal comment "/*! @decl object _static_modules\n" " *!\n" " *! This is an object containing the classes for all static\n" " *! (ie non-dynamic) C-modules.\n" " *!\n" " *! In a typic Pike with support for dynamic modules the contained\n" " *! module classes are:\n" " *! @dl\n" " *! @item @[Builtin]\n" " *! @item @[Gmp]\n" " *! @item @[_Stdio]\n" " *! @item @[_math]\n" " *! @item @[_system]\n" " *! @enddl\n" " *!\n" " *! If the Pike binary lacks support for dynamic modules, all C-modules\n" " *! will show up here.\n" " */" in "_static_modules.Builtin". scope(0,function(object, mixed : int(1bit)) | function(string, int | string : int(1bit)) | function(array((0=mixed)), 0 : int(1bit)) | function(multiset, int : int(1bit)) | function(mapping(mixed:(1=mixed)), 1 : int(1bit))) This is from a freshly compiled Pike from the 8.0 branch, made with "make -j12 tinstall". The has_value issue also exists on the 8.1 branch, but "doc has_value" is slightly better there: > doc has_value scope(0,function(object, mixed : int(1bit)) | function(string, int | string : int(1bit)) | function(array((0=mixed)), 0 : int(1bit)) | function(multiset, int : int(1bit)) | function(mapping(mixed:(1=mixed)), 1 : int(1bit))) While not very readable, I guess it contains the info I needed. :-)

1 0

Delaying a future/promise by an arbitrary amount of time
by Stephen R. van den Berg 30 Apr '19

30 Apr '19

Say I'm holding a value, but I want to turn it into a promise that fulfills delayed by a predetermined amount of time, any suggestions as to where to put a utility function like that? The first thing that comes to mind would be to create a new member function of Concurrent.Future, i.e. next to the timeout() already there, we could introduce a delay() which would then semantically be something like: Return a Future that will be fulfilled with the result of this Future no sooner than after delay seconds. It's basically a sleep for promises. Any comments? -- Stephen.

2 20

Re: Operator assignment and strict_types
by Marc Simpson 24 Apr '19

24 Apr '19

Bumping this—I believe the behaviour is unchanged in HEAD. On Wed, Mar 28, 2018 at 5:30 PM Martin Nilsson (Coppermist) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Looks like a bug to me. I think these should all give the same > warnings. >

1 0

Re: Pike Meet-up 2019-Q2
by Mateusz Krawczuk 24 Apr '19

24 Apr '19

If moving the meeting to May 11th turns out to be impossible, would it be ok if I dropped by the Roxen office between 13th and 17th afternoon to ask some questions regarding the debugger? śr., 17 kwi 2019 o 11:53 Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> napisał(a): > Hi. > > At Pike Conference 2017 it was decided that we ought to hold a > more informal meeting in Linköping ~ once every quarter. As the > six month mark from the latest conference is coming up soon, > it seems time to announce the second such meeting for 2019: > > Pike Meet-up 2019-Q2 > Date: 2018-05-04 (Sat) > Time: 10:00 - afternoon/evening > Place: Roxen IS AB > S:t Larsgatan 22A > Linköping > > Welcome! > > /grubba >

2 1

Re: Pike Meet-up 2019-Q2
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 24 Apr '19

24 Apr '19

>Any chance it might be moved to 11th May? Sure, I don't have any problem with either date. What do others say? >År., 17 kwi 2019 o 11:53 Henrik GrubbstrÃ¶m (Lysator) @ Pike (-) developers >forum <10353(a)lyskom.lysator.liu.se> napisaÅ(a): > >> Hi. >> >> At Pike Conference 2017 it was decided that we ought to hold a >> more informal meeting in LinkÃ¶ping ~ once every quarter. As the >> six month mark from the latest conference is coming up soon, >> it seems time to announce the second such meeting for 2019: >> >> Pike Meet-up 2019-Q2 >> Date: 2018-05-04 (Sat) >> Time: 10:00 - afternoon/evening >> Place: Roxen IS AB >> S:t Larsgatan 22A >> LinkÃ¶ping /grubba

2 1

Re: Interaction between automap and argument splicing segfaults
by Chris Angelico 04 Apr '19

04 Apr '19

On Thu, Apr 4, 2019 at 11:11 PM Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > > The crash is on this line: > [...] > > If pike is built with PIKE_DEBUG, you get this fatal instead: > [...] > > So the crash is in the compiler proper, not in the execution of the > > program. > > Thanks for the report, test case and investigation. > > Fixed the code generator in Pike 8.0 and master. > Thanks! Confirming that it works with my original code too (from which the test case was derived). Much appreciated! ChrisA

1 0

Interaction between automap and argument splicing segfaults
by Chris Angelico 04 Apr '19

04 Apr '19

Test case: int score_image(string image, int r, int g, int b) {return 42;} array(int) getpixel() {return ({1, 2, 3});} int main(int argc, array(string) argv) { if (argc < 2) exit(0, "All good! Try again with -DBOOM for a segfault.\n"); array images = ({"foo", "bar", "quux"}); for (int x = 0; x < 10; ++x) //Without the loop, no boom { #ifdef BOOM array pixel = getpixel(); array(int) scores = score_image(images[*], @pixel); //Segfault #else [int r, int g, int b] = getpixel(); array(int) scores = score_image(images[*], r, g, b); //But avoiding @ works. #endif } } It's fine with either [*] or @pixel, and it's even fine with both, as long as it's not in a loop. But put all three together, and the interpreter segfaults before executing a single line of actual code, which I suspect means an issue at the compilation stage. (Can be triggered identically by casting "boom.pike" to program too.) Tested with the latest master branch, and with 8.0.735. No idea where to start looking for the cause, but it's a completely consistent crash. ChrisA

3 2

Debugger, Debug Adapter Protocol, Annotations
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 06 Feb '19

06 Feb '19

> Hey Grubba! Hi. > Thanks for a great and fruitful meetup. I've learned a lot of things there. > I'm also really glad that we move the debugger development on. Wouldn't > have done it without you. [...] > Also,would you be able to share the local variable lookup feature so I can > move on with the debugger work? I remember on Saturday the feature was a > little buggy. I hope it will be possible to you to fix it. Anyway, what you > already did would still be useful to me for moving on with work on the > client. I'm in the process of cleaning up the code, and it will enter Pike/master soon (tm). > Thanks and hope to see you on the next meetup! See you. /grubba

1 0

Re: Debugger, Debug Adapter Protocol, Annotations
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 06 Feb '19

06 Feb '19

Hi Mateusz. >Regarding the annotations - I seem to have lost my notes from the meetup, >and have some questions: >I've managed to play around the @Implements annotation and it seems to work >alright. > >Can you remind me what does the @constant annotation do? @constant is a "fake" annotation that sets the PROGRAM_CONSTANT flag on the class it is contained in. This flag indicates that creating instances of the class is valid in constant expressions (like eg in an annotation expression). >I've tried running the annotations() buitin and pass both classes and class >instances to it, but both ways the returned array is always empty. You probably only have annotations on the class itself, and not any on its members. Note that annotations() works analogously to indices(), values() and types(). To see annotations on a class (or inherit) you currently need to have at least on non-protected member of the class, and specify the recurse flag to annotations(). >Is it already possible to define your own annotations in Pike code? If yes, >how to do it? Some examples would be great. You may want to take a look at the annotation tests in src/testsuite.in. An example adapted from the testsuite: local class InheritedImplements { // Extend the default Implements annotation. inherit Pike.Annotations.Implements; // Make it valid to clone this class in a constant expression context. @constant; // Make this attribute inherited. @Pike.Annotations.Inherited; } class A { // Everything that inherits A must implement A. @InheritedImplements(A); int foo() {} } class B { inherit A; int foo() { return 1; } } class C { inherit A; // This fails due to bad return type compared with A::foo(). float foo() { return 1.0; } } >Thanks in advance. /grubba

1 0

Filesystem.Tar misbehaves for setuid files
by ceder (-) Per Cederqvist ＠ Pike (-) developers forum 04 Feb '19

04 Feb '19

I found two issues relating to extracting tar files where a file has the setuid bit set: - unsafe default - setuid but lost To demonstrate these issues, I created this simple C file: --- cut here for setuid-demo.c --- #include <stdio.h> #include <unistd.h> int main() { printf("running as id %d\n", (int)geteuid()); return 0; } --- cut here for setuid-demo.c --- I compiled it, set the setuid bit, created a tar archive, and inspected it: $ gcc -Wall setuid-demo.c $ chmod 4711 a.out $ tar cf a.out.tar a.out $ tar tvf a.out.tar -rws--x--x cederp/cederp 8352 2019-02-04 11:42 a.out Let's extract it using tar to see how it works: $ rm a.out $ tar xf a.out.tar $ ls -l a.out -rwx--x--x 1 cederp cederp 8352 feb 4 11:42 a.out* Ok. We lost the setuid bit. But when we run as root we get it: $ rm a.out $ sudo tar xf a.out.tar $ ls -l a.out -rws--x--x 1 cederp cederp 8352 feb 4 11:42 a.out* Now, let's do the same with Pike: $ rm a.out $ ~/rgit/pike/bin/pike Pike v8.1 release 13 running Hilfe v3.5 (Incremental Pike Frontend) > Filesystem.Tar("a.out.tar")->tar->extract("/", "."); $ ls -l a.out -rws--x--x 1 cederp cederp 8352 feb 4 11:42 a.out* Looking good. But this is of course a flawed test. Let's see what happens when we run this as root? $ rm a.out $ sudo ~/rgit/pike/bin/pike Pike v8.1 release 13 running Hilfe v3.5 (Incremental Pike Frontend) > Filesystem.Tar("a.out.tar")->tar->extract("/", "."); $ ls -l a.out -rws--x--x 1 root cederp 8352 feb 4 11:42 a.out* Oh! I got a setuid-root file! This is the first problem: I don't like that Filesystem.Tar by default extracts the setuid, setgid and sticky bits, while it doesn't extract the user and group info. Changing this would be backwards incompatible, though, so perhaps the best thing you could do is document this. But the issue is arguably in my code . I should have specified EXTRACT_CHOWN if I wanted a root-extracted file to be owned by cederp. Lets do that and see what happens: $ rm a.out $ sudo ~/rgit/pike/bin/pike Pike v8.1 release 13 running Hilfe v3.5 (Incremental Pike Frontend) > Filesystem.Tar("a.out.tar")->tar->extract( "/", ".", 0, Filesystem.Tar.EXTRACT_CHOWN); $ ls -l a.out -rwx--x--x 1 cederp cederp 8352 feb 4 11:42 a.out* The setuid bit is lost! This is because Filesystem.Tar first sets the mode bits, and then sets the owner. Quoting chown(2): When the owner or group of an executable file is changed by an unprivileged user, the S_ISUID and S_ISGID mode bits are cleared. POSIX does not specify whether this also should happen when root does the chown(); the Linux behavior depends on the kernel version, and since Linux 2.2.13, root is treated like other users. It would work better to set the correct owner first, and then set the mode bits.

1 0

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