> > I have developed patch for this in the form of a new routine > > which returns a nul terminated C style string given a parrot > > string as argument. It does this by making sure buflen is at > > least one greater than bufused and then stuffing a nul in that > > byte. > > > > This isn't a particularly brilliant fix so I'm attaching it here > > for comments before I commit it. > > I haven't seen any major objections to this so I have committed > it. It will at least ensure that file opening is stable for the > upcoming release.
If you want something to be looked at, commit it. :) This patch assumes the underlying string is an scii string, since it just sticks a null byte at the end of the string's original byte data. Transcoding to ascii might be more proper. Problem is, if the type syscalls expect is unicode (say plan9 or something), how do we indicate an endofstring? io.ops has an open which also is assuming the native type is ASCII. I submitted a patch that transcoded everything to ASCII, and added the byte, before calling PIO_open, but it seems that it was never applied with whatever patch it was a part of (warnings cleanup perhaps?) Mike Lambert
