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

[Tomas Hajny]

On Thu, June 10, 2010 12:01, Bihar Anwar wrote:
> On June 10, 2010 1:46:39 PM, Tomas Hajny wrote:
 .
 .
>>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.

OK, this is a slightly different story then. Win32 API function FindFirst
(and thus also the Delphi function FindFirst provided in SysUtils) returns
the "search handle" (positive value) in case of a success and -1 in case
of an error. The implementation for OS/2 and DOS passes the error
information directly (rather than relying on a subsequent call to
GetLastError, which is again a Win32 API call and not directly
transferable, or using GetLastOSError and relying on the fact that no
other OS API has been used by the RTL in the meantime), but it needs to
use a negative value in order to differentiate from possitive values
meaning success. The same logic is then in turn also used for FindNext
(although that one does never return search handles even on Windows).

Tomas