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