[fpc-devel] Weird output from fpGetErrNo

[Tomas Hajny]

On Wed, January 30, 2013 23:18, Ewald wrote:
> On 30 Jan 2013, at 21:52, Marco van de Voort wrote:
>> In our previous episode, Ewald said:
 .
 .
>> 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?

Correct.


> 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)

I don't think you need to worry too much. It's perfectly normal that
certain functions used within RTL, etc., may end up in a failure code.
Sometimes there's no other way for testing certain things than simply
trying them and checking the result afterwards (and this may happen within
the RTL and RTL itself needs to evaluate what should be cinsidered an
error and what not).

This is one of disadvantages of this way (one common function for checking
the last error) of returning error codes, BTW - if API functions return
detailed error code directly, no such leftovers may happen. Obviously,
there are some advantages too. ;-)

Tomas