[Octave-bug-tracker] [bug #47820] Uncomprehesive behaviors for functions that are not recognized in configure

[Mike Miller]

Update of bug #47820 (project octave):

                Severity:              3 - Normal => 1 - Wish               

    _______________________________________________________

Follow-up Comment #6:

I did a quick search for the string "not supported on this system". It
basically boils down to the user-callable functions defined in
libinterp/corefcn/{getgrent,getpwent,syscalls}.cc. I'm assuming that string is
used everywhere for functions that may not exist on the host operating system,
it may not be.

These functions return a "msg" output argument instead of maybe raising an
error condition, which is possibly what Tatsuro would prefer.

* dup2
* endgrent
* endpwent
* exec
* fcntl
* fork
* getgrent
* getgrgid
* getgrnam
* getpgrp
* getpwent
* getpwnam
* getpwuid
* kill
* pipe
* setgrent
* setpwent
* uname
* waitpid

Tatsuro, these are all basically wrappers around POSIX functions, and it's
expected that users calling them are familiar with the way that these POSIX
functions work, including what integer return values are meaningful and what
are not.

The POSIX equivalent is usually to check for a -1 return value, and then
decode the value of the errno variable into a standard error message. In
Octave this is turned into a second (or Nth) output argument that contains the
error message.

Some functions do already raise an Octave error condition, for example popen2,
but most return the error message as an output argument and return an invalid
value.

I can see the case for consistently raising Octave errors if the function
returns an error string, or for keeping things the way they are now and
requiring the user to check the return value.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47820>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/