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.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,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 c8dcbba5 for ; Fri, 10 Jan 2020 19:09:06 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id D70C49B87A; Sat, 11 Jan 2020 05:09:04 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 15DFA93D85; Sat, 11 Jan 2020 05:08:34 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="qyk6wQN7"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id D665993D85; Sat, 11 Jan 2020 05:08:30 +1000 (AEST) Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by minnie.tuhs.org (Postfix) with ESMTPS id 7582393D07 for ; Sat, 11 Jan 2020 05:08:30 +1000 (AEST) Received: by mail-qt1-f177.google.com with SMTP id n15so2882746qtp.5 for ; Fri, 10 Jan 2020 11:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pg/tQMAhpfTJWYe0yAlBeUesGSmOIKWf1iLvzoMDExw=; b=qyk6wQN7lRoHv/mNCPIBLIn7I+vM5v+Mrj1t2XY7uymbvr9SgvaeBDR8ObkW30BJKk taVFA37+rgsbsdtzv+Gurjkasxm89UcBIvvWUUhDQKLb64FS/wprbSIt3c2Kbgm6X++o Ndu7UO48CJxOSoVx7F6oOt5/lda5LCbQQcdl8ClyWfp8pQfmeoctYNIiWqkqK+HbNyeF WdxtWPWy7HNsg+nfujYAUw6hliNJaUZhphXH9rQ5N3sTFhWukvLOhipgfh69IoojhQcB 9Rb/qqfTnrUWDkYDHwcPHj1A23RlvR1WJyBdbMjAMS1C4Yglj4Gfig6KuIjmrWZ3RBYS QOxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pg/tQMAhpfTJWYe0yAlBeUesGSmOIKWf1iLvzoMDExw=; b=HnN9OGyZSBDlrALzvjnKdTKcSkIfyEHPqZrB+kAL6CHhtpanqSdtc5wVFJHRuMK4J6 D+q1jxVqVL+KoNwkgjitnLsHcuf6URt4iCauYJ3EgjkaDLMruB0jaTWyX0z4pX4XB/l+ maj9DMkGPmTRQc7FUJ/YQTeSZ+gN9Fmawgv1skVWSw33bwGssk/aAm7t1lHQi7IYzrAH bIMNNm1JyK3gii3fg7C6gDlHSqqKrZJec597E+gRvJjucip3YCCZbVkMbtNFxWHzegwK PuUC2Ia5BXPGhXDrpXdBYv0+0xgm3Dr0E6pSmAVS9CaN8Ypta06SUV63o1jaGQiqrJmx rE1Q== X-Gm-Message-State: APjAAAU5ikpyA+fxQ/aiZMO60vRnKOSHpH+2lcjb59LpiUGu4KUZLzsZ kq1WvggH9jMZwss3ICyfDLStHvflR1M1GYxNC6WLRN/c X-Google-Smtp-Source: APXvYqwg2SWITusgmDetfsrYcAyZr9k/3elREP+7yyhOVm6QPalte/ByYj8FOG5TLd5GL33ECI6o5YoJUPVYhwGuv2U= X-Received: by 2002:aed:2ce4:: with SMTP id g91mr3809345qtd.352.1578683309335; Fri, 10 Jan 2020 11:08:29 -0800 (PST) MIME-Version: 1.0 From: Dan Cross Date: Fri, 10 Jan 2020 14:07:53 -0500 Message-ID: To: The Eunuchs Hysterical Society Content-Type: multipart/alternative; boundary="000000000000dda9d0059bcdd995" Subject: [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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000dda9d0059bcdd995 Content-Type: text/plain; charset="UTF-8" This question comes from a colleague, who works on compilers. 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. 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). My colleague was particularly surprised that this seemed required: even at this early stage, the `extern` keyword was present, so why bother with this behavior? Why not, instead, make it a link-time error? Please note that if two source files have initializers for these variables, then one gets a multiple-definition link error. The 1988 ANSI standard made this an error (or at least undefined behavior) but the functionality persists; GCC is changing its default to prohibit it (my colleague works on clang). Doug? Ken? Steve? - Dan C. --000000000000dda9d0059bcdd995 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This question comes from a colleague, who works on compile= rs.

Given the definition `int x;` (without an initialize= r) 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 th= at; otherwise, allocate space for it at link time, possibly in the BSS. If = several source files contain such a declaration, the linker allocates exact= ly one 'x' (or whatever identifier) as appropriate. We've verif= ied=C2=A0that this behavior was present as early as 6th edition.
=
The question is, what=C2=A0is the origin of this concept and nomenclatu= re? FORTRAN, of course, has "common blocks": was that an inspirat= ion for the name? Where did the idea for the implicit behavior come from (F= ORTRAN common blocks are explicit).

My colleague w= as particularly surprised that this seemed required: even at this early sta= ge, the `extern` keyword was present, so why bother with this behavior? Why= not, instead, make it a link-time error? Please note that if two source fi= les have initializers for these variables, then one gets a multiple-definit= ion link error. The 1988 ANSI standard made this an error (or at least unde= fined behavior) but the functionality persists; GCC is changing its default= to prohibit it (my colleague works on clang).

Dou= g? Ken? Steve?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C= .

--000000000000dda9d0059bcdd995--