I want signal to act as a transport bus. In particular, I want to give certain contacts permission to ask my phone for its location, so I can give my wife that ability without sharing it with Google.
Signal has solved the identity part, now encourage others to build apps on it.
(2fa via Signal would be better than SMS, too, though I know this may be controversial!)
I'm not seeing how you could draw that conclusion. The more likely explanation is that they are telling people not to build apps around it (and I assume thus the apis aren't well designed for adoption by other apps).
> This repository is used by the Signal client apps (Android, iOS, and Desktop)
as well as server-side. Use outside of Signal is unsupported.
Also, where are the test vectors? Because when I implement this, that's the first thing I have to write, and you could save me a lot of work here. Bonus points if it's in JSON and UTF-8 already, though the invalid UTF-8 in an RFC might really gum things up: hex encode maybe?
Andrew Tridgell's KnightCap did this differently: it's a network chess server, and it would dump its data to a file and re-exec. The trick here is that it would keep the (network) fds open for zero downtime. IIRC he used a Perl script called datadumper to gen the code marshal/demarshal the structures.
This has the advantage that reboots can be handled fairly seemlessly too (though there will be reconnections then of).
Eh, you could probably get away with it if you use BearSSL[0]. The only difficulty would be:
These elements can be allocated anywhere in (writable) memory, e.g.
heap, data segment or stack. They must not be moved while in use
(they may contain pointers to each other and to themselves).
Which you could probably get around with by just keeping track of offsets and using mmap
Absolutely. Wrapping the distinguished entry point in a new structure type equipped with a thin type-safe wrapper API that covers the most common use case is the way to go.
In recent years I've come to rely on this non-initialization idiom. Both because as code paths change the compiler can warn for simple cases, and because running tests under Valgrind catches it.
>
ryao 7 hours ago | parent | context | flag | on: Hacktical C: practical hacker's guide to the C pro...
cast a `struct Foo*` into a `struct Bar*` and access the Foo through it (in practice we teach this as the "strict aliasing" rules, and that's how all(?) compilers implement it, but that's not what §6.5 paragraph 7 of the standard says!)
Use the union type. Abusing it for aliasing violates the standard too, but GCC and Clang implement an extension that permits this. Alternatively, just allocate a char array and cast it as you please. Strict aliasing does not apply to char arrays if I recall.
allow a signed integer to overflow
Is this still true? I thought that the reason for this is because C left the implementation to define how signed arithmetic worked, meaning you could not assume two’s complement, but the most recent C standard was supposed to mandate two’s complement.
>> pass a NULL pointer to memcpy, even if the length is zero
> There is a reason for this. memcpy is allowed to start reading early as a performance optimization, before it does a branch that checks if reading is only.
Where did you get this idea from? It's not possible, since you can hand an address at the end of an array, and length 0. The array ends at the end of a page.
Handing memcpy() the address at the end of an array and length 0 is undefined behavior. It is often said that the reason for this is to allow memcpy() to read before it branches to make it fast.
This lead me to think of the case where you hand it the address right before the end of a byte array where the byte after the last byte is an unmapped page and tell it to copy 1 byte. I suspect systems that have such an optimization would read beyond 1 byte into invalid memory. This is my criticism of the idea of having memcpy(NULL, NULL, 0) be undefined to make that speed trick legal. I am suggesting that an undefined number of low values to copy must also be undefined, yet they are not under the standard.
I don't care, as long as a commit which fixes a crash, compiler error or test failure quotes the errorv. This helps searching for issues, and also helps later if you find they mis-diagnosed the problem.
Other peeve: quote the core of the bug report you're closing, so when GitHub inevitably goes away/turns evil/starts charging, you don't lose half your knowledge. The git tree should always stand alone.
It's a trick I stole from ext2, and simplified. In that filesystem there are three bitsets: one for reading, one for writing, one for fsck. If you don't understand a bit you can't do that action.
For most protocols there's only reading and writing, so you can use odd bits to mean "backwards compatible features, you can read even if you don't understand" and even for "stop, we broke compat".
That's a good idea for filesystems. But OpenTimestamps Proofs aren't really "written to". They're created, and then later validated. Also, being cryptographic proofs, my philosophy is the validator should almost always understand them 100%, or not at all, to avoid any false proofs.
That's also why I picked a binary encoding: it's difficult to parse an OTS proof incorrectly. An incorrect implementation will almost always fail to parse the proof at all, with a clear error, rather than silently parse the proof incorrectly.
Signal has solved the identity part, now encourage others to build apps on it.
(2fa via Signal would be better than SMS, too, though I know this may be controversial!)