Flags as a system call API design pattern

Posted Feb 14, 2014 22:42 UTC (Fri) by giraffedata (guest, #1954)
In reply to: Flags as a system call API design pattern by nybble41
Parent article: Flags as a system call API design pattern

This has happened multiple times in the Linux userspace APIs, and since breaking previously-working user applications isn't allowed no matter how they abuse the APIs, you effectively can't redefine any bit you've previously ignored.

Has this really happened with fields that are documented as "reserved for future use - must be zero" and someone put random garbage in there?

It isn't really true that you can't break previously-working user applications with new kernel code. There are a few cases of API abuse becoming the standard that make the news because the abuse was so widespread to be worth tolerating, but I'm sure there are thousands of instances where some application bug that was innocuous in Linux N expressed itself in Linux N+1 and everyone agreed breaking the application was appropriate.

The widespread abuses usually were somewhat deliberate - it saved someone significant effort or seemed to be legal. In contrast, failing to initialize memory is more likely to be in the rare and unforgiven category.