findinglisp wrote:If I remember right, there is an internal ECL function for converting between these two. Hmmm... or maybe that was between a raw Unix file descriptor and a stream, not a C FILE*. Look in the source files for ECL (not that large, actually), and you can probably find it. It's in the C section of the source.
c_stream_to_lisp_stream (cl_object* lisp_stream,
int* const info)
int fd = -1;
/* Get integer file descriptor number for the given C stream.
fileno must always return (under Linux at least), but may return
-1 and set errno to EBADF if it can detect that the given stream
(FILE*) is not valid. */
errno = 0;
fd = fileno (c_stream);
if (errno == EBADF || fd == -1)
errno = 0;
*info = -1;
/* Make a Lisp stream from the given file descriptor. Note: it had
better be an input stream of some kind, or you'll be sorry!!! */
*lisp_stream = ecl_make_stream_from_fd (Cnil, fd, smm_input);
*info = 0;
nklein wrote:The FILE* buffers in user-space (your program). Any buffering that happens with the file descriptor (from fileno()) is in kernel-space (your operating system). You will run into trouble if your C code writes to the FILE* before you Lisp code is invoked without calling fflush() because there will be stuff in the FILE* buffer that writes to the fileno would completely ignore.
Also, if your C code reads a few bytes from the FILE*, it probably buffered 4k or 8k under the hood. If you then try to read from the file descriptor, you won't get the next bytes after the few that you read from the FILE*, you'll get the next bytes after what the FILE* buffered. fflush() won't help you out of that one.
Weirder things may happen to if you have the file open Read-Write.
nklein wrote:I think an implementation may be allowed to fill its buffer during the open call if you open the file for reading. I would bet most don't bother. But, I doubt there is a reason they can't.
findinglisp wrote:I'd just modify ECL itself and post a patch to the ECL mailing list. Only that one little portion of your code (the patch) would be under LGPL. If you get into including header files into your other programs, then you start dancing around the line of derivative works and things get messy. Just create the function that you wish ECL had, put it in the ECL codebase, and send a patch to the ECL developers, and call that function from your code.
Users browsing this forum: Google [Bot] and 3 guests