5/n
A semantic quirk of the open() uapi is the definition of the O_RDONLY
flag. It would seem natural to define:
#define O_RDWR (O_RDONLY | O_WRONLY)
but that isn't possible because:
#define O_RDONLY 0
This makes O_RDONLY effectively meaningless when passed to the kernel.
In other words, there has never been a way - until O_PATH at least - to
open a file without any permission; O_RDONLY was always implied on the
uapi side.
I couldn't help myself and last night started attacking unzip with @fanf 's excellent unifdef tool to see what could be done.
https://github.com/fragglet/antizip/commits/main
It's like pulling weeds: you pull out one #define and then you find there are more. And more and more and more and more.
@wolf480pl@mstdn.io my main concern is being able to write rules in a way which allows the user to progressively "opt out" from magic depending on their skillset/needs.
how? -> for example: #ifdef WF_MODEL_SOMETHING \ #define SCREEN_1 ((volatile uint16_t*) 0x2000) \ ... \ #endif - another option could be generating a per-project .h file containing this information
i don't want users to write .ld files directly, as the toolchain's means of layouting sections and converting ELFs to binary files is a moving target
find the bug
#define REVEAL_PASSWORD(password) \
printf("the password is:\n"); \
printf("%s\n", password);
if (password == "my_password")
REVEAL_PASSWORD(password)
else
printf("incorrect password!\n");
#define onion union
[marie kondo voice] #define WIN32_LEAN_AND_MEAN
symptom: TX DAC clock rate is half what it should be
"oh this should be easy"
*hours of troubleshooting with JTAG, gdb, oscilloscopes, spectrum analyzers, etc*
actual problem: missing #define led the function that validates FIR filter configuration to use a broken memcpy implementation