--On Wednesday, February 09, 2011 10:08:14 AM -0600 David Boyes
<[email protected]> wrote:
But the "transaction" above it doesn't exist in a standard. While
conceptually it exists, the only place it's really documented as such
is
in the existing implementation(s). So, as I read it, giving the RPCs a
successful return code is already tying us to the implementation, since
it just comes from the convention of the C librx implementation. At
least, that's how I read "if you really want to avoid making
assumptions
based on the implementation..."
Gotta start somewhere. Implied operations are not good practice
No. Undocumented assumptions are not good practice. Implied things are
fine, as long as they're documented.
You asked about the section that defines error codes, and whether we had a
constant to use for "success". The answer is that we do not, because the
error codes in question are the codes sent in an Rx abort packet when an
RPC fails. If the RPC succeeds, no abort is sent, and thus there's no need
for a code to be used in abort packets to indicate success.
The question of how the Rx layer indicates to the application the
distinction between a call that succeeds, a call that is aborted by the
peer, and a call that fails for local reasons is entirely up to the
implementation.
Really, how tough is it to #define RX_SUCCESS 0 and then use the constant
in the text instead of hardcoding a fixed value in the spec?
There is no fixed value hardcoded in the spec. The packet that contains
the error code _is not sent at all_ if the call doesn't fail.
OpenAFS's Rx implementation models RPC's as function calls, returning an
integer which is the error code from the abort, or a locally-generated
error, or 0 if the call succeeds. For such an implementation, it is mostly
reasonable to define a constant for success(*). But that's up to the
implementation; it doesn't appear on the wire and is not part of the spec.
-- Jeff
(*) Mostly, but not entirely. Success-as-zero is _not_ just another value,
because zero is special in C and most C-like languages. A function which
returns 0 on success allows for relatively clean, simple code like
if (unlink("/my/file")) {
... do something about the error ...
}
Whereas if unlink returns 5 on success, you have to write
if (unlink("/my/file") != 5) { ... }
or even
if (unlink("/my/file") != SYSCALL_SUCCESS) { }
and it starts to get harder to read.
If something is going to return 0 on success, then it should be defined to
return 0, not FOO_SUCCESS-which-just-happens-to-be-zero, because doing so
allows callers to use language features that interpret expressions in a
boolean context, and because on some architectures, comparison to zero is
shorter, faster, and/or implied.
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
