Is there a function for obtaining a BPTR file handle from a newlib file descriptor similar to _get_osfhandle() function in Windows? I could really use such a function in a project that I'm working on. If there isn't I will probably have to give up on this project for now as I don't feel like rewriting all file i/o code I've written until now to use file descriptors at the moment.
Wed, 2011-05-04 18:02
#1
Newlib file descriptors
If there were such a function, I think someone would have responded by now. Maybe such a function isn't available because it could be unsafe to access a file by file descriptor and by the underlying file handle. I don't know what you plan on doing with the filehandle but I imagine that reading or writing the file with the filehandle without changing the data in the file descriptor could result in file corruption if the file is subsequently accessed through the file descriptor. It seems like it would be safer to change your file functions to use AmigaDOS equivalents. Change fopen() to IDOS->FOpen(), fread() to IDOS->FRead etc. etc.
X1000 - OS 4.1FE
TBH I didn't think there would be but I felt I had to ask at least. Would be nice if it was added though as it shouldn't be that much work to implement.
That's not a problem on AmigaOS any more than it's on Windows.
The library API requires that the file i/o code should be able to accept a file descriptor. If my port can't do this then it is useless. The only alternative without _get_osfhandle() function would be to rewrite the code to use file descriptor i/o which I won't do because I hate doing file i/o this way and I won't be able to get large file support this way either.
The only other option I can think of is to use clib2 and access the file descriptor structure to obtain the underlying filehandle. The clib2 sources are in a sourceforge CVS repository so you can check out the code and find the descriptor structure. I checked out the clib sources and found what appears to be the fd structure and it has a member which appears to be the filehandle. I would still have concerns about the safety of doing things that way.
X1000 - OS 4.1FE
Using clib2 isn't an option for what I want to do.
There is no way to do it yet with newlib but it is a feature I want added.
Good to know I'm not the only one who wants it. Does this mean that you have filed a feature request or something like that? Should be pretty easy to implement, I would expect, for anyone with access to the newlib source code.
newlib does use some clib2 code underneath the covers so if you look at the clib2 code you will have a very good idea on how to implement the feature in newlib.
The feature is extremely useful and would make it possible to use newlib in more contexts where clib2 is currently required.
Perhaps a safer alternative would be a hybrid function that clones the file descriptor into a DOS file handle by duplicating it? That way the danger of using the same file handle between DOS and Newlib functions would be avoided.
Or even the opposite way, say open a file in normal DOS functions and then be able to pass it to a Newlib function that can clone a file descriptor off it.
I wonder, if this can actually be done in an "inefficient" manner, that is grab the file descriptors path name and simply open a file from DOS using the name?