Pike-devel February 2019

pike-devel@lists.lysator.liu.se

2 participants
7 discussions

Pike Meet-up 2018-Q1
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 21 Oct '21

21 Oct '21

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 three month mark from the conference is coming up soon, it seems time to announce the first such meeting for 2018: Pike Meet-up 2018-Q1 Date: 2018-02-03 (Sat) Time: 10:00 - afternoon/evening Place: Roxen IS AB S:t Larsgatan 22A Linköping Welcome! /grubba

2 13

Operator assignment and strict_types
by Marc Simpson 08 Jul '20

08 Jul '20

Hi folks, It looks like operator assignment (op=), increment and decrement statements aren't subjected to the same typechecks as their more explicit equivalents. For example, neither the post-increment nor += statements below warn with strict_types enabled, even though they assign values outside of foo's restricted int domain: int(3..3) foo = 3; foo++; // no warning foo += 1; // no warning foo = foo + 1; // warning from strict_types Similarly, operator assignment on aggregates fails to elicit a warning: array(int) a = ({}); multiset(int) b = (<>); mapping(int:int) c = ([]); // no warnings a += ({ "hey" }); b += (< "hey" >); c += ([ "hey": "there" ]); // warnings from strict_types a = a + ({ "hey" }); b = b + (< "hey" >); c = c + ([ "hey": "there" ]); I'm guessing this is because the checks provided by the F_ASSIGN/F_ASSIGN_SELF case (las.c) only apply to direct assignment; op= and friends are presumably not instrumented for strict_types in the same manner. Have there been any discussions around addressing this inconsistency? Thanks, Marc

3 3

Remixml, javascript module
by Stephen R. van den Berg 26 Feb '20

26 Feb '20

This might be of interest to the Pike and/or Roxen community: https://www.npmjs.com/package/remixml I just launched it. Using it in a Single-Page-Application website. Any critical feedback is welcome (I'm currently the only user, so changes in the API are easy and still allowed). >From the description: Remixml is an XML/HTML macro language/template engine. The language and primitives used blend in completely with standard XML/HTML syntax and therefore integrate smoothly with existing XML/HTML syntax colouring editors. Requirements It runs inside any webbrowser environment (starting at IE11 and up). For historical reference: Remixml was originally inspired by RXML, the Roxen webserver macro language. -- Stephen.

1 1

Re: debugger, status and suggestions sought
by Mateusz Krawczuk 04 Nov '19

04 Nov '19

I think having both LSP <https://microsoft.github.io/language-server-protocol/> and DAP <https://microsoft.github.io/debug-adapter-protocol/> implementations for Pike would be awsome, but I feel that this discussion is getting further away from it's main point. We've been talking about LSP for a little during the Conference. There is a huge interest in it and I think we should move the LSP discussion to another mailing thread to avoid mixing contexts. Having a Pike debug adapter would also be great, but since DAP is used for estabilishing communication between IDE and the debugger, we can't move on with it until we actually have a debugger. >From what I understand the greatest challenge now would be to reach the local variables. I've heard that long time ago, the language got some optimizations that makes retrieving local variable names very challenging. Is it true? If yes, how we can jump this through? I would be more than happy to help crossing-out the remaining TO-DOs, if I only could get some itroduction and clues.

5 25

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

07 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 07 Feb '19

07 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

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 February 2019