From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19148 invoked from network); 31 Mar 2023 02:48:55 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 31 Mar 2023 02:48:55 -0000 Received: (qmail 15811 invoked by uid 550); 31 Mar 2023 02:48:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32461 invoked from network); 31 Mar 2023 02:18:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1680229110; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=1yxH4BXYQE7RkPxYhP2MT1kCQA+FMSy+6HIlAycnTik=; b=oRkMm9MZnAMUJ7nopX/B7ixWwq26H5LgoMZcAcIZMKt8z0x9wdgBhnh+XrOKElfE sBnUEBmjf1tENTuW985yoyaAFbxAtTthpnYr363xr2Kg6TDgEZRC6zCPBhFAn5U4Gk8 S9mWUpzutoy8bZXUCCvzeQY78gsWF9AdTf3ztn9nm7SXCfbgREvkeKUE/KdgXK6Ng4T qXzXx75mqtLLklS212mjbqXJLCzm8XwyLR/cbvtt7xLJGfVe+nPKCtJn0veh75dyi+1 nWHJtn87X6flvrFL4mM0EM7l1hMa408j2NTmmAqTPl2VQB+JOYIQnMOEwYXvvPmJOgk 0nk62umRWA== Date: Fri, 31 Mar 2023 04:18:30 +0200 (CEST) From: shawnlandden@tutanota.com To: Musl Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_359639_472131472.1680229110217" Subject: [musl] Running FDPIC binaries in the same memory space as the caller. ------=_Part_359639_472131472.1680229110217 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I am not really in the mood to sell all the benifits of doing this---but dpkg felt obligated to support all the nonstandard comoressors APIs of compressors that all supported the standard gzip interface, because of a percieved slowness of the 386's MMU. Now that we have FDPIC binaries that run both with and without a MMU this is no longer an excuse to be weird. But I do think it would be easiest to do this, without any changes to the compilers (or god-forbid the c standard), by making stdin stdout and stderr (always been 0 1 and 2) stored in thread-local storage. But supporting that instead of just 0 1 and 2 would only be necessary for using the c abi (which is not UNIX!) at the same time as the shell api. Otherwise Linux can handle it. Sorry for not selling this like soap, Shawn Paul Landden ------=_Part_359639_472131472.1680229110217 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I am not really in the mood to sell all the benifits of d= oing this---but dpkg felt obligated to support all the nonstandard comoress= ors APIs of compressors that all supported the standard gzip interface, bec= ause of a percieved slowness of the 386's MMU. Now that we have FDPIC binar= ies that run both with and without a MMU this is no longer an excuse to be = weird.

But I do thin= k it would be easiest to do this, without any changes to the compilers (or = god-forbid the c standard), by making stdin stdout and stderr (always been = 0 1 and 2) stored in thread-local storage.

<= /div>

But supporting that instead of just 0 1 and 2 would = only be necessary for using the c abi (which is not UNIX!) at the same time= as the shell api. Otherwise Linux can handle it.

Sorry for not selling this like soap,

Shawn Paul Landden

<= /body> ------=_Part_359639_472131472.1680229110217--