g++ fd.getline() and msvc fd.getline()??

g++ fd.getline() and msvc fd.getline()??

Post by David C. Brow » Tue, 24 Oct 2000 04:00:00



Question:  I've written a program that reads records from a text file.

sorta like thsi..

int main() {
ifstream in;

in.open(filename);
while(!in.eof()) {
        in.getline(inbuff, 199);
        cout << inbuff;
return 0;

Quote:}

Well it compiles fine, but it doesn't read from the file (300+ lines) I
get eof returned after the first
read attempt.  Is there a bug or something in fd.getline()?  I've never
used this in linux but it works
great in msvc++.  or is there a different syntax in using this
statment?  any help would be great

thanx
David

 
 
 

1. read(fd, buf, size) after shutdown(fd, SHUT_RD) implementation-defined

I notice some missing specification in the documentation on shutdown():

The Linux man page and glibc info page say that shutdown(fd, SHUT_RD)
shuts off "reception" of data on the socket. Single Unix Spec says
"disables further receive operations". That sounds like it applies to the
tcp/ip session, not to the process's ability to read() if the socket
read buffer still has data when shutdown() is called. Neither the man
pages, info pages, or SuS man page say anything about what the
semantics of read() should be after shutdown(fd, SHUT_RD) is called.

The SO_LINGER option only discusses the write() direction: "close() and
shutdown() will block until all data has been written". (I wonder how
O_NONBLOCK works with that, but that's a question for another day).

An ipc tutorial from Berkeley's CSRG, issued when 4.3 bsd was the current bsd
version, says:

  Should a user have no use for any pending data, it may perform a
  "shutdown" on the socket prior to closing it. This call is of the
  form:

      shutdown(s, how);

  where "how" is 0 if the user is no longer interested in reading
  data, 1 if no more data will be sent, or 2 if no data is to be
  sent or received.

This appears to simply assume that code is not going to call read()
on the socket after shutdown(fd, SHUT_RD), and so leaves the question
of how the kernel is to respond to such a read() call undefined.
(Joys of an ad-hoc spec defined by the code that first implemented it,
and whose later formalization failed to specify the  semantics of subsequent
file operations on the socket fd after shutdown().)

So I would merely take the position that "results of read(fd, buf, size)
after shutdown(fd, SHUT_RD) has been called are implementation-defined"
(meaning that any given kernel will do something in that situation, but
code cannot expect how one kernel reacts to read() after
shutdown(fd, SHUT_RD) to be portable to other systems or kernel
versions without some formal standard specifying those semantics).

It seems prudent to not rely on the socket's read buffer to still be available
to the process after telling the kernel that you no longer have any
interest in reading from it. Anything the kernel does with the socket's
read buffer after shutdown(fd, SHUT_RD) is unspecified and thus valid
by definition.

How quickly the kernel gets around to actually notifying the remote peer
that the socket is closed for writing is internal to the tcp/ip stack.
"Immediately" would be good, but it is not going to be seen by the reader
that called shutdown() in any case.

Mutliple reader/writer apps that share a socket should still use locks and
"open/closed for i/o flags" (that are checked once a process or thread
holds the lock) to insulate themselves from variations in
(implementation-defined) "i/o after shutdown()" behavior, imho.

Regards,

Clayton Weaver

"Everyone is ignorant, just about different things."  Will Rogers

2. smbmount & kernel upgrade

3. Is /dev/fd redundant to /proc/self/fd ?

4. Linux Web Site for Newbies

5. fd 0 == fd 1 when running under inetd?

6. probs with Tkined compilation

7. PS2 MCA -> FD MCS-350 SCSI :: Compatible with other FD cards?

8. nfs Linux->IRIX broken

9. awk question: getline with no argument

10. reading a file slooooooow with c++ getline

11. equivalent for "getline"

12. 'getline < "-" in awk script does not work!

13. ssh command fails after a getline in an awk program