[fpc-devel] Weird output from fpGetErrNo

[Ewald]

Once upon a time, on 01/30/2013 08:17 PM to be precise, Marco van de
Voort said:
> In our previous episode, Ewald said:
>> I was just writing a little mmapped (that's two `m`'s -- no typo ;-) )
>> file stream and thought to do it properly just in case I might fork().
>> So I thought to give some advise about memory:
> Why not simply use fpgetcerrnp in unit initc?
I didn't know it existed.


>> I get the most ambiguous results (ENOTTY, ENOENT, which are not even
>> documented as being possible error comditions after this call).
> What do you see if you strace the resulting binary?
When explicitely triggering an error: (madvise(0, 4096))
madvise(0, 4096, 0xa /* MADV_??? */)    = -1 ENOMEM (Cannot allocate memory)

And when using madvise() correctly:
madvise(0x7f5352248000, 31160801, 0xa /* MADV_??? */) = 0

Native fpGetErrNo gives ENOENT / ENOTTY respectively, while my little
experiment gives me ENOMEM / 0 (success) respectively.

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.

So, what's supposed to be the difference between fpgetcerrno and
fpgeterrno (multithreading? [*])?



[*] Maybe not important, but this is a rather heavily multi-threaded
application.

-- 
Ewald