А почему в OS/2 xxx yyy?

Только что, на канале… Валериус отловил багу в хедере линуксовых исходников.

Как показало расследование, это оказалась не бага, а этакая «фича» компилятора OpenWatcom…

[14:52:29] valeriusN: Moveton: а что, в gcc если unsigned short в структуре поделена на 
битовые поля, то можно писать просто unsigned? -- я взял hpfs.h от линукса, а там много раз 
unsigned char, unsigned short и unsigned long заменены на просто unsigned -- так и должно быть? 
-- ватком на таких местах выдает неправильные смещения
[14:52:58] Moveton: valeriusN известная багофича стандарта C
[14:53:28] valeriusN: Moveton стандарта C? -- а почему ватком такого не понимает?
[14:53:43] Moveton: valeriusN что ж ты раньше молчал, что у тебя не unsigned, а битовое поле? ;)
[14:54:33] valeriusN: Moveton я вообще-то думал, что просто unsigned это unsigned long ;)
[14:54:47] Moveton: valeriusN ууу
[14:54:51] [Pasha]: так помнится icc на unsigned битовое поле всегда лепит 32 бита... а на все 
остальное матерится
[14:56:49] valeriusN: [Pasha] ватком тоже молчаливо предполагает что unsigned это unsigned long 
(если 32-разрядный компилер)
[14:57:32] Moveton: valeriusN вообще-то ватком предполагает int, как и положено
[14:57:45] valeriusN: Moveton выходит, поведение icc или wcc386 это не стандарт, а gcc ведет себя 
по стандарту?
[14:58:07] valeriusN: ну да, unsigned int а не unsigned long т.е.
[14:58:30] valeriusN: Moveton т.е., для битовых полей исключение?
[14:58:53] Moveton: valeriusN ща допишу ответ :)
[15:00:21] Moveton: valeriusN По синтаксису там дурка такая: согласно стандарта на битовое поле 
можно ставить тип только int. А вот какого оно размера, не специфицируется. VAC и gcc делают в 
итоге размер в соответствии с количеством бит в поле. Ватком расширяет стандарт и позволяет 
указывать произвольный целочисленный тип. При этом размер поля будет равен размеру этого типа
[15:01:36] valeriusN: хм
[15:03:02] valeriusN: а тут понимаешь ли, бочку стали катить на линух, что они де-стырили 
16-битный хедер и unsigned как было, так и оставили (но тогда б, по идее, ничего у них бы не 
работало)
[15:05:45] Moveton: valeriusN а в ваткоме оно у них наверняка и не работает :)
[15:06:38] valeriusN: Moveton просто на ваткоме никто не пробовал линуксовую hpfs собирать ;)
[15:07:33] Moveton: valeriusN ну так бы и попробовал. Перед тем, как портировать

Вот такая вот загогулина! (C)

[6:30:37] *valeriusN заюзал хедер hpfs.h из линуксовой HPFS. Оказалось, не без ошибок -- в  
структуре Dir entry поле типа unsigned short разбито на битовые поля. А в хедере стояло просто 
unsigned, т.е., 32-разрядное, а не 16-разрядное. Я долго не мог понять, почему у меня смешение 
имени файла от начала dir entry ватком вычисляет неправильно. Оказалось, в хедере бага. ;) как 
оно работает в линуксе, непонятно...