From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 22998 invoked from network); 25 Apr 2020 20:17:20 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with UTF8ESMTPZ; 25 Apr 2020 20:17:20 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id CD7629C8AF; Sun, 26 Apr 2020 06:17:19 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 95D3B9C733; Sun, 26 Apr 2020 06:17:04 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id B1BD09C733; Sun, 26 Apr 2020 06:17:02 +1000 (AEST) X-Greylist: delayed 593 seconds by postgrey-1.36 at minnie.tuhs.org; Sun, 26 Apr 2020 06:17:01 AEST Received: from pio-pvt-msa1.bahnhof.se (pio-pvt-msa1.bahnhof.se [79.136.2.40]) by minnie.tuhs.org (Postfix) with ESMTPS id 9050A9B962 for ; Sun, 26 Apr 2020 06:17:01 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by pio-pvt-msa1.bahnhof.se (Postfix) with ESMTP id E0A163F8D9 for ; Sat, 25 Apr 2020 22:07:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from pio-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (pio-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEwl-ecTwrpb for ; Sat, 25 Apr 2020 22:07:05 +0200 (CEST) Received: from localhost (unknown [85.24.253.39]) (Authenticated sender: mc592273) by pio-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id D07393F876 for ; Sat, 25 Apr 2020 22:07:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (Postfix) with ESMTPS id E0D112E02D2 for ; Sat, 25 Apr 2020 22:07:04 +0200 (CEST) Date: Sat, 25 Apr 2020 20:07:03 +0000 From: Michael =?utf-8?B?S2rDtnJsaW5n?= To: tuhs@minnie.tuhs.org Message-ID: <9900c104-6f80-4b35-ae53-08b95c9dfbdf@localhost> References: <20200425131112.6E54F18C0B6@mercury.lcs.mit.edu> <1587821712.2206.338.camel@mni.thm.de> <2050076633.160857.1587841270567@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2050076633.160857.1587841270567@mail.yahoo.com> Subject: Re: [TUHS] v7 K&R C X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 25 Apr 2020 19:01 +0000, from blstuart@bellsouth.net (Brian L. Stuart): > On Saturday, April 25, 2020, 09:52:45 AM EDT, Hellwig Geisse wrote: >> The subject can be looked at from another angle. Consider >> the call f(42). This might be read as first naming f (and >> thus constructing a pointer to f) and then calling the >> function which the pointer is pointing to. > > This is the way that I've taken to looking at it for the > last 10 years or so. In fact, I see it as the same thing > as an array. Specifically, I've taken to thinking of [] > as a postfix indexing operator and () as a postfix > calling operator, and the thing on the left is a pointer > in both cases. That's an interesting way of looking at it. I was thinking: couldn't we apply the same kind of reasoning to variables as well? Bear with me for a second. If we have int z = 123; then "z" is a mnenomic way of referring to an int-sized memory location, which after initialization holds the value 123. In C, we can take the address of any variable stored in memory, and we can dereference any address into memory. (How _meaningful_ especially the latter is varies, particularly on memory-protected architectures, but it's still possible.) So, is there any material difference between printf("%d", z); and printf("%d", *(&z)); If there is, then certainly GCC isn't indicating that it's there. Both print 123, and both variants compile cleanly even with -Wall -pedantic. OpenBSD clang 8.0.1 cc also gives identical output for both variants. So if "z" and "*(&z)" (take the address of z, then dereference that address, then use the value stored there) are equivalent, then in the name of consistency, why _shouldn't_ f() and (*f)() (dereference the address of f, then call) also be equivalent? After all, what is "f" here, other than a mnenomic name for a memory location? -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”