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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel