they're SO sassy about msvc lmao

#pragma optimize("agtw", on) /* doesn't seem to make much difference... /
#pragma warning(disable: 4710) / who cares if functions are not inlined 😉 /
/ fastest possible local call under MSVC */
#define LOCAL(type) static __inline type __fastcall

only change since the year 2000 was to avoid lumping in clang-cl with msvc earlier this year (from someone else who also contributed to the jit). didn't ms fire their whole python team recently? that's sad i forgot about that

@mirabilos not ever (though i do bsearch somewhat often), which is why i want more ways to do vla-types, for a dynamic array btw, you can do:

int (*arrayp)[len] = malloc(sizeof(*arrayp));
/* init *arrayp */
qsort_typed(*arrayp, cmp, data);

or, what could be more useful, say you have a struct type:

struct int_array { size_t len; int *data };
#define to_vla(arr) ((int (*)[arr.len]) arr.data)

struct int_array my_ints = ...;
qsort_typed(*to_vla(my_ints), compare, data);

and it’s the reason i really wish we add a way to specify VLA syntax in structures, so we could end up with something similar to:

struct int_array { size_t len; int (*data)[len]; };

struct int_array my_ints = ...;
qsort_typed(*my_ints.data, compare, data);

@mirabilos not ever (though i do bsearch somewhat often), which is why i want more ways to do vla-types, for a dynamic array btw, you can do:

int (*arrayp)[len] = malloc(sizeof(*arrayp));
/* init *arrayp */
qsort_typed(*arrayp, cmp, data);

or, what could be more useful, say you have a struct type:

struct int_array { size_t len; int *data };
#define to_vla(arr) ((int (*)[arr.len]) arr.data)

struct int_array my_ints = ...;
qsort_typed(*to_vla(my_ints), compare, data);

and it’s the reason i really wish we add a way to specify VLA syntax in structures, so we could end up with something similar to:

struct int_array { size_t len; int (*data)[len]; };

struct int_array my_ints = ...;
qsort_typed(*my_ints.data, compare, data);

but there was a followup d3ab61ecbab2b that changed pretty much everything without while taking great pains to obscure it. my favorite part:

-#define BATTERY_CHARGING 0x40
+#define BATTERY_DISCHARGING 0x40

that's a breaking ABI change!! no explanation!

i did think adding measures like power (?) cycle count would seem to be a reasonable thing to introduce into the language we use to talk about batteries. but there's another bit from sbs-battery.c that's concise enough to reproduce in full:

static void sbs_unit_adjustment(struct i2c_client *client,
 enum power_supply_property psp, union power_supply_propval val)
{
#define BASE_UNIT_CONVERSION 1000
#define BATTERY_MODE_CAP_MULT_WATT (10 * BASE_UNIT_CONVERSION)
#define TIME_UNIT_CONVERSION 60
#define TEMP_KELVIN_TO_CELSIUS 2731
 switch (psp) {
 case POWER_SUPPLY_PROP_ENERGY_NOW:
 case POWER_SUPPLY_PROP_ENERGY_FULL:
 case POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN:
 / sbs provides energy in units of 10mWh.
 * Convert to µWh
 */
 val->intval *= BATTERY_MODE_CAP_MULT_WATT;
 break;

https://stackoverflow.com/questions/33051108/how-to-get-around-the-linux-too-many-arguments-limit/33278482

> I have to pass 256Kb of text as an argument to the "aws sqs"

what, uhhh, what

> MAX_ARG_STRLEN is defined as 32 times the page size in linux/include/uapi/linux/binfmts.h:
> The default page size is 4 KB so you cannot pass arguments longer than 128 KB.
> I modified linux/include/uapi/linux/binfmts.h to #define MAX_ARG_STRLEN (PAGE_SIZE * 64), recompiled my kernel and now your code produces

casually patching the kernel to send a quarter megabyte as a *single* argument oh my god i'm laughing hard

https://stackoverflow.com/questions/33051108/how-to-get-around-the-linux-too-many-arguments-limit/33278482

> I have to pass 256Kb of text as an argument to the "aws sqs"

what, uhhh, what

> MAX_ARG_STRLEN is defined as 32 times the page size in linux/include/uapi/linux/binfmts.h:
> The default page size is 4 KB so you cannot pass arguments longer than 128 KB.
> I modified linux/include/uapi/linux/binfmts.h to #define MAX_ARG_STRLEN (PAGE_SIZE * 64), recompiled my kernel and now your code produces

casually patching the kernel to send a quarter megabyte as a *single* argument oh my god i'm laughing hard

which comes from the scheduler! which makes sense since the scheduler controls everything that's happening on the system

#define get_current() (current_thread_info()->task)
#define current get_current()

ooooh this is actually pretty cool. when defining a hash table you always define the number of bits as well

/**
 * hash_init - initialize a hash table
 * @hashtable: hashtable to be initialized
 *
 * Calculates the size of the hashtable from the given parameter, otherwise
 * same as hash_init_size.
 *
 * This has to be a macro since HASH_BITS() will not work on pointers since
 * it calculates the size during preprocessing.
 */
#define hash_init(hashtable) __hash_init(hashtable, HASH_SIZE(hashtable))

#define IMAGING_PIXEL_RGB(im, x, y) ((im)->image[(y)][(x) * 4])
#define IMAGING_PIXEL_RGBA(im, x, y) ((im)->image[(y)][(x) * 4])
#define IMAGING_PIXEL_CMYK(im, x, y) ((im)->image[(y)][(x) * 4])

I'm still wondering why would you keep the image in Y-by-X in memory, but still access it X-by-Y.