Да де и аз това имах предвид че се вика функция с 32 битов параметър - което ако беше 32 битова ОС нямаше да е проблем щото нямаше да се налага разширяване на числовия литерал който се подава. Просто може-би малко по-неясно съм се изразил ама то от бързане щото съм доста зает тия дни ..и от старост вече може-би...
Не смятам че оптимизацията на gat3way е валидна в случай като нашия когато се вика код от друг модул /библиотечна функция/ по принцип такива оптимизации са възможни само в/върху един и същи т.нар. translation unit или 1 файл или хайде проект да го наречем - само когато и извикващата и извикваната функция се компилират от същия компилатор и той знае какво да очаква и от двете страни. В случая с викането на библиотечна ф-я или изобщо код от друг translation unit компилатора няма как да знае онова чудо(вище) отсреща как е компилирано (дори и да знае че е пак gcc то не знае с какви опции и оптимизации) - може да е друг компилтор напр. icc, msvc, asm или даже аз да съм си го набичил бинарен код и няма как да очаква че моя бинарен код ще му разшири правилно параметъра - затова обик. това разширяване се прави преди извикването на функцията защото след това не се знае как.
напр. 8 към 16 бита че по лесно да речем мойта асемблер функция получи 0xFF как ще знае до какво да го разшири правилно 0xFFFF 0x00FF защото не знае какъв е бил смисъла на тези битове преди извикването на функцията т.е. ако е било число със знак то първото е правилно ако е било без знак то второто...
Затова мойто изначално предположение беше че -
1) имаме бъг в gcc - много малко вероятно при положение че препратката която открих е от 1995 досега все щяха да го оправят
2) нямаме бъг в gcc обаче поради някаква причина не match-ва правилната ф-я или библиотека - който се решава много лесно - даже има два начина: или включваме правилния header или поне подсказваме на компилатора с type cast точно коя ф-я и как да match-не
..и аз заложих на второто (че няма бъг в gcc) тъй като първото ми се видя много малко вероятно.
Изводът е - Винаги включвайте правилните хедъри и желателно е явно/експлицитно да преобразувате типовете а не да оставяте компилатора да си развява... и после до го дебъгвате.
Лек ден ви желая и успехи в раследването
П.П. За съжаление нямам време теди дни да разследвам повече и аз...
П.П.П. Дори и модули компилирани с един с същ компилатор може да имат проблеми заради напр. различни опции по време на компилация напр. даже Майкрософт предупреждаватза "модули" компилирани и от двете страни със същия т.е. техния компилатор не се препоръчва да се link-ват когато са компилирани с различни опции напр. едно и също нещо да ползват като напр. STL (string) защото може да го видят различно :-) според зависи напр. дали DLL е компилиран като много нишков или не и дали е с поддръжка на др. библиотеки от майкросфт напр. MSVCRT*.DLL и с какви оптимизации такак че дори и просто нещо като sizeof(string) да връща различен резултат или дори и да е еднакъв то напр. масив от низове да се подравнява различно.
Извинявайте но в момента се боря с Уиндоус програмиране а и... време e да дадем път и повод и на по-млaдите вече да се изяват. Очакваме резултата шошонче Последна редакция:
при мен ldd показа това
linux-vdso.so.1 => (0x00007fff7a573000)
libc.so.6 => /lib64/libc.so.6 (0x00000030a7200000)
/lib64/ld-linux-x86-64.so.2 (0x00000030a6e00000)
при следните резултати от strace:
no unistd type cast
lseek(3, 18446744073709551606, SEEK_SET) = -1 EINVAL (Invalid argument)
no unistd no type cast
lseek(3, 4294967286, SEEK_SET) = 4294967286
unistd no type cast
lseek(3, 18446744073709551606, SEEK_SET) = -1 EINVAL (Invalid argument)
unistd type cast
lseek(3, 18446744073709551606, SEEK_SET) = -1 EINVAL (Invalid argument)
също забелязах и това че винаги присъства т.е. O_LARGEFILE възможно да и ма пръст в цялата работа...
fcntl(4, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)