Здесь показаны различия между выбранной ревизией и текущей версией данной страницы.
|
blog:vadim_priluzkiy:28-10-2009-a_pochemu_v_os_2_xxx_yyy [28/10/2009 07:02] oxyd создано |
blog:vadim_priluzkiy:28-10-2009-a_pochemu_v_os_2_xxx_yyy [29/10/2009 01:00] (текущий) oxyd Это не бага, это фича (C) |
||
|---|---|---|---|
| Строка 3: | Строка 3: | ||
| - | {{tag>irc_log osfree linux ifs hpfs valerius bug}} | + | {{tag>irc_log osfree linux ifs hpfs valerius openwatcom bug feature}} |
| - | Только что, на канале... Валериус отловил багу __в хедере__ линуксовых исходников. | + | Только что, на канале... <del>Валериус отловил багу __в хедере__ линуксовых исходников.</del> |
| - | [6:30:37] *valeriusN заюзал хедер hpfs.h из линуксовой HPFS. Оказалось, не без ошибок -- в структуре Dir entry поле типа unsigned short разбито на битовые поля. А в хедере стояло просто unsigned, т.е., 32-разрядное, а не 16-разрядное. Я долго не мог понять, почему у меня смешение имени файла от начала dir entry ватком вычисляет неправильно. Оказалось, в хедере бага. ;) как оно работает в линуксе, непонятно... | + | Как показало расследование, это оказалась не бага, а этакая "фича" компилятора 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 ватком вычисляет неправильно. Оказалось, в хедере бага. ;) как | ||
| + | оно работает в линуксе, непонятно... | ||
| ~~DISCUSSION~~ | ~~DISCUSSION~~ | ||