When I was writing the PIO_parse_open_flags() test it did seem to me rather Perlish to have string flags in the first place. But I'm a new cockroach in town, so I kept my mouth shut, not wanting to get stomped on.
If the PIO_F_* flags used by open() were moved up to io.h then they could be exported as .constants by config/gen/parrot_include.pl and used explicitly.
Various composite flags could be added for convenience.
PIO_F_WRITE_TRUNC (">") PIO_F_WRITE_APPEND (">>") PIO_F_READ_WRITE ("+<", "+>")
Also, add an INT flag version of open.
inline op open(out PMC, in STR, in INT)
It does seem to make more sense to have the open op take an INT mode, à la the Unix open(2), and leave the translation from a flags string to an INT to the language level. This of course leaves the PIO layer less language-specific, which is good, and it also gets rid of ambiguities such as whether "<+" is a valid alternative to "+<", or whether "<<<<<" is valid, or what do do with a mode string such as ";)-", since a bit in an INT is either set or not, making an INT flag-set unambiguous and (probably) never invalid.
Here is the list of modes from the open(2) man page on my system; I'm not sure if this is a subset or a superset of what PIO should support:
O_RDONLY open for reading only
O_WRONLY open for writing only
O_RDWR open for reading and writing
O_NONBLOCK do not block on open or for data to become available
O_APPEND append on each write
O_CREAT create file if it does not exist
O_TRUNC truncate size to 0
O_EXCL error if create and file exists
O_SHLOCK atomically obtain a shared lock
O_EXLOCK atomically obtain an exclusive lock
JEff
