I look at the FPC RTL source codes and notice that in some OSes (e.g. OS/2, DOS) every RTL functions which call OS API functions will return the OS error code as a negative number. What is the reason behind this? I don't find such a convention in the official documentation of thouse OSes.

Bihar Anwar wrote

I look at the FPC RTL source codes and notice that in some OSes (e.g. OS/2, DOS) every RTL functions which call OS API functions will return the OS error code as a negative number. What is the reason behind this? I don't find such a convention in the official documentation of thouse OSes.

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.

Tomas

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.

Bihar Anwar wrote

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

.
.

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

Thanks Tomas, that explanation even makes me understand this FPC decision better.