[fpc-pascal] Negative RTL Error Codes in Some Platforms

[Bihar Anwar]

On June 
10, 2010 1:46:39 PM, Tomas Hajny wrote:

>If I remember correctly, it's been done in order to differentiate standard
>error 
codes (supposedly cross-platform and mostly inherited from TP/BP)
>from all other error codes which may be 
triggered there and which are
>completely platform specific. It's well possible that this convention has
>never been documented and possibly not followed in implementations for
>other platforms either. However, you shouldn't rely on the returned values
>too much anyway. They 
depend not only on the underlying platform, but
>possibly partly also 
on the specific implementation for the particular
>platform - i.e. one RTL function originally based on a single OS API call
>in the DOS 
(TP) times may require several subsequent OS API calls in an
>implementation for another platform and you wouldn't really know which of
>the calls returned the value and why unless you trace the implementation.

Thanks Tomas for your detail explanation. It's a logical reason.

>However, you shouldn't rely on the returned values
>too much anyway.

No, I just rely on such a returned values in a very few cases. For example, In Windows/OS2/DOS, when FindNext() encounters the end of a directory content, it returns ERROR_NO_MORE_FILES (18 or -18); whereas in UNIX, it returns -1 and errno is not set. Thus UNIX doesn;t consider it as an error, and this is more acceptable by me. So, my file searching function will return 0 in this situation. I'm certainly sure such a convention for the basic operations will never be changed in those OSes, so I attempt to handle this.

Thanks in advance. Cheers.