HN user

abaines

41 karma

alex @ <username> .me.uk

Posts0
Comments15
View on HN
No posts found.

With most installations of X11 / Xlib, there is also an extension library: libXFixes. With this, it is possible to receive an event whenever the clipboard (or any other selection) changes (even if our program is not the owner). [0]

I used this in the past when porting a Windows text editor to Linux that needed to know when the clipboard had changed.

In the C bindings, it corresponds to XFixesSetSelectionOwnerNotifyMask / XFixesSelectionNotifyEvent. There is also a SelectionNotify event in the core X11 protocol, but I'm pretty sure it is different (occurs in response to XConvertSelection - asking for the clipboard contents). Though it has been some time since I wrote the code I'm looking at.

[0] https://www.x.org/releases/current/doc/fixesproto/fixesproto... (6. Selection Tracking)

I feel as though they should change the name of the paper, because this must be one of the most complex takes on 'defer' that I have seen.

They make a classic mistake of trying to solve a problem by adding more complexity. They cannot decide on by-value or by-reference, so they take the convoluted C++ syntax to allow specifying one (as well as other semantics?).

It does not fit with C in my opinion. It will also hurt third party tools that wish to understand C source code, because they must inherit this complexity.

I would prefer a solution where they simply pick one (by ref / by value) and issue a compiler warning if the programmer has misunderstood. For example, pick by-value and issue a warning if a variable used inside the defer is reassigned later in the scope.

I had a go at this myself a few years ago [0]. But I wanted a dynamically linked ELF instead of a static one so that I could load SDL, OpenGL, etc. That requires extras like a DYNAMIC section which takes up quite a bit more space.

I ended up at 728 bytes without any self-extracting techniques. It played a nice animation though.

I have not tested it recently, I expect it won't run any more as it used "bad things", like relying on ecx having a specific value when the program started, but the ideas should still be relevant.

[0] https://github.com/baines/demostuff

The article doesn't mention SECCOMP_RET_TRAP which was an existing way to inspect syscall pointer arguments during interception (when combined with a SIGSYS signal handler).

I'm curious how the two approaches compare - does USER_NOTIF give a greater range of possibilities, or is it mostly just a different interface?

In a small application that forks once and uses seccomp on the child process, would there be much benefit in moving from RET_TRAP to USER_NOTIF?

These are my results on an (admittedly old) Intel i3-2120 CPU @ 3.30GHz. Compiling both programs with -O3:

    ojc_parse_str    1000000 entries in 3607.615 msecs. (  277 iterations/msec)
    simdjson_parse   1000000 entries in  418.997 msecs. ( 2386 iterations/msec)
and might as well throw in my own parser...
    uj_parse   1000000 entries in 1959.731 msecs. (  510 iterations/msec)
The -O3 seems to make a large difference for simdjson.

You may want to add -z noexecstack or linking the object will give your program an executable stack.

e.g: ld -r -b binary -z noexecstack input.bin -o output.o

I was initially surprised that all the lexers treat "[01]" as four tokens, but it makes sense from the state diagram.

In the past I've encountered JSON lexing that only considers token boundaries on "special" characters i.e. ",}]:" and whitespace. This will return a lexing error when it sees "01" (equivalently "truefalse").

The table in [1] has 0 in the carry flag for the SRA instructions, is that correct? I thought they shifted the lowest bit into the carry same as SRL.

You can subscribe via email without any google account by sending a message to <groupname>+subscribe @ googlegroups.com, then it acts just like any other mailing list.