[fpc-devel] Weird output from fpGetErrNo

[Ewald]

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