buffering of stdio streams

[Kenneth Brody]

Jack Klein wrote:
[... Linux / fdopen() / select() / fgets() ...]

You need Neither select() nor
fdopen() are part of the C language, they are non-standard extensions
provided by your platform.

True. However, they are irrelevent to the actual question being asked,
which boils down to his last sentence:

"How can I tell if anything resides in the FILE's buffer?"

The answer to that, AFAIK, is "you can't, without getting system-specific".
Make a function, let's call it "GetFileUnreadBufferCount(FILE *f)", which
will return the number of unread bytes in the FILE's buffer. Isolate it
in a system-specific module, to make porting easier.

Then, you can make system-specific versions of this function. Check with
your compiler vendors documentation, newsgroup, or support, to find out
if there is a way to do this with your specific compiler.

(Hint: check the FILE structure definition. It's probably hidden in there.)

Note, however, that even this, by itself, won't help you if there is a
partial line in the buffer, as fgets() will still block unless the rest
of the line is on the stream, but not yet read into the buffer.

 

[CBFalconer]

# Under Linux, I'm using select() to detect when any of a collection of
# socket descriptors is ready for reading. Associated with each socket
# descriptor is a FILE pointer, obtained via fdopen(sd, "r"). When any
# socket descriptor becomes ready, I call fgets(...., fp) to read a line
# of textual input.

stdio doesn't handle more sophisticated I/O all that well. Rather than
struggle to make it work, I abandon it in favour of lower level
interfaces, like read() and write(), or more sophisticated libraries
like Tcl_Write and Tcl_Gets.

Please do not answer off-topic questions here in c.l.c. There is
(at least in theory) noone to validate and/or criticize your
replies, if they are wrong, and it only encourages people to ask
such. In addition, answers specifying such non standard things as
sockets, fdopen etc. are also off-topic. However rerouting to a
suitable newsgroup is always useful.

 

[Alan Balmer]

Oh, quick, there was a post about free iPods.
You guys better get over there and shoot 'em down quick.

That post was spam, and has already been reported as such.

So far, they haven't replied to insist that we should read and reply
to it.

 

[Chris McDonald]

Thank you to the people who kindly posted replies to my question -
in particular those highlighting that what I was trying to do was not
possible in a portable fashion.

My apologies for trying to better set the scene, and daring to use
the words Linux, socket, select(), or fdopen(), when my question only
pertained to the exact topic that I chose for my Subject: line.

_______________________________________________________________________________
Dr Chris McDonald E: (e-mail address removed)
Computer Science & Software Engineering W: http://www.csse.uwa.edu.au/~chris
The University of Western Australia, M002 T: +618 6488 2533
Crawley, Western Australia, 6009 F: +618 6488 1089

 

[CBFalconer]

.... snip ...

True. However, they are irrelevent to the actual question being
asked, which boils down to his last sentence:

"How can I tell if anything resides in the FILE's buffer?"

The answer to that, AFAIK, is "you can't, without getting system-
specific". Make a function, let's call it "GetFileUnreadBufferCount(
FILE *f)", which will return the number of unread bytes in the
FILE's buffer. Isolate it in a system-specific module, to make
porting easier.

Then, you can make system-specific versions of this function.
Check with your compiler vendors documentation, newsgroup, or
support, to find out if there is a way to do this with your
specific compiler.

(Hint: check the FILE structure definition. It's probably hidden
in there.)

Note, however, that even this, by itself, won't help you if there
is a partial line in the buffer, as fgets() will still block unless
the rest of the line is on the stream, but not yet read into the
buffer.

Again, this illustrates the dangers of answering OT questions.
For many systems, there is no internal buffer. Whether or not it
exists, the hardware may have a character (or mre) ready in such
things as UART FIFO buffers. The fact that a putative i/o buffer
is empty does not mean that there is nothing in the input stream.
Once more, the _only_ appropriate answer is to redirect to the
appropriate system specific newsgroup. Even if he specifies his
system, and you are familiar with it, he should still be
redirected so that knowledgeable people can vet any answers.

BTW, only somebody very knowledgeable should be poking about in
system headers and macros. If he is that knowledgeable, he
wouldn't be asking the question in the first place.

 

[Jack Klein]

[hopefully of wide interest, and not too OT]

.....

You need Neither select() nor
fdopen() are part of the C language, they are non-standard extensions
provided by your platform.

A tiresome response.

Yes, yours is.

*plonk*

 

[CBFalconer]

Thank you to the people who kindly posted replies to my question -
in particular those highlighting that what I was trying to do was not
possible in a portable fashion.

My apologies for trying to better set the scene, and daring to use
the words Linux, socket, select(), or fdopen(), when my question only
pertained to the exact topic that I chose for my Subject: line.

No, your problem is taking a snide and antagonistic attitude to
those who politely pointed you to suitable newsgroups and advised
you that you were off topic here. If your objective was to leave
a smelly reputation, you have succeeded.

 

[Mac]

On Fri, 06 Aug 2004 07:02:08 +0000, CBFalconer wrote:

[snip]

Interesting. An allegedly educated in the field individual is incapable
of preparing correct signatures with a proper sig marker, is incapable
of checking the usual practices on a newsgroup before butting in with
off-topic material, and then responds to polite and helpful advice about
where to get appropriate information with a snippy answer.

This all speaks very poorly of one or more of the McDonald clan, The
University of Western Australia (and its department of Computer
Science), Australians, or Western Australians. I am not sure whether
manners or education are at fault. At any rate the so-called Doctor is
definitely in the boor category.

Somehow I doubt that all Australians should be so categorized. Maybe
some will respond and better place the category limit?

Well, I'm not an Australian, or a MacDonald (nor McDonald), but I
don't think you should judge any of these superficial groups (did you
every read _Cat's Cradle_? The groups you mention are all granfalloons
;-) by the behavior of this one individual. I have personally met a fair
number of Australians, and found nothing to complain about. The people I
met were informal, friendly, helpful, and had a real can-do attitude.

