[SOLVED] stdin ioctl simply put

multiplex22 · 01-12-2015, 12:03 PM

Im trying to read stdin with read and it is a success. I found I could use ioctl to flush stdin (STDIN_FILENO) to an even greater surprise.

Big question: can I determine the file size/length of stdin?

Ive tried lstat w ttyname even, but returns 0 bytes though the termios buffer is not depleted yet. Tried feof too for comparisons, but itll stay in an infinite loop. Using lseek is also bad.

ioctl seems it, but for sizing?

NevemTeve · 01-12-2015, 12:18 PM

> can I determine the file size/length of stdin?

If that were possible, what would you expect to get as a result? The dimensions of the terminal(window)?

multiplex22 · 01-12-2015, 12:28 PM

Not at all. The length of remaining characters unread. TIOCGWINSZ would only return the rows and columns. And I already understand how to wait for a read signal.

It has an unread filled buffer of oodles of bytes somewhere. I simply want to allocate a proper string to receive precise data.

NevemTeve · 01-12-2015, 12:41 PM

I don't think that would be either possible or useful. Just read diligently until you get an EWOULDBLOCK. (Or use select/poll/SIGIO).
The size of the buffer can be dynamically increased, details are described here: http://www.joelonsoftware.com/articl...000000319.html

rtmistler · 01-12-2015, 02:09 PM

I don't think you can easily, if not at all. You can either read what's in stdin now, or not. You can limit your read in byte count, but that doesn't respond by telling you how much is in there in the first place.

When I say "easily" I don't know but I bet if you browse down the /proc file system for a given terminal or other process, you may be able to discern the count of bytes in stdin, but you know ... you've then opened and viewed yet another file when all you needed to do was to read stdin.

Note also that you can use select() to determine if there is anything in that file descriptor in the first place if your intentions are to determine if there is any data.

jpollard · 01-12-2015, 03:04 PM

Are you looking for the ioctl FIONREAD? (man ioctl_list) which returns the number of bytes that can be read from a descriptor?

multiplex22 · 01-15-2015, 11:29 AM

Thanks and very good replies. This is mostly what i want to confirm. However the kernel stores the data it is probably a static buffer somewhere. Yet another flaw you encounter with strict text data systems. Strict meaning "protected".

NevemTeve · 01-15-2015, 11:57 AM

Could you please explain what flaw you found?

multiplex22 · 01-15-2015, 12:10 PM

Quote:

Originally Posted by NevemTeve

Could you please explain what flaw you found?

Simple. I need human text data from the proc folders versus the old way of asm interrupt calls to fetch fast binary data. I find this inefficient but I will suffice with free.

NevemTeve · 01-15-2015, 12:41 PM

I guess you are trying to reimplement utility 'ps'...

SoftSprocket · 01-15-2015, 12:59 PM

Quote:

Originally Posted by multiplex22

Thanks and very good replies. This is mostly what i want to confirm. However the kernel stores the data it is probably a static buffer somewhere. Yet another flaw you encounter with strict text data systems. Strict meaning "protected".

If by data you mean the pipe buffer that feeds libc's stdin buffer - it's a circular buffer. It's not a static buffer.

You can mess with setvbuf within a program (it doesn't affect the buffer libc uses for stdin in other programs) and doing so gives some interesting results.

Code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define MAX_BUF 4096

int main () {
        char buf[MAX_BUF];

        if (setvbuf (stdin, buf, _IOLBF, MAX_BUF) != 0) {
                 perror ("setvbuf");
                 exit (EXIT_FAILURE);
        }

        printf ("In buffer - %ld\n", strlen (buf));

        int c;
        int read = 0;

        while ((c = fgetc (stdin)) != EOF) {
                read += printf ("%c", c);
                printf ("- %ld -", strlen (buf) - read);
        }       

        printf ("\n");

        printf ("In buffer %ld\n", strlen (buf));

        return 0;
}

Code:

$ gcc -Wall -std=c11 rebufio.c -o rebufio
$ echo "Hello World" | ./rebufio
In buffer - 0
H- 11 -e- 10 -l- 9 -l- 8 -o- 7 - - 6 -W- 5 -o- 4 -r- 3 -l- 2 -d- 1 -
- 0 -
In buffer 12

I don't know if this says anything about libc's stdin buffer - but I find two things notable.

First there is nothing in the buffer until fgetc is called. Second, string size in the buffer doesn't change as it's read which means there is an internal pointer being kept. This makes sense when you consider a function such as ungetc.

jpollard · 01-15-2015, 03:25 PM

Quote:

Originally Posted by multiplex22

Simple. I need human text data from the proc folders versus the old way of asm interrupt calls to fetch fast binary data. I find this inefficient but I will suffice with free.

Umm.... efficiency isn't the issue. None of the data from /proc can be synchronized, thus it is irrelevant about any "efficiency" involved. What counted was standardization of access to the data. Using open/close/read/write eliminates all the unique ioctl function parameters that do the same thing. This eliminated a lot of code (the ioctls) in favor of other already existing data retrieval (file search, open/close/read/write).

multiplex22 · 01-16-2015, 12:40 PM

Quote:

Originally Posted by jpollard

Are you looking for the ioctl FIONREAD? (man ioctl_list) which returns the number of bytes that can be read from a descriptor?

Perfect

NevemTeve · 01-16-2015, 01:43 PM

Not really. The amount can change even between ioctl(FIONREAD) and read/recv (remember: time-sharing, interrupts, asynchron events and stuff like those). Also it can change during read/recv.

Normally you use some message delimiter (eg CR and/or LF as end-of-line), or a length-field (eg HTTP:Content-Length).

jpollard · 01-16-2015, 04:23 PM

Quote:

Originally Posted by NevemTeve

Not really. The amount can change even between ioctl(FIONREAD) and read/recv (remember: time-sharing, interrupts, asynchron events and stuff like those). Also it can change during read/recv.

Actually, the only thing that can happen is that it gets larger.

Quote:

Normally you use some message delimiter (eg CR and/or LF as end-of-line), or a length-field (eg HTTP:Content-Length).

FIONREAD IS the length. You cannot trust "length-field" within the packet, nor can you trust delimiters... that is an old security failure as the length within the packet can be invalid, and delimiters could be missing. You can only test for "sanity" by verifying that it is less than the actual length of the message...

The only way to get that is by FIONREAD, or requesting exactly the messege length expected, and expect to block if it is short, or handling EWOULDBLOCK errors.