patches for Neutrino port

[Sam Roberts]

From: Marco d'Itri <md at linux.it>
> On Mar 26, Sam Roberts <sroberts at uniserve.com> wrote:
> 
>  >Here are the patches for QNX/Neutrino, mostly checking for ENOSYS
> This is very ugly. You should wrap the code with #ifdefs or provide
> null stubs for the missing functions.

This referring to what? You might leave in the patch for the code
you're referring to next time, saves guessing...

Since I'm not near that code right now, I seem to recall one place
where it was assumed that if mlock() existed but failed it was a BUG(),
but if it didn't exist it was a warning. I added an "&& errno != ENOSYS"
so if it exists but isn't supported yet then it's the same as if it didn't
exist. This seems rational to me, why doesn't it to you?

ENOSYS is a POSIXly ok return value for these functions, the alternative
is adding configuration tests for a system call error, adding another
config.h variable, and wrapping the call in another level of ifdefs, if
the call exists and if it's implemented.

Putting in a stub doesn't make sense, the functions isn't missing, it's
returning ENOSYS, next month when the kernel support is added, it'll
return EOK, why screw around with a bunch of configure-time nonsense?

In another place if RLIMIT_CORE wasn't defined in <resources.h> it
was a warning, and if it was defined but the answer was EINVAL
it was also a warning, and I added an additional check for ENOSYS.

The existing code was doing what I described above (and you seem
to be suggesting is "ugly"): if the calls seemed to be supported, but
return a "sorry, can't really do that" then warn and move on. ENOSYS
in this case means the same thing as EINVAL, so I added the code
to make it be so, what's wrong with that?

In summary:

- You didn't say what code you think ugly, so if I'm guessing wrong
  perhaps you could clarify.

- You seem to be suggesting checking the return value of a system
  call is ugly. gpg already does this, I just added two conditions that
  apparently hadn't been come across by the developers yet, which
  is the nature of porting.

- You suggest wrapping the code in ifdefs, often considered "ugly" in
  their own right, without considering the hacks to the configure script
  that would be required to do a compile time check of runt-time return
  codes.

- And you seem to be suggesting stubbing functions as cleaner than
  checking their return codes.

I'm pretty clearly missing your point, one way or another, so perhaps
you'll elaborate on how you think configure.in should deal with
this more cleanly and simply.

ciao,
Sam