neoteric · HackerTrans

Absolutely, RAII is an abstraction (and a useful one), but it has a cost in that it prevents a form of useful optimization because cleanup is required at the destruction of the stack frame. You'd expect the same in C if you explicitly had to call a cleanup function on return from a call.

What C++ does with RAII is make this tradeoff not obvious. std::unique_ptr is a great example to show this: colloquially a std::unique_ptr is "just a pointer", but it isn't in this case because it's non-trivial destructor prevents TCO.

neoteric

5 anni fadiscuss

One thing I've been thinking about in C++ land is that just how much the idiomatic usage of RAII actually prevents the compiler from doing it's own tail call optimization. Any object instantiated in automatic storage with a non-trivial destructor is basically guaranteeing the compiler _can't_ emit a tailcall. It's rather unfortunate, but perhaps worth it if the traideoff is well understood. Example: https://godbolt.org/z/9WcYnc8YT

neoteric

12 anni fadiscuss

For what it's worth, this is broken when the target directory contains spaces/wildcard characters, etc. I would suggest you consider using something like the following to generate the command line you pass to ssh:

  printf -v cmd 'cd %q && $SHELL -l' "$target_dir"

Also, dropping the ':' and just having an additional argument would make your life a bit simpler. What's with the array assignment just to invoke the command? Seems a bit unnecessary. The microoptimizer in me tells me you should use 'exec' as well :).

neoteric

13 anni fadiscuss

Firstly, the Linux kernel already provides easy accessors for the MSRs, see arch/x86/include/asm/msr.h. Secondly, have you investigated the existing msr-tools package, and the existing driver for msr accesses? (see /dev/cpu/<n>/msr in usermode and arch/x86/kernel/msr.c providing the functionality).

neoteric

13 anni fadiscuss

How would that work? The MSRs are _not_ memory mapped.

neoteric

13 anni fadiscuss

The contrived examples you've shown aren't examples of POSIX-incompatibility, or bugs in `find` at all. You've explicitly involved the shell. Of course trying to run every directory name as a shell command string is going to result in executed code!

Your original argument was that given:

    find . -type d -exec chmod g+x {} ';'

It is possible to force code execution of arbitrary commands given a carefully crafted directory name. The key difference in this case is that the shell is not involved _at all_. I challenge you to find an implementation of `find` that is broken in this way.

As a side note, it is even possible to involve the shell in the picture in a safe way with `find`, without the use of `xargs` (and thus avoid the overhead of setting up a pipeline):

    find . -type d -exec sh -c 'chmod g+x "$1"' _ {} ';'

(my contrived example is quite poor, though, since it does nothing but introduce unnecessary shell overhead)

Modern (POSIX > 2001?) `find`'s support `-exec {} +` which further reduces the number of reasons to invoke `xargs`:

    find . -type d -exec sh -c '
        for x; do
            do_foo "$x"
            do_bar "$x"
            do_baz "$x"
        done
    ' _ {} +

(example above shows how to make proper use of this feature with an explicit shell invocation)

neoteric

13 anni fadiscuss

I am assuming a POSIX-compliant implementation of `find`. The shell is not involved.

FWIW, your `find -print0`/`xargs -0` is not POSIX.

neoteric

13 anni fadiscuss

This is simply not true:

    $ mkdir '; echo woops'
    $ find . -type d -exec echo {} ';'
    .
    ./; echo woops

As you can see 'woops' is never echoed.

EDIT: The reason being the shell is never involved in this process, and the shell is what is responsible for splitting commands on semicolons/newlines.

comments