> массив непонятного размера, кстати что это?

это примерно так использовать предлагается:

struct my_str {
    size_t len;
    char data[];
};

struct my_str* alloc_my_str(char *c_str) {
    size_t len = strlen(c_str);
    struct my_str *ret = malloc(sizeof(struct my_str) + len * sizeof(char));
    ret->len = len;
    memcpy(ret->data, c_str, len);
    return ret;
}

Фишка в том, что ты можешь хранить len в том же блоке данных, где у тебя переменного размера массив. Таким образом ты уменьшаешь количество malloc/free, снижаешь фрагментацию кучи, уменьшаешь количество разадресаций при использовании строки, повышаешь кеш-локальность данных, и вообще сплошные плюсы.

Для ядра такого рода структуры совершенно нормальны, они там налево и направо используются. Другое дело, что когда ядро начинали писать, C не поддерживал из коробки подобное, и поэтому вместо char data[], писали char data[1]: такое любой компилятор C съест, правда нулевого размера массив не получится создать. То есть можно, но придётся писать malloc(sizeof(struct my_str) - sizeof(char)). Но это всё хождение по тонкому льду, потому что на разных платформах C может по-разному упаковывать структуры, и несложно подорваться на какой-нибудь мине.

> Да и вообще, теперь ядро будет работать по разному в зависимости от того, как в стандарте Си реализуют какой-то там массив?

Шта? Да. Код на C работает в зависимости от того, что в стандарте написано. Это задумано так.