|Do you know where your variables are?|
One downside I can think of here is, if you accept a passed-in filehandle, and use it directly, then your method will be altering the file position of the caller's handle.
Thatís not a bug, itís a feature!
It has to work this way, because otherwise you will get mangled I/O. It is critical that the seek points be the same or else you get overwrites and duplicate reads on seekable devices. You will also incur behavioral differences between running on nonseekable devices like sockets, pipes, and ttys then when running on seekable devices like disk files. Completely misery and chaos would ensue.
Never assume that you alone have the sole copy of a particular kernel file descriptor. If you are relying on that, you are almost certainly broken in some way. Passed in descriptors are quite possibly duplicated in another process; with the std streams, this is virtually guaranteed.
In fact, even if you open a file yourself, you cannot know you have the only copy because you cannot guarantee that you are not yourself a clone, since any function that you call after the open is welcome to fork itself an identical process. You cannot know you are who you think you are ó or least, not easily.
Welcome to Unix, and have a nice day.
In reply to Re^2: Difference between File Handles and File Descriptors in function parameters.