fcntl semantics

[Michael Hudson]

buzmeg at newsguy.com writes:

> I've had to deal with fcntl directly for a while now and was
> thinking of moving my C programs to Python.  However, the OS
> dependence of the packed structure used to access fcntl pretty much
> stops that idea cold.  So, my question is:
> 
> Why does fcntl use a packed struct as it's third argument?

Ease of programming most likely.  Not that for ioctl, just about
anything can be stuffed into the last arg, so there's no way of
programming for all cases.  fcntl is less of a pain in this regard.

> And why does it throw away the return code in that case?

It doesn't.

> That particular mechanism actually goes out of its way to lose data.
> The complier knows the correct form of struct to put the data in
> when it compiles the modules, throws it away, the user has to dig
> out what that structure was, and then hard code it into the Python
> code.  Additionally, it throws away the error/return code when you
> pass it a packed struct as the final argument.
> 
> I can think of several ways that it could be coded, but the one I
> find the most appealing is:
> 
> fcntl(fd,op,arg):
>     arg is a hash -- keys are fcntl struct member names -- vals are values

What is this "struct fcntl" of which you speak?  Surely "arg" is still
allowed to be an integer?

>     return value is a hash in same form
>     Exception raised on error with return/error value in exception object
> 
> All the information from the C function fcntl is accessible without
> any of the nasty OS/compiler dependence.  It even allows future
> extension to the fcntl structs to be accomodated without changing
> the language semantics.  It also doesn't require in place
> modification of data so it has a low surprise factor.  In addition,
> the type of arg is different and identifiable from the previous form
> of fcntl (thus, previous semantics can even be preserved if
> desired).
> 
> I would really like to know if there is a good reason for requiring
> packed data for fcntl (Perl does the same blasted thing), and, if
> not, the proper mechanism for attempting to get this changed in the
> language.  I would even write the code, if required.

It seems to me that all that is missing is a (fairly) portable and
sane way of getting at F_GETLK, right?  F_SETLK is covered by
fcntl.lockf.  So write fcntl.get_lock or similar, returning either a
dictionary or (better) a Python object with fields corresponding to
the struct members and fire the patch at:

    http://sourceforge.net/tracker/?group_id=5470&atid=305470

I don't know whether it would get into 2.2, though.

Cheers,
M.

-- 
  it's not that perl programmers are idiots, it's that the language
  rewards idiotic behavior in a  way that no other language or tool
  has ever done                         -- Erik Naggum, comp.lang.lisp