On 30 Jan 2013, at 21:52, Marco van de Voort wrote: > In our previous episode, Ewald said: >> fpgetcerrno from initc gives me the correct results as well; and by >> looking at the code I see it implements it by using `__errno_location` >> under linux, so no surprise there. > > Well, the surprise is that initc worked, and yours not. From a quick glance > I believe it to be correct too.
I believe there is a bit of confusion: my little experiment and the fpgetcerrno both boil down to exactly the same code (both using __errno_location under linux). The reason I wrote it is that I didn't know it was already implemented this way in initc. Both functions obviously work. The function that seemingly doesn't work is the native fpGetErrNo (with native I mean the function that is available in unit baseunix without any modification). > >> So, what's supposed to be the difference between fpgetcerrno and >> fpgeterrno (multithreading? [*])? > > Platform dependent. They can be the same. FPC does its own kernel calls on > some platforms, and the result is then stored in fperrno. That's handy, so it would be advisory to use fperrno as much as possible then. > > fpcerrno is always linking to libc's errno. > > On platforms where FPC uses libc to acces the kernel, errno=cerrno. Thus on linux fpc does its own kernel access then, since errno <> cerrno? So, on this linux, after calling a syscall which I defined as `external 'c'` (like the madvise in the original post) it makes no sense to call fpGetErrno, and instead I should call fpgetCerrno to get sensible results? If the above is right, than errno (without the `C`) contains a leftover error from somewhere before in the program. What bothers me is: what (and why) created the contition? (I know it is not some garbage data in the variable, since it changes over time to another error: ENOTTY --> ENOENT) -- Ewald _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
