[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 25 Feb 2016 14:52:56 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: missing decription struct named FILE
On Thu, Feb 25, 2016 at 10:36:34PM +0300, Fiodar wrote:
> I always think that FILE is stable public api and may have specific
The public interfaces you can pass FILE* to are a stable public API,
but the contents of the pointed-to object, or even whether FILE* is a
real pointer or just some other kind of opaque reference is completely
unspecified and a matter of implementation internals.
> augmentation in various libc implementations/versions.
> I use musl libc 1.1.14. I need description all fields and how read,
> write an seek operates internally with them.
It's not clear what you want to do. If you just want to be able to
operate on the underlying file descriptor, you can use fileno() (a
standard public function) to get the fd number and use any of the
standard functions from unistd.h on it. However mixing use of the
stdio functions and direct operations on the fd will cause problems if
you don't observe some rules for switching between them.
musl also has some lightly abstracted functions for accessing normally
hidden parts of the stdio FILE state which were added (somewhat
reluctantly) to meed the needs of gnulib. They're declared in
stdio_ext.h and defined in src/stdio/ext.c and src/stdio/ext2.c. I
would not recommend using them in new programs (they're mainly for
legacy compatibility with gnulib) but if the alternative is poking at
the FILE structure yourself, they would be a better choice.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
