From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85887 invoked by alias); 17 Nov 2015 21:05:44 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 85876 invoked by uid 89); 17 Nov 2015 21:05:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 17 Nov 2015 21:05:42 +0000 Received: from vapier.lan (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 46872340821; Tue, 17 Nov 2015 21:05:40 +0000 (UTC) Date: Tue, 17 Nov 2015 21:05:00 -0000 From: Mike Frysinger To: Kevin Buettner Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] PPC sim: Don't close file descriptors 0, 1, or 2 Message-ID: <20151117210540.GM31395@vapier.lan> Mail-Followup-To: Kevin Buettner , gdb-patches@sourceware.org References: <20151116145807.4aedd84f@pinnacle.lan> <20151116235317.GF31395@vapier.lan> <20151116210533.058520d2@pinnacle.lan> <20151117054133.GI31395@vapier.lan> <20151117133154.72b61a52@pinnacle.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="B9BE8dkJ1pIKavwa" Content-Disposition: inline In-Reply-To: <20151117133154.72b61a52@pinnacle.lan> X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00355.txt.bz2 --B9BE8dkJ1pIKavwa Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1366 On 17 Nov 2015 13:31, Kevin Buettner wrote: > On Tue, 17 Nov 2015 00:41:33 -0500 Mike Frysinger wrote: > > > So sim/common is doing the same thing as my proposed patch for ppc; > > > sim/common is just using a more elegant mechanism to avoid calling > > > close() on these three file descriptors. > >=20 > > the difference is that this code sequence misbehaves after your change: > > close(1); > > write(1, "foo", 3); > > under the common sim, the write will return EBADF. > >=20 > > considering how much of common/ came from ppc/ i'm a little surprised > > virtualization of the fd table didn't. > >=20 > > it would be nice if we could at least hide these three fds (a static > > array of 3 bools maybe?), but i won't push hard for you to do that. >=20 > Do you mean an array which indicates the open / closed status of each > of stdin, stdout, and stderr? This status would then be used to > return EBADF in the right places when the descriptor is "closed". correct. maybe add a helper func like the common code does, and then have every wrapper (read, write, etc...) check that before making the actual call. i don't think we have to get fancy and preserve exact behavior since the standard does not require it; i.e. this code: close(2) int fd =3D open(...) fd would normally be 2, but since we haven't really closed it, you'd get back a higher fd. -mike --B9BE8dkJ1pIKavwa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWS5ajAAoJEEFjO5/oN/WBeysP/iiRg0f7E7OYNygnuHvavmK5 6XJQFpqGVMOLdIgHEQC6KADfXuIZXw479xc1aKLbjv5xgDrmViHhR0nnUkvs2jJ8 /TnnFB1UKe11xviL4ML3AYsfXLy1kHjWNI153+3rBy13Hee3vToL855gI3g8YafI XO5Xx6O6z1e046NX//Pdqpb5hYmeJfxKhxT+rpbIz+oA1CHUcZC10LDo0WKavaCF vndaxkI5AjCme//0peQ/zIgK9+8PhJffkHwTH1LpRsUqOZ8HSiDkgBydAALMc2fc AdrcNabwowUx0fTE2a5V44rW8MfLy0lctuElGYKaF3Dnba0H8hNC3NnqzWN76UJe jTkd9u6s+1q9uk6qRAqAcGmrXJ0lzjQNIBXsy/YAQoHoU5tLe7rvUzRuMJxrvVI1 OlHQCJ5chrJ4OHsJSCQn0ZSkzwyln8NHxcB8ObMqhdJe4gOgWWDyHZo01l7Lqkro Bi8VimfgSd2FeB7p8jCr1ox6QO3IwHtnHMvs6t9dm6nrCTKvWXaD1K6zVLo1QwPm 4fQbMqjhPLGW0M2odGnt68VADCDGmmqu8dzHC7/HsYMN6ubrZ5zW2PoXV1tiNDFO YRN3I/D2Z2WpuGHWZHC+f0hEarYJ9iBz44KAa1g18pfg6FV5+MxAd9w3yHnRXjiO uvPhWmToHf+pCmyNaKtn =5Hfk -----END PGP SIGNATURE----- --B9BE8dkJ1pIKavwa--