Things to commit just before leaving your job

- Treat JS code like 7-bit ASCII

- For each character, convert the bits into white space. 1= space, 0 = tab

- A = "1000001" = space tab tab tab tab tab space

- concat it all together, \n shows you are done

So you can represent JS code as just whitespace. Which means this is malicious code:

<script> //st4rt

//3nd

var html = document.body.innerHTML; var start = html.indexOf("//st" + "4rt"); var end = html.indexOf("3" + "nd"); var code = html.substring(start+12, end); eval(hydrate(code)); </script>

As an employee of a company that provides you a paycheck, you "owe" them your best effort. If you don't want to try, quit - but don't sabotage. That is juvenile and perhaps illegal and certainly unethical.

Either he still has the code, in which case he's supposed to hand it over.

Or he deliberately destroyed it, which means destruction of company property. Deliberate? Yes, because a programmer claiming "oh didn't realize you wanted to keep the source codes!" is not going to fly very far in court.

(BTW I'm modelling this on my assumptions about how this would play in Dutch court, which can be delightfully pragmatic. So there might be some differences how this would work in the USA, such as others commented, ability to afford justice in the first place)

https://en.wikipedia.org/wiki/Private_prosecution#United_Sta...

    irb(main):009:0> class Fixnum; def + other; 42; end; end
    => nil
    irb(main):010:0> 4 + 5
    => 42

A thing you have to understand about PHP - at least, the php.net/Zend Engine PHP most people use - is that what is and isn't in its "standard library" isn't as well-defined as it is for, say, Python. At its most basic, PHP is just the /Zend directory of the source tree: a lexer, parser, compiler and interpreter for PHP code. It can run PHP code, but Zend alone can't do anything except maybe tell you how long a string is.

In order to actually do anything, you need functions and classes that interact with the outside world. And all of these, even the "standard" ones, are implemented as extensions. These are libraries that plug into the Zend engine and expose functions, classes and constants. You can enable them or disable them at compile-time. You can build them into the interpreter itself (static linking), or load them at runtime (dynamic linking).

PHP's source code repository, alongside the /Zend directory containing the PHP interpreter, also contains an /ext directory containing a bunch of different, useful extensions. Only a few of these are always compiled and cannot be disabled, such as /ext/standard, which includes a large number of functions dealing with things like file I/O, strings, array manipulation, password hashing, number conversion, and so on. There's also /ext/date, which manipulates dates. These are the only extensions guaranteed to be available in PHP. They're the most minimal definition of PHP's standard library.

But there's a lot of other stuff in /ext. There's JSON parsing (/ext/json), database connectivity (/ext/pdo, /ext/mysql, etc.), image drawing (/ext/gd) and arbitrary-precision arithmetic (/ext/gmp) among other things. These are all maintained by the core PHP maintainers alongside PHP versions.

However, alongside all of these, there's tons of community-maintained extensions in PECL. You can find all kinds of stuff in there, such as runkit, the extension you're talking about. Sometimes, extensions from PHP core move into PECL (usually dead ones), sometimes extensions from PECL move into PHP.

Anyway, presumably because there's no real difference between PECL and PHP-maintained extensions, both can be found in the manual. That's why runkit's there - it's not part of PHP proper, but it is on PECL. It might seem strange to group things into the manual that aren't officially maintained by PHP, but most of PHP's core extensions need separately installing anyway.

tl;dr: all the functions, classes and constants in PHP are defined by extensions, and the manual includes extensions that aren't part of PHP proper. PHP in most distributions only ships with a few of these enabled. runkit isn't part of PHP.

In C and C++, volatile is not intended and must not be used for synchronisation primitives, it is not a memory fence (so it does not force cache coherency and does not prevent operations reordering) and operations on volatile variables are not atomic. Its primary use case is memory-mapped IO (with a sub-use case of preventing eliding memory operations affected by inline assembly). If a lock is broken because `volatile` is disabled, it's probably incorrect in the first place.

All `volatile` does[0] is forbid elision of loads and stores.

[0] again in C or C++, Java and C# have completely different semantics