bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bugs #9667] [MinGW] GSFileHandle does not descriptor associated to sock


From: Willem Rein Oudshoorn
Subject: [bugs #9667] [MinGW] GSFileHandle does not descriptor associated to socket
Date: Wed, 28 Jul 2004 07:41:03 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030718

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #9667] Latest Modifications:

Changes by: 
                Willem Rein Oudshoorn <woudshoo@xs4all.nl>
'Date: 
                Wed 07/28/2004 at 11:37 (Europe/Amsterdam)

            What     | Removed                   | Added
---------------------------------------------------------------------------
         Assigned to | None                      | wim
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
Commited fix to CVS.






/**************************************************************************/
[bugs #9667] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=9667>
Project: GNUstep
Submitted by: Willem Rein Oudshoorn
On: Fri 07/16/2004 at 14:03

Category:  Base/Foundation
Severity:  3 - Ordinary
Item Group:  Bug
Resolution:  None
Assigned to:  wim
Status:  Closed


Summary:  [MinGW] GSFileHandle does not descriptor associated to socket

Original Submission:  If GSFileHandle is actually a socket the MinGW specific
code for closing the socket is, as far as I can see, not correct.  

It does close the socket, but not the C-Runtime file descriptor
created with _open_osfhandle ( )

The fact that this behaviour is wrong can be deomonstrated
with the attached program.  This program will repeatedly
create and destroy a GSFileHandle object and after about
2045 iterations it will fail.  

I will commit the attached patch if nobody objects.

The patch does the following:

in -[GSFileHandle gcFinalize] and in -[GSFileHandle closeFile]
it will, after calling closesocket also call close on
the filedescriptionr.

Also, in closeFile I changed the check on
"isStandardFile" to using "isSocket", because
it used to decide if we should close a socket. 
However I am not sure if this is right, so if there
is a reason that "isStandardFile" is used, please say so.
  
Wim Oudshoorn

Follow-up Comments
------------------


-------------------------------------------------------
Date: Wed 07/28/2004 at 11:37       By: wim
Commited fix to CVS.

-------------------------------------------------------
Date: Fri 07/16/2004 at 14:04       By: wim
And here is the patch






File Attachments
-------------------

-------------------------------------------------------
Date: Fri 07/16/2004 at 14:04  Name: gsfilehandle.patch  Size: 806B   By: wim
The patch for GSFileHandle.m
http://savannah.gnu.org/bugs/download.php?item_id=9667&amp;item_file_id=1499

-------------------------------------------------------
Date: Fri 07/16/2004 at 14:03  Name: GSFileHandleTest.tar  Size: 10KB   By: wim
Program which demonstrates the problem
http://savannah.gnu.org/bugs/download.php?item_id=9667&amp;item_file_id=1498






For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=9667>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/







reply via email to

[Prev in Thread] Current Thread [Next in Thread]