[Bug libgcj/27219] New: bogus-looking code in natPlainSocketImplPosix.cc

[Bug libgcj/27219] New: bogus-looking code in natPlainSocketImplPosix.cc

[tromey at gcc dot gnu dot org]

I'm looking at natPlainSocketImplPosix.cc:write_helper().

* Why not throw an exception on ENOTCONN or ECONNRESET?
  We could at least use a better comment here.

* This code doesn't handle EINTR properly.

The recv code also doesn't seem to handle EINTR properly.


-- 
           Summary: bogus-looking code in natPlainSocketImplPosix.cc
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tromey at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27219

[Bug libgcj/27219] bogus-looking code in natPlainSocketImplPosix.cc

[tromey at gcc dot gnu dot org]

------- Comment #1 from tromey at gcc dot gnu dot org  2006-04-20 15:54 -------
You can see it by compiling this short example
program with 'g++ --syntax-only':

#include <gcj/cni.h>
#include <jni.h>


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-04-20 15:54:03
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27219

[Bug libgcj/27219] bogus-looking code in natPlainSocketImplPosix.cc

[tromey at gcc dot gnu dot org]

------- Comment #2 from tromey at gcc dot gnu dot org  2006-04-20 16:06 -------
Ignore that, I appended to the wrong report.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27219

[Bug libgcj/27219] bogus-looking code in natPlainSocketImplPosix.cc

[mckinlay at redhat dot com]

------- Comment #3 from mckinlay at redhat dot com  2006-04-20 21:45 -------
It does look like these should be made robust in the case of an EINTR which was
caused by a signal other than the interrupt signal.

As for ignoring ENOTCONN and ECONNRESET, I have a vague recollection that there
is a good reason for doing this (compatibility with Sun?) - but this probably
does warrant more testing/investigation, and a better comment.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27219