Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #1196 > unrolled thread

Re: Function to determine the number of chars in a FILE buffer

Back to article view | Back to comp.unix.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Function to determine the number of chars in a FILE buffer tm <thomas.mertes@gmx.at> - 2011-08-31 23:54 -0700
    Re: Function to determine the number of chars in a FILE buffer Jasen Betts <jasen@xnet.co.nz> - 2011-09-01 11:02 +0000
      Re: Function to determine the number of chars in a FILE buffer tm <thomas.mertes@gmx.at> - 2011-09-01 05:44 -0700
    Re: Function to determine the number of chars in a FILE buffer David Schwartz <davids@webmaster.com> - 2011-09-01 04:41 -0700

#1196 — Re: Function to determine the number of chars in a FILE buffer

On 1 Sep., 00:56, James Kuyper <jameskuy...@verizon.net> wrote:
> On 08/31/2011 06:43 PM, tm wrote:
>
> > Is there a portable solution to find out how many chars are
> > buffered in FILE *aFile.
>
> There's no portable way to find out how many chars; only a portable way
> to set the number of chars: setvbuf(), ...

I am not iterested in the total size of the buffer. Instead I am
interested in the actual number of chars in the buffer. The actual
number of chars in a buffer of size 1024 can be any integer
between 0 and 1024. As I already said: This interests me for a
file in read mode and when the file is a FIFO (e.g. opened with
popen() or other code which creates a FILE * which is a FIFO).

E.g.: When my proposed function fbufsize(aFile) returns 5 reading
5 characters from aFile would just deliver the characters from the
buffer. So reading 5 characters would not block. Reading the 6th
character would request a new char from the underlying file
descriptor, so it could possibly block (when the file is a FIFO).

My proposed function inputReady() could contain something like:

  if (fbufsize(aFile) >= 1) {
    return 1;
  } else {
    /* Use code with fileno() and select() (Linux), respectively
       fileno(), fstat(), _get_osfhandle() and PeekNamedPipe()
       (Windows) to find out if reading from the underlying
       file descriptor would block. In this case return 0.
       Otherwise (reading 1 char will not block) return 1. */
  }

Without fbufsize() even setting a file to no buffering with
setvbuf() will probably not lead to a solution: An ungetc() may
have happened and there is no way to find out if the next char
read with getc() will be the one provided with ungetc(). Since
a getc() after an ungetc() will not block inputReady() should
return 1 in this case.

> > ... This interests me for a file in read
> > mode and when the file is a FIFO (opened with popen()).
>
> A fully portable C program cannot call popen() and has no way to be sure
> whether or not a stream that it opens is a FIFO.

I am already aware of that situation. :-) At least Windows and Linux
(and probably also any other UNIX look alikes) use FIFOs for files
opened with popen(). AFAIK DOS uses tempory files for popen() so my
function will not be useful for DOS. Btw.: popen() is just an
example. I am searching for a general solution for FIFOs.

> You'll get better
> answers to your questions in a newsgroup associated with the library
> that provides popen() (and select() and fileno(), and all of the other
> implementation-specific features referred to in your program).

Thank you for this suggestion. I added OS specific newsgoups.

I already have a solution for the implementation specific
part of inputReady(). Under Linux (UNIX, etc.) I use fileno() and
select(). Under Windows I use fileno(), fstat(), _get_osfhandle()
and PeekNamedPipe(). The only thing is: Everything is hampered by
the buffering imposed by FILE * files. That's the reason I used
comp.lang.c for my question.

Many thanks in advance.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [next] | [standalone]

#1197

On 2011-09-01, tm <thomas.mertes@gmx.at> wrote:

> Without fbufsize() even setting a file to no buffering with
> setvbuf() will probably not lead to a solution: An ungetc() may
> have happened and there is no way to find out if the next char
> read with getc() will be the one provided with ungetc(). Since
> a getc() after an ungetc() will not block inputReady() should
> return 1 in this case.

basically you can't do non blockin IO using the stdio library
in a way that's likely to continue to work.

try somethine else (eg: glib )

http://developer.gnome.org/glib/stable/glib-IO-Channels.html


-- 
⚂⚃ 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#1199

On 1 Sep., 13:02, Jasen Betts <ja...@xnet.co.nz> wrote:
> On 2011-09-01, tm <thomas.mer...@gmx.at> wrote:
>
> > Without fbufsize() even setting a file to no buffering with
> > setvbuf() will probably not lead to a solution: An ungetc() may
> > have happened and there is no way to find out if the next char
> > read with getc() will be the one provided with ungetc(). Since
> > a getc() after an ungetc() will not block inputReady() should
> > return 1 in this case.
>
> basically you can't do non blockin IO using the stdio library
> in a way that's likely to continue to work.
>
> try somethine else (eg: glib )
>
> http://developer.gnome.org/glib/stable/glib-IO-Channels.html

Thank you for this information.
The description of the IO Channels state that they were made to
integrate file descriptors, pipes, and sockets into the main event
loop. Since my runtime library (for Seed7) works without event loop
this might be a problem for me. The page states also that the IO
Channel support for Windows is only partially complete. This would
also be a problem for me, since I want to support Windows as well.

My runtime library (for Seed7) supports a 'file' interface together
with several implementations. One 'file' implementation is for
FILE * files and another is for sockets (there are other 'file'
implementations as well and user defined 'file' implementations
are also possible).

My intention was, to handle pipes as FILE * files. But this seems to
lead to problems, when I want to introduce the function 'inputReady'
(determine if reading is possible without blocking).

Maybe it is necessary to introduce a 'file' implementation for pipes
instead of using FILE * files for pipes.

My own pipe type would be based on file descriptors, respectively
file handles (under Windows). The question is:
Can and should this pipe type work buffered or unbuffered?

For one specific function (hasNext, which determines, if the next
character will be EOF) I need a lookahead of one character, so I
need at least a buffer of one character. A bigger buffer would save
system calls so it could increase performance. But I am not sure if
this is possible and if the effort pays off.

Concerning this (writing my own pipe functions) I have questions:
Is it possible to peek from the file descriptor of a (Unix) pipe?
Is it possible to determine how many chars can be read, from the
file descriptor of a (Unix) pipe, without blocking?

Input buffering would need the number of chars available in a pipe.
Otherwise reading could block, when it is not expected.

AFAIK the Windows function PeekNamedPipe() can provide such an
information (number of chars available). But unless both Unix and
Windows can provide such information I will not implement a
pipe type with buffering.

Many thanks in advance.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#1198

On Aug 31, 11:54 pm, tm <thomas.mer...@gmx.at> wrote:

> I am already aware of that situation. :-) At least Windows and Linux
> (and probably also any other UNIX look alikes) use FIFOs for files
> opened with popen(). AFAIK DOS uses tempory files for popen() so my
> function will not be useful for DOS. Btw.: popen() is just an
> example. I am searching for a general solution for FIFOs.

That's impossible. This operation only makes sense if FIFOs and
buffers are implemented in a particular way, which no standard
requires. If you want a portable implementation, this is the best you
can can do:

int inputReady(FILE *f) { return 0; }

If you can tell the difference between this function and your proposed
function, your code is not portable. (At least, I can't see any way a
portable program could tell the difference.)

For example, no rule prohibits an implementation from pushing a buffer
back to the FIFO and then allowing another listener connected to the
FIFO to consume it. You would need a rule prohibiting this behavior
for a portable implementation to be possible.

DS

[toc] | [prev] | [standalone]

Back to top | Article view | comp.unix.programmer

csiph-web