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, 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 f3317372 for ; Fri, 10 Jan 2020 21:03:04 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id D61349B86E; Sat, 11 Jan 2020 07:03:03 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 9D75C93D85; Sat, 11 Jan 2020 07:02:48 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=bsdimp-com.20150623.gappssmtp.com header.i=@bsdimp-com.20150623.gappssmtp.com header.b="G67PlJBg"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 8934A93D85; Sat, 11 Jan 2020 07:02:46 +1000 (AEST) Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by minnie.tuhs.org (Postfix) with ESMTPS id BBE3293D07 for ; Sat, 11 Jan 2020 07:02:45 +1000 (AEST) Received: by mail-qt1-f171.google.com with SMTP id w30so3174504qtd.12 for ; Fri, 10 Jan 2020 13:02:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NHE52rfe0IP0kZSSbaQypTGnb+gFXroqf/A9dr8Ss1I=; b=G67PlJBgy7jq8PRiMgIXaLNbJeJ+tsyuztHJPVHNZlsu6aF6MRsPAEVf/RLkoE4Pjw 73UArItl3qyHBXuuAWpnqI5RLyxTfkWUy0wo1fXrspoz8LPBUyRSnL9o38xXRdhvMgyG JejFVabKqtivaNSnwgQeawWy2hLjxYTY7rN8RE1bo+Zl+3OpsOTk9zsTTKEzw/9nwLAt X1mNPgVrhul4cJZJN00zxf/mPHuGQlN1klH12cDLXwI1a8FRAR4Dir1xJ7qV1lVycogn VbsmporTXDaCJD4/+sBdpJHoLgzGXhixhdP3gJ22OfBzh5ub2/tngCBOGPSLMJa+EB7K NTsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NHE52rfe0IP0kZSSbaQypTGnb+gFXroqf/A9dr8Ss1I=; b=baZ/6ketDtOVY7wAXY8GL6WQ95hg4OP+jap5oONc5NQsjIATkJCsGytBGMO/MfiFCH 46VBx0oiTK6tPCSr8QYBeuzi3KQsMF6n7nqm6BgKgXHV8si7PyqbkaBxytJxKWC4QgZb iHk/B0SwbEb15IoBOPg9KKCsnQfTmgIo+j9wZONyhvgZxI1K+ke9Q0m9Ga1uKu301q0N VRekGgqEI6v1eP5RsXAZ4WnlAPCUOcwwHentNh+EDbuJzu033TDahIcl+RLXKtAoSVku GvAq3qSjoXZE+/sD8rvfPeP8LEh20cZRbH9Q7i3fSRe7wV7kYL17O9LIM4CfiWFaoGuF dACg== X-Gm-Message-State: APjAAAX7k/v6ISzc62V1NTVpIXh5v24UyBzIa6OnXe6BKoUKkZs5Wx1W Iy6zAWrorMZTSZJEutgc8pvNH6fgdVYw7FTBgxERys1y X-Google-Smtp-Source: APXvYqxuU2jQzHErtd3lTaQsEFMpe1ETVTYcmbLYuCxSLIPyPI6DvybVCaeS39DCNmhLJ9GXS8yXVdWPAy8cBse4Mzk= X-Received: by 2002:ac8:3198:: with SMTP id h24mr365676qte.291.1578690164812; Fri, 10 Jan 2020 13:02:44 -0800 (PST) MIME-Version: 1.0 References: <20200110205525.GA1766@clarinet.employees.org> In-Reply-To: <20200110205525.GA1766@clarinet.employees.org> From: Warner Losh Date: Fri, 10 Jan 2020 14:02:33 -0700 Message-ID: To: Derek Fawcus Content-Type: multipart/alternative; boundary="0000000000007c03ce059bcf7278" 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" --0000000000007c03ce059bcf7278 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 10, 2020, 1:55 PM Derek Fawcus wrote: > On Fri, Jan 10, 2020 at 02:07:53PM -0500, Dan Cross wrote: > > > > 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). > > This behaviour differed between platforms, unix using the common approach, > and some other platforms simplying making it a (non common) symbol in the > bss. > > Having learnt C in its pre-ANSI form on unix, I then ran in to this > behaviour > on DOS C compilers. None of which (that I came across) providing the > 'common' > behaviour. > Gcc offered warnings for this behavior in the early 90s, iirc. I went through a bunch of code in that time frame to remove the assumption... Warner > --0000000000007c03ce059bcf7278 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jan 10, 2020, 1:55 PM Derek Fawcus <dfawcus+lists-tuhs@employees= .org> wrote:
On Fri, Jan 10,= 2020 at 02:07:53PM -0500, Dan Cross wrote:
>
> My colleague was particularly surprised that this seemed required: eve= n 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 tha= t if
> two source files have initializers for these variables, then one gets = a
> multiple-definition link error. The 1988 ANSI standard made this an er= ror
> (or at least undefined behavior) but the functionality persists; GCC i= s
> changing its default to prohibit it (my colleague works on clang).

This behaviour differed between platforms, unix using the common approach,<= br> and some other platforms simplying making it a (non common) symbol in the b= ss.

Having learnt C in its pre-ANSI form on unix, I then ran in to this behavio= ur
on DOS C compilers.=C2=A0 None of which (that I came across) providing the = 'common'
behaviour.

Gcc offered warnings for this behavior in the early 90s, iirc. I = went through a bunch of code in that time frame to remove the assumption...=

Warner
--0000000000007c03ce059bcf7278--