| View previous topic :: View next topic |
| Author |
Message |
Måns Rullgård
Guest
|
 Posted: Tue Oct 21, 2008 1:04 am Post subject: Re: Reading /proc//maps file |
 |
|
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
| Quote: | It is technically correct that, just because a file descriptor is
supposed to be associated with any particular stream, the
stdio-implementation itself need not necessarily use any particular
set of I/O-primitives provided in some operating environment, eg stdio
could be implemented as set of system calls operating on special
purpose kernel objects which are purposely incompatible with the other
I/O-interfaces provided by this kernel (and this is probably not much
different from the situation in 'certain operating environments' ...)
but for UNIX(*) and anything like it, this is simple: stdio is a
library sitting on top of the kernel system call API and is
implemented by using the same facilities any other lump of userspace
code could use, too.
|
Any modern Unix-type kernel has many system calls outside the ones
required by SUS. A libc designed specifically for, say, Linux is free
to use Linux-specific system calls to implement any functionality.
For example, there is no guarantee that fread() ever invokes a read()
system call, although it seems to (I haven't read the spec carefully)
be required to have an open file descriptor that *could* be used with
read().
--
Måns Rullgård
mans@mansr.com |
|
| |
|
 Back to top |
Jasen Betts
Guest
|
| Posted: Tue Oct 21, 2008 1:53 pm Post subject: Re: Reading /proc//maps file |
|
|
On 2008-10-20, David Schwartz <davids@webmaster.com> wrote:
| Quote: | On Oct 18, 3:18Â am, Jasen Betts <ja...@xnet.co.nz> wrote:
On 2008-10-17, David Schwartz <dav...@webmaster.com> wrote:
Really? How do you even know that "fread" call "read"? All you know is
that "fread" works for normal files "somehow".
The existance of fileno(3) gives a strong hint.
It's possible that this function opens a file, rather than returning
one that's already opened.
|
The function fileno() examines the argument stream and
returns it's integer descriptor.
I think they would have used different wording if there was a chance
of any side-effects.
then there is the fact that fileno(stdin) returns the same number as
the macro STDIN_FILENO and also the behavior of fdopen() ...
Bye.
Jasen |
|
| |
|
| Back to top |
Rainer Weikusat
Guest
|
| Posted: Tue Oct 21, 2008 3:39 pm Post subject: Re: Reading /proc//maps file |
|
|
Måns Rullgård <mans@mansr.com> writes:
| Quote: | Rainer Weikusat <rweikusat@mssgmbh.com> writes:
It is technically correct that, just because a file descriptor is
supposed to be associated with any particular stream, the
stdio-implementation itself need not necessarily use any particular
set of I/O-primitives provided in some operating environment, eg stdio
could be implemented as set of system calls operating on special
purpose kernel objects which are purposely incompatible with the other
I/O-interfaces provided by this kernel (and this is probably not much
different from the situation in 'certain operating environments' ...)
but for UNIX(*) and anything like it, this is simple: stdio is a
library sitting on top of the kernel system call API and is
implemented by using the same facilities any other lump of userspace
code could use, too.
Any modern Unix-type kernel has many system calls outside the ones
required by SUS.
|
Eh ... yes. So what?
| Quote: | A libc designed specifically for, say, Linux is free
to use Linux-specific system calls to implement any functionality.
|
Please name the thing and the people responsible for it, so that I can
be certain to never inadvertently use it. Generally, 'the Linux
C-library', ie the C-library used by default on a Linux-distribution
is the GNU C library. The GNU C-library has
a) a certain documented behaviour.
b) an open source implementation.
| Quote: | For example, there is no guarantee that fread() ever invokes a read()
system call,
|
I already wrote in my first sentence that the UNIX(*)-specification
does not demand that stdio uses any particular other facilities of a
system. But this is of little interest to me (or anyone with an actual
problem), because one does not program the UNIX(*)-specification (it
is actually of really little interest to me, because stdio is
historical cruft and its use should IMO be avoided). |
|
| |
|
| Back to top |
Rainer Weikusat
Guest
|
| Posted: Tue Oct 21, 2008 3:49 pm Post subject: Re: Reading /proc//maps file |
|
|
Jasen Betts <jasen@xnet.co.nz> writes:
| Quote: | On 2008-10-20, David Schwartz <davids@webmaster.com> wrote:
On Oct 18, 3:18 am, Jasen Betts <ja...@xnet.co.nz> wrote:
On 2008-10-17, David Schwartz <dav...@webmaster.com> wrote:
Really? How do you even know that "fread" call "read"? All you know is
that "fread" works for normal files "somehow".
The existance of fileno(3) gives a strong hint.
It's possible that this function opens a file, rather than returning
one that's already opened.
The function fileno() examines the argument stream and
returns it's integer descriptor.
I think they would have used different wording if there was a chance
of any side-effects.
|
Each function that operates on a stream is said to have zero
or more ``underlying functions''. This means that the stream
function shares certain traits with the underlying functions,
but does not require that there be any relation between the
implementations of the stream function and its underlying
functions.
(SUS 2.5.1 'Interaction of File Descriptors and Standard I/O
Streams')
For the GNU C-library, the existence of such a 'relation between the
implementation of the stdio-routines' and the I/O-interfaces provided
by the kernel is documented to exist. Its existence can also
empirically be verified by looking at the source code. This does not
preclude hypothetical other implementations, where this would be
different, including hypothetical other libraries also called 'GNU
C-libary'. |
|
| |
|
| Back to top |
|
