fatal SIGSYS under irix

[Tim Peters]

[Quinn Dunkan]
> % python                                                    ~/tmp
> quinn at cholera
> Python 1.5.2 (#10, Feb 11 2000, 15:14:46)  [GCC 2.8.1] on irix6-n32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> f = open('foo')
> >>> f.seek(1, -4)
> zsh: 61898 invalid system call  python
> 140%
>
> Granted, I reversed the order of the arguments for seek().  But
> killing the interpreter is a bit harsh.  This happens on all
> irix systems I was able to test.  Linux just ignores the bad
> SEEK_* arg.

I'd say both OSes are unreasonable here (Irix shouldn't blow up, Linux
should at least complain).  Under Win95 (dear Lord, how embarrassing for
Unix <wink>):

>>> f = open("blah.blah")
>>> f.seek(1, -4)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
IOError: [Errno 22] The device does not recognize the command
>>>

> I don't know if this is because it doesn't send SIGSYS for that, or
> because linux python is catching it.  The hpux and solaris boxes
> are down so I couldn't test them...

Look at function file_seek in Objects/fileobject.c.  Regardless of platform,
Python clears errno, calls the platform's flavor of fseek, and raises an
exception based on the new errno value if the fseek returns a non-zero
result.

Python generally doesn't try to validate arguments when using a tissue-thin
wrapper around a libc function, partly because it seems redundant, partly
because it doesn't want to prevent you from getting at platform-specific
extensions.  But if the platform fseek is unreasonable about error-checking
under several OSes, Guido would probably opt to validate fseek's argument
himself.

the-python-implementation-would-be-a-lot-simpler-if-oses-worked-ly
    y'rs  - tim