From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 284393fe for ; Fri, 10 Jan 2020 20:25:05 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 80D32949BA; Sat, 11 Jan 2020 06:25:04 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id D148D93DA0; Sat, 11 Jan 2020 06:24:35 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="PtB2YBAm"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id D835193DA0; Sat, 11 Jan 2020 06:24:32 +1000 (AEST) Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) by minnie.tuhs.org (Postfix) with ESMTPS id 6FF0793D85 for ; Sat, 11 Jan 2020 06:24:32 +1000 (AEST) Received: by mail-vk1-f176.google.com with SMTP id w67so974755vkf.1 for ; Fri, 10 Jan 2020 12:24:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uco0Tjk8lpuB3KnJzCgSiFpcXY410rNjn4gJcPs8FGk=; b=PtB2YBAmifQSV3TQZ/9H2uKvKxl8X3nCFFS46jTr/SHcoy38eGTpFe8YarfroskaVA MmeOZ+YffuXl/IYCZ9msjqoQUVPfta+BpZEuD5anQW0RPLqvUKXUSHVuZSzs4GKpKto0 t0q6bCVdHzTY4nspYAwm1tXmT7A1u/N16AsqxJlKDguEDIW3sU3Lw8iu2Udv6BlBE75F 83CKLXfKANgZBar1phUFvlpXLPy1XeXLdDVi1O749rQ9gU/3wX82d7YLrT/M6hmJZvhC ZGKh+cL+Tfqt63uDxYW4MjKEFGzpaOUwX3MvCqV8Ni70ticlmQsubzCMZS8jit7iLbeK GfLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uco0Tjk8lpuB3KnJzCgSiFpcXY410rNjn4gJcPs8FGk=; b=Zcw997b/c6XzS0TNPGu4jYMNFIsKOLDhzPxms96nNUxfZ3ZAcGTkWj7faVJh/DgFee LA8pOXJ7I9ZFd9CvvJzuXehcTjZF/weIHd26PtzIiORS1pQNYZMgFbeJmB3+CnvtxK+i fXAT01Yakk5PvGDBh6NY+Afyj7lpj8dthnbHRgsLu7RBeuvOBfs+SHYnl3z30HUJS5NQ oL0a7yPiabZME5EH2F+ZNQEtbRsRStU3Zz7okf7b0nbn2R1UMvC2m/huM0ifsXBcpvwH 6/ypVTcN8Z6t0nA1zEYgY2U2+fCS5evyAUSXsIDycORP+rkYbStRBb/1PpOX5U67cXWd e/8g== X-Gm-Message-State: APjAAAWCrSWY0BVQxPtRUAXr2gNKmlX7GHRZBmq1dGGDd9yN1kxFV3K5 sHLaEfpSQqwq89v05ucDW4RPkH0HnfmWEiXihds= X-Google-Smtp-Source: APXvYqyELyI23rhsvQf4N6U1QNHAb/OCT1qN7GpQ00MCMvHcWijFx957kSX5Ydkw/rmauFEawzjCyyFBb5BMMzTU2wE= X-Received: by 2002:a1f:fe4e:: with SMTP id l75mr3541783vki.18.1578687871602; Fri, 10 Jan 2020 12:24:31 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ab0:3745:0:0:0:0:0 with HTTP; Fri, 10 Jan 2020 12:24:30 -0800 (PST) In-Reply-To: References: From: Paul Winalski Date: Fri, 10 Jan 2020 15:24:30 -0500 Message-ID: To: Dan Cross Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] Question about early C behavior. 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: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 1/10/20, Dan Cross wrote: > > Given the definition `int x;` (without an initializer) in a source file the > corresponding object contains `x` in a "common" section. What this means is > that, at link time, if some object file explicitly allocates an 'x' (e.g., > by specifying an initializer, so that 'x' appears in the data section for > that object file), use that; otherwise, allocate space for it at link time, > possibly in the BSS. If several source files contain such a declaration, > the linker allocates exactly one 'x' (or whatever identifier) as > appropriate. We've verified that this behavior was present as early as 6th > edition. I think the situation you describe (common sections) is how this is done in ELF. a.out and COFF, as used on Unix, don't have common sections. Instead 'int x;' (without an initializer) becomes symbol 'x' in the object file's symbol table, with both the "external" and "undefined" attribute bits set, and with the symbol's value being the size of 'x' (typically 4 bites, in your example). It is the non-zero symbol value that distinguishes common symbols from ordinary external references, e.g., 'extern int x;' (without an initializer). At link time, common symbols are handled differently from ordinary external references: [1] When the linker is searching libraries, an ordinary external reference to 'x' will cause the linker to load an object that contains an external definition for 'x'. Common symbols do not trigger the loading of an object from a library. [2] After the linker has processed all of the files and libraries on the command line, if there is an external definition for 'x', all common symbol references to 'x' are treated as ordinary external references to 'x' and resolved against the definition. If no external definition is found, the linker allocates 'x' in BSS, using the maximum allocation size seen in any common symbol references to 'x'. All common symbol references and ordinary external references to 'x' are resolved to the newly-allocated space. > The question is, what is the origin of this concept and nomenclature? > FORTRAN, of course, has "common blocks": was that an inspiration for the > name? Where did the idea for the implicit behavior come from (FORTRAN > common blocks are explicit). Yes, the concept, nomenclature, and semantics come from FORTRAN, and they were included in a.out and COFF to support FORTRAN and other languages (such as PL/I) that have COMMON block-type semantics. I don't know why 'int x;' (without an initializer) in C was implemented as a common symbol. I suspect it was done to allow C and FORTRAN object modules linked together in the same executable to share external data. -Paul W.