As for the clan MacDonald, well, the days of clans are long gone, for all
intents and purposes. The idea that all members of the clan MacDonald
share traits in common is just silly. I think we just have one individual
here who has made a series of errors and will hopefully either conform to
the applicable rules of netiquette or just go away.

--Mac

 

[Chris McDonald]

No, your problem is taking a snide and antagonistic attitude to
those who politely pointed you to suitable newsgroups and advised
you that you were off topic here. If your objective was to leave
a smelly reputation, you have succeeded.

Without continuing the muckraking, my concern is that my serious and
sensible question was immediately treated as if it was asked by someone
having no clue. As with many quite reasonable questions asked by other
individuals seeking help via this newsgroup, a number of keywords in
a question, like a red flag to a bull, trigger an immediate response
directing the question to another newsgroup.

Many of us who seek help via this newsgroup, are tired of these polite,
yet trite, responses. Like discussions in most other less technical
newsgroups, any comment on our dissatisfaction with these responses
quickly degenerates into character attack or, for some reason, on a whole
country, state, university, or a person's long standing qualifications.
It appears that all is fair game.

I asked a question about the behaviour of the buffering of stdio
streams. I tried to set the scene as to how my data arrived in the buffer.
Anyone making a resonable effort to comprehend my question, saw that the
issue was independent of operating systems and other off-topic areas.
At least 2 responders did not find the question off-topic.

We all agree that the FAQ is very good, meeting many needs. However, it
doesn't hold an answer to my question - certainly not one I could find.
All that says is that my question is not Frequently Asked. And yet
the response of one individual was instantly that I should lurk long in
this newsgroup, read the FAQ, and go back to news.admin.newbies. Well,
I had read the FAQ (section 12 on stdio anyway, and Phil Plauger's "The
Standard C Library"), I've been reading USENet since 1984, and c.l.c.,
for as long as my University has been receiving it.

Few (unfortunately) will have followed this thread to its end (I hope),
but the hundreds of us legitimate legitimate that have serious, relevant
questions to ask, would appreciate not being continually shot down by
the handful of individuals that treat this shared newsgroup as their own.

I welcome any serious discussion; just leave my country, state,
university, and education out of it.

_______________________________________________________________________________
Dr Chris McDonald E: (e-mail address removed)
Computer Science & Software Engineering W: http://www.csse.uwa.edu.au/~chris
The University of Western Australia, M002 T: +618 6488 2533
Crawley, Western Australia, 6009 F: +618 6488 1089

 

[SM Ryan]

#
# >Chris McDonald wrote:
# >> .....
# >>
# >> My apologies for trying to better set the scene, and daring to use
# >> the words Linux, socket, select(), or fdopen(), when my question only
# >> pertained to the exact topic that I chose for my Subject: line.
#
# >No, your problem is taking a snide and antagonistic attitude to
# >those who politely pointed you to suitable newsgroups and advised
# >you that you were off topic here. If your objective was to leave
# >a smelly reputation, you have succeeded.

'Assholes do vex me.'
- Robin Williams

# Without continuing the muckraking, my concern is that my serious and
# sensible question was immediately treated as if it was asked by someone
# having no clue. As with many quite reasonable questions asked by other
# individuals seeking help via this newsgroup, a number of keywords in
# a question, like a red flag to a bull, trigger an immediate response
# directing the question to another newsgroup.

You're dealing with an obnoxious clique which tries like hell to moderate
an unmoderated newsgroup. This way they can post their off topic messages
unimpeded. Contrary to their insistence, this is group is not strictly
about ANS C; this whinging about off-topic posts started about seven years
ago and destroyed a previously valuable resource about C programming.

 

[Dave]

Please do not answer off-topic questions here in c.l.c. There is
(at least in theory) noone to validate and/or criticize your
replies, if they are wrong, and it only encourages people to ask
such. In addition, answers specifying such non standard things as
sockets, fdopen etc. are also off-topic. However rerouting to a
suitable newsgroup is always useful.

So is remembering to take your medication.

Dave