From owner-freebsd-arch@freebsd.org Tue Apr 24 23:14:11 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9139DFB60F6 for ; Tue, 24 Apr 2018 23:14:11 +0000 (UTC) (envelope-from enquiry@evlink.com.my) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01hn0209.outbound.protection.outlook.com [104.47.126.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 705BF75B22 for ; Tue, 24 Apr 2018 23:14:10 +0000 (UTC) (envelope-from enquiry@evlink.com.my) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evlinkmy.onmicrosoft.com; s=selector1-evlink-com-my; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6qxCKjfLyTclgwtd5qv+rVXfro8etsgylxo4rldD6Lk=; b=GJnpF+SWafYQ1mL2Uz5jxjCFx/4ByKUd9J5g0nq6z0ex5+e6KCxAbqA2Wu/XgOg+UkUbUdvo3wEENh9SQqiZPUByXZWyQpwNknk7sUok29O9tzg6cIJtjQNyGTvfS7IsUvh1YhI0eFyfCF/RsqlZK9zp76XFxcd2psfuYw1zHeg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=enquiry@evlink.com.my; Received: from evlink.com.my (157.119.122.217) by KL1PR06MB1238.apcprd06.prod.outlook.com (2a01:111:e400:7820::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Tue, 24 Apr 2018 23:14:07 +0000 From: Customers Service To: freebsd-arch@freebsd.org Subject: Bank Advice Date: 24 Apr 2018 16:14:19 -0700 Message-ID: <20180424161419.465CA4879F75DCD6@evlink.com.my> X-Originating-IP: [157.119.122.217] X-ClientProxiedBy: SG2PR04CA0156.apcprd04.prod.outlook.com (2603:1096:4::18) To KL1PR06MB1238.apcprd06.prod.outlook.com (2a01:111:e400:7820::20) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4534165)(7022125)(4603075)(9333020)(4627221)(201702281549075)(7048125)(7026125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:KL1PR06MB1238; X-Microsoft-Exchange-Diagnostics: 1; KL1PR06MB1238; 3:6FJ8bd9JCm+5zwgAv7UELthcthUkucAwg0a+ZDADQKf4S4RJLmabjgUYRWTOnrPb6uUclZwRL02r1sqR1SeSA9ERa6vxcZqv+rPfB35nT8ByiKwXW6wZNkEsmcoJXIbHQqMQsSpEuMQrmNTqonH6mEctwcwEY0XGbsNcXh08OaTySy7UMyXWZgM/DevDVpbbPydxfFo+NahLsyw+zVJGBPqTUxJYY0z7XfSoiTGZ5VLDg2uMSn6ic+Spk4d/zTp3; 25:WuO7+wZwq70Tp1vDYdrZc5IwwqxNgGdBCbQKTzEiBBAUTC596fjVJdm0KVJ1Uwg1A0lzr3VCGXKyB1NpaYEoa5GNPJHhbmPq1z60+ui6FJfEIWKiIBcKs/ogbUwOQWgo4OkzKIW7QAnOm9P1CjZKx47bjshr+g8Ot0NMGlSkSmN/VphzJ7xYzyRdcf+rv1Gn7wNzLRdWAPpsPJL4NFS6+x63ctlDn6FqlmQwiJDvRa8YArvqCmeDm2u2D1AAVA+LjIruT9WhcUCJ31eDY0JuRNJnECF3Xn19wEDqi4o3JHLjQ07SU9WlmUeRiRKzfPYoZ8crE4jH7ArSLtA7iaxZ1uExFhA5Ukvgyz9kYZRdpyo=; 31:hfWg+DJH2uO+2G7/cacpQglTWV1bEH5XjjZNdl17BVjxnNXq9L5wTcf+rN4RMYr9p4W27YJ4h6Pp8k90vn5gs6kZkchq+cuSDQpcClEmYHrMnr7hq8W7KG8e/P5AJO6q+/7WeX4j0nB/kdi1n/GQmfGz4YsGj0bfUJ0vuTzNFm0f/GrbEMo9fvm7NFDCcvzOtvyWBwQp22KqcUiqkGqlyVG8tgwofb/M+GJrzSuHGMU= X-MS-TrafficTypeDiagnostic: KL1PR06MB1238: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(73312121905874)(211936372134217); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231232)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(20161123564045)(20161123558120)(2016111802025)(20161123560045)(20161123562045)(6043046)(6072148)(201708071742011); SRVR:KL1PR06MB1238; BCL:0; PCL:0; RULEID:; SRVR:KL1PR06MB1238; X-Microsoft-Exchange-Diagnostics: 1; KL1PR06MB1238; 4:S/Vsqap69qVYiHZn7GB2ZlCrOYjNbK2PSGSiFOyg2y7ziyvDyeFl5A0ydDzEo5mvKzFBZINy1mPel9A5dHi5QL5yA1mbe4tq3PgapT4KbhBMTYe6NQDglcjtc9yoyMsEWa9NKwaTNC9Cw43BG24xOcjSK6We7wR1utBZY0Q/SPbKP7BEEuPhow3aK2cuAgramtRUE/KyOPUGiC/F0wQ+qkYgI7n/kccYaQlQwExOEMhe9KVh0gxejsM6BbFmeMwggPrUMa0uth302ELEgqtceMu2HZWnvCgO7/c+HeqEDIdCcamQ04ZhW7DAx7t6OOA8gRO+PrrWohjeYubBRZGfwzSoH15QZjtCkSoR7qJenGU= X-Forefront-PRVS: 0652EA5565 X-Forefront-Antispam-Report: SFV:SPM; SFS:(10009020)(7966004)(376002)(346002)(396003)(39380400002)(39850400004)(366004)(199004)(189003)(413944005)(16799955002)(36756003)(53416004)(50466002)(508600001)(106356001)(23846002)(105586002)(33656002)(74482002)(2351001)(69596002)(54836003)(25786009)(6116002)(1076002)(97876018)(68736007)(347745004)(606006)(6916009)(23756003)(3846002)(5890100001)(2361001)(2906002)(15650500001)(55046002)(186003)(16526019)(28505004)(486006)(476003)(2616005)(956004)(4743002)(386003)(52116002)(5660300001)(7116003)(7696005)(103936005)(26005)(59450400001)(8676002)(6666003)(316002)(236005)(86362001)(81156014)(81166006)(3480700004)(6306002)(8936002)(8746002)(66066001)(575854001)(8266002)(53936002)(7736002)(55016002)(97736004)(570100007); DIR:OUT; SFP:1501; SCL:5; SRVR:KL1PR06MB1238; H:evlink.com.my; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; Received-SPF: None (protection.outlook.com: evlink.com.my does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; KL1PR06MB1238; 23:feai5tt6D/TFAop6oUnuuAetiT0ojERBb5k6YKV?= =?iso-8859-1?Q?alykkWEVYdaAEa70/lbyuzAy8XNax/NIGGeRfbQj8NsCWeYWrj3NM2IR3T?= =?iso-8859-1?Q?+zuj3uJ6AUrFXbsxSoEuTlgkkY0+HvphyL626enj0/asrifHVCf7BRsF0Y?= =?iso-8859-1?Q?sZwiHk1xBWYpvu8IFC0yAikon+OkSnrYCjuLaGn6/fkrBVa6l2Rp/Em0lk?= =?iso-8859-1?Q?pgY2Jw1EekkbihpnxK+OeFNdQulXNJgnT1MgTkJ+hKwoqtAoRf0UsHRSrx?= =?iso-8859-1?Q?iTlwUj5q7I+DmhOT0pKsXbh4N7jlVM5DqIJOpbSgBbD7oYlwu68BYrN7J6?= =?iso-8859-1?Q?TRemQDbXkClKL0F9JXp7XWAUAUtnPRbJaq8iwqi0N5wcNfOqHcgmr8pBQO?= =?iso-8859-1?Q?DjDIXH8/+UXnvO6Um+bQ1kVMiTE3s1QGce3ECJCtYHHTF4tS1yvvbOKKPb?= =?iso-8859-1?Q?GQpCjYSleh3y0lvjtZ9pHwUJ02ZVK5f2dJL0fUG5nwV0X3tW9dNn/Sd96u?= =?iso-8859-1?Q?vVRxPW5FFeYoPPgoE6DW/LZKAG6IUkpiNiKPlccAFWpyL0NXsbPE5Kck9p?= =?iso-8859-1?Q?y8zMHc4L9H9nDpp6FlzXvn4Avo+ADLhBNakxDk3SB9gLZvoouxC9ew76di?= =?iso-8859-1?Q?D4WRsyvPI0npyIfETKN3cB3JQ0zLYgSVy6zK1fyHugrEdH/ko30A9d3gyI?= =?iso-8859-1?Q?tllYj7vs5Y1IIT7FsMQyhLsZCMkJKKvBATnEvJ5Mm2gScLVTp266tMS0cU?= =?iso-8859-1?Q?b87WtE0nhOh6NYHRdsaaqjF5iNcYgk5ck+G838b9va4AlaFO1EmqlOrwkO?= =?iso-8859-1?Q?0V2IB9hqMGs6/YiqPhE0KDCYnq40vxD2zBiwaxIo+Wn5+xs0S04Qw5UHvF?= =?iso-8859-1?Q?+ntFfwRR/bbefD7vJs0qeHxk1WK7RtwmAbLxzzXV58IGgdxC0VZS2UmAY+?= =?iso-8859-1?Q?O3Vv1ZeTfL9dXkkOAryQxfjDCD/qRXzt9tmCQzvX3TLS+QRyeqLpQWerk/?= =?iso-8859-1?Q?S/v7oNU/H3PjNlT9IyIGwsasbDW/Jm3uTF4o4Y2GpFuTdyagvUYQE/dU0f?= =?iso-8859-1?Q?fM5oSPKhdJoO8MaYKVZH7rMbY+kqskP9/pOFAsPHNpbvQ5P2+nfDZjT6A3?= =?iso-8859-1?Q?i2qtKQG8aoYiUE3trcKOujVjNBTeIy+NcGETtcSaoNT/NIr90nYGDUW8HD?= =?iso-8859-1?Q?7fb/QWkdhsvqMcVSatElvaQEkWxVMNreb1ZC0BGLAcyOz7qOWnbQeONBZP?= =?iso-8859-1?Q?cKwYhrwKmO7TZZX5rlvs7XrJIMdIYjHJRN188qFfHY6kAuqBlglcPJdjbN?= =?iso-8859-1?Q?Q7pKTlCI/Vo6nJgn/jM1Vm7i73czQVNdD5x9xYOtg0VHzuoRvf4g+FkP61?= =?iso-8859-1?Q?JfzjnYgEtBXxsCgunNjU6GxobYyaK4qbg8oJvNHWSaZr/UOekDWSKlG+7h?= =?iso-8859-1?Q?kaH/91KFD3yeVCiW4Vrnm4cxtkTlq2P+rW6vNA5bb36dSo+TvqEHLCneo0?= =?iso-8859-1?Q?yjlJ+3gM5fbLioFWPwip6ni8/M8flVGUX9Hi7hJKdyawYPAvd7JYGfVIrY?= =?iso-8859-1?Q?WI0h8U7WxwgIqhxP8WbD8c2Qf5xWUfPUsb6dDSw/wjIbbJxxSB3Z9N0Me1?= =?iso-8859-1?Q?cnK1TkuxCWfTEe7KlWH47nHdHVDDM/hIO7/bt0Kw4jsQAAG5cM6Y2SpOET?= =?iso-8859-1?Q?ysrYkq6wuyiityZIoGFkRxOHpRLqRq+7jXD4K0rpij9fyMv9YR4ih2VwRY?= =?iso-8859-1?Q?c?= X-Microsoft-Antispam-Message-Info: M/ALiL1uRWfBD7dePiToRWgJNttXrtDLV6k0Pvn51Q8mVyd5roux3JsngmtJ1oez7yO9CKGa7zDqhHpYO75Dxp+zpx9MiWVShIscPviAr6d8UEW/WjmPX4mbNCXr2jezAQxp5DLmxsICoVuKeQewokxdyrEjb6bjVOFNseCsLvPsN4qVXRgzc9TxAnGanElh79YyhxUyd23GdCFCg/0zMoOt1V7JVETpMwg5ipp5fAETUlpsgLERbd7b848S387+Ynynq2bJgAxIq6AhGA7+KcO141ptarTlrbSXAW6OsGZ/q5XnGnhAcNjuTHE5Z2cXprGTcJPJkIu5CSqbBsnLuGcbeuxnlIwo7mfRXOsKCoW3Pc3JF1+RBLAdP9cvhj8IDG8XjFA2xtBmvkMJY1+080QSNmApv9lQMJzIYr842cfhNNuel/Cx769IL41/x6A+QSsH+HWmeIR/RdsclTYGj6xigiDct7e9ObPTjmTSq5UsXas7SqlalQJB+m6Uxyybf/DyyKcIE4AOFmvXYTnFujAezBRlaD8Lz09jPdUnFx2Hdjtw05pYdzMc4qgHB2B3PUtx7G8aR2jz68nthuzRpMKrs6RsDh6JENkLvRA6ztag7uMiDbG5mhLJNh6e6RO6CvcO1HnZE+NlhvRux5JrOg== X-Microsoft-Exchange-Diagnostics: 1; KL1PR06MB1238; 6:p6G+KCXouKQ59Pj9ZUeq6puIT59MMFPzd+taDrWHi4Kw9pSZuvTolCeXXgWH01uG/nhjD7xAZyYcdNa1xrhAO80gYwzxCoZA/f5eXT0qHVdCBu5ceHkzEDAhwVXuILZF2Qx1R63x5+SZKJm8OUS9YuVrhxrmLu+fxPvkt+cCpbtBZpxDplFPOnBUgKsqyAuvXaO9c9KC6m+/EO3p5hzQCvzA+mIBEnkY0w1LDrib/Bd2AlA5I4VBYvYOxQl1H1LCpfbig3hogf45D7tma8wnjR4/dV2zEtP5J4vesnZJHZ2oT01ee5Lp6w5klzR7BMz/8mDGJiykQ+HIq0OBxT6hUtir0++ulcwo7QXhYnp2MKVb+J4ugirTIYKDxJqUVKllRJc8ptjsyEKG950+MBhHvtRYbnCiAJf5xGqsQjdmZTPefl5XkAWaAH3jC75qZ+IClVEQCMCtPP1bjRf2u0ye4xvolSKbfnF1QvyD81v6mj9R9YhvekoR/Q4pch2AAM1J5faALXGADATmYepDbPRb7g==; 5:D3o7mxmSJXSUdXIsnItMjwbIT1pzlrkmanvfiwUN7vo4pfVrz0lOVSkExO4Y9PFeFkYoW+zqIGI5q8aZKjZYOYJZdfRPl6IKdpjT50hY4IoNZrp2oni1BtDDAb0m8U4bamRrHojXEe0VzYJLbVFeU5iAYyJRrplXVz902G38R2A=; 24:4CC8+46ySF79KFUxnIfySiJLpzJoO6pRR+Cl4ReMJ0IKugSnOM4AL9PfYqoE0jjDPFu/NMWWE30KBCPsx414+Q== SpamDiagnosticOutput: 1:22 X-Microsoft-Exchange-Diagnostics: 1; KL1PR06MB1238; 7:rTaBykTQiIA58MhuZ0+Uzsie+c0ATn/E7/bdkSPnhKX/GxDiVtjMe3qXg34J7vXQX2Ehdwr4dTgsB8UzftHTkpRkBsrIVhD3S2wR2WDHz00RP9ucTwYMH01KhsRVAUJySjp0i2FP/RXQPSFDGwOt2e1s6zhaUrOMExMPDyamo0PrG6EsjIsUDNktznGWkKLblIKb2tBNwslrRH5SrDilW1xwAOmPWKd22WrHSSs2uqky+mHzv9eF/oleRzl4TlA4 X-MS-Office365-Filtering-Correlation-Id: 429ec0d0-7f48-4dcf-d339-08d5aa39146b X-OriginatorOrg: evlink.com.my X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2018 23:14:07.2761 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 429ec0d0-7f48-4dcf-d339-08d5aa39146b X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: c6337ecd-1372-4c03-ba9a-e9fa77944c7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1PR06MB1238 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 23:14:11 -0000 From owner-freebsd-arch@freebsd.org Fri Apr 27 22:19:13 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA09CFB31DE for ; Fri, 27 Apr 2018 22:19:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6BCEF6B823 for ; Fri, 27 Apr 2018 22:19:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2A38AFB31D9; Fri, 27 Apr 2018 22:19:13 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17F3AFB31D8 for ; Fri, 27 Apr 2018 22:19:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2C5D6B807 for ; Fri, 27 Apr 2018 22:19:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id A0B9C91D9 for ; Fri, 27 Apr 2018 22:19:12 +0000 (UTC) (envelope-from jhb@freebsd.org) From: John Baldwin To: arch@freebsd.org Subject: LIBC_SCCS Date: Fri, 27 Apr 2018 15:19:06 -0700 Message-ID: <1711113.VelFtdTVS7@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 22:19:14 -0000 I suspect no one cares, but for whatever reason our current handling of the LIBC_SCCS macro in some of our libraries annoys me. In theory it seems like LIBC_SCCS's purpose is to control whether or not old SCCS IDs from Berkeley are included in libc's sources when libc is built. (Similar to how macros control the behavior of __FBSDID().) However, we use an odd construct in the tree. First, we define LIBC_SCCS by default in the CFLAGS of various libraries (libkvm, libutil, libthr, libc, etc.) which in theory would enable the IDs, but then we explicitly wrap them in #if 0, e.g.: #if defined(LIBC_SCCS) && !defined(lint) #if 0 static char sccsid[] = "@(#)kvm_hp300.c 8.1 (Berkeley) 6/4/93"; #endif #endif /* LIBC_SCCS and not lint */ I'd rather that we make LIBC_SCCS actually work by removing the #if 0 (and perhaps the lint baggage) but then remove it from the default CFLAGS to preserve the existing behavior by default. Does anyone else care if I do this? -- John Baldwin From owner-freebsd-arch@freebsd.org Fri Apr 27 23:36:59 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F67FFB473A for ; Fri, 27 Apr 2018 23:36:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E17C179EA6 for ; Fri, 27 Apr 2018 23:36:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9CBAFFB4739; Fri, 27 Apr 2018 23:36:58 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78844FB4738 for ; Fri, 27 Apr 2018 23:36:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0494A79EA3 for ; Fri, 27 Apr 2018 23:36:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id h143-v6so3861739ita.4 for ; Fri, 27 Apr 2018 16:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OQilJwz/KY6OrPOoh6RnDlCeZbvskzYVMnHY2J7eITI=; b=wSSgEPyn2oialAb59LfZVuYo9yRb5xxTxZ0xImZhtdpkIWdO3THvCJyK4MXh7e0GdG t8rJeDUCivDGumFDiWzK2ZmP+DBPr/hESs6xiGiRyWRVahbIy1MXt2fwlmvoHZa+3b2C /nKHoujjhM/cQ60i0H3/cA+CSVM3Pmz+/oYFKW47Wv6zoq2e5i3fbD4ObdeNp0eeHeC3 GtM49HzTA+EUildJ1XbKzhYxrn4nrVDP6YoXAzx7ZTT6n0Z28ENePrInbnhEe6gqAqgS fkJgPQELbywefvP73g8rpQM2TKhaTZGzeSmi4EZbdPOHMtE2/0uCC+bb98Z//AxAkEoQ Bx8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OQilJwz/KY6OrPOoh6RnDlCeZbvskzYVMnHY2J7eITI=; b=rVP+a6JPCj35OC+SuFoege6XEciopzcVl0k0qmoTSz+lhTlivoOQ6l61XhdnSIpisn Q3M6X1IaG9CU2wOvr9zBCmnoEZur/4yDILp2Ljj1Z2yLLhz2yl8wVdcU8wZ8HswEYfv1 SMKhOKn0W2TXN3L7OKz4zYlVW7HAR3Ky1hQZN2XvHxOWKVI/PUVr14t1fX0E3bH0Ye2a vRzm13MwZS96kQlSk91Jpl6m4a9ATyGrCSPsFVeMIN0Co6Tl91gv7U1NVDfGwIEhMXVk igY9NLRPXUImrhVuqCTgQgZxx7d90b7R7+0FmMyIAc7CeMVYUeuZ9Yd5Vasce0XPhD/3 iOsg== X-Gm-Message-State: ALQs6tAnfwuysYQsGLuuz1Q0VkuhxTT20cDlBpGEO39b8tItK0bXfjTh SqKCzt/dQPfoPjJ5AGJ2VXS37FJHyDNEbKMDg90Utw== X-Google-Smtp-Source: AB8JxZpNCGqFMi9C5x34vat/9ww6qy0+rDj/ur0uMXMb9aHM80iNgQKfMJdrPBObGfWza081TT18rQwhFdTweDUlgto= X-Received: by 2002:a24:e983:: with SMTP id f125-v6mr4002923ith.36.1524872217152; Fri, 27 Apr 2018 16:36:57 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a65a:0:0:0:0:0 with HTTP; Fri, 27 Apr 2018 16:36:56 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <1711113.VelFtdTVS7@ralph.baldwin.cx> References: <1711113.VelFtdTVS7@ralph.baldwin.cx> From: Warner Losh Date: Fri, 27 Apr 2018 17:36:56 -0600 X-Google-Sender-Auth: fBAjKVvAfHoBUGgLeypa1Av5NSA Message-ID: Subject: Re: LIBC_SCCS To: John Baldwin Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 23:36:59 -0000 On Fri, Apr 27, 2018 at 4:19 PM, John Baldwin wrote: > I suspect no one cares, but for whatever reason our current handling of the > LIBC_SCCS macro in some of our libraries annoys me. In theory it seems > like > LIBC_SCCS's purpose is to control whether or not old SCCS IDs from Berkeley > are included in libc's sources when libc is built. (Similar to how macros > control the behavior of __FBSDID().) However, we use an odd construct in > the tree. First, we define LIBC_SCCS by default in the CFLAGS of various > libraries (libkvm, libutil, libthr, libc, etc.) which in theory would > enable > the IDs, but then we explicitly wrap them in #if 0, e.g.: > > #if defined(LIBC_SCCS) && !defined(lint) > #if 0 > static char sccsid[] = "@(#)kvm_hp300.c 8.1 (Berkeley) 6/4/93"; > #endif > #endif /* LIBC_SCCS and not lint */ > > I'd rather that we make LIBC_SCCS actually work by removing the #if 0 (and > perhaps the lint baggage) but then remove it from the default CFLAGS to > preserve the existing behavior by default. Does anyone else care if I do > this? > I'm cool with it. Why not do __SCCS_ID( "@(#)kvm_hp300.c 8.1 (Berkeley) 6/4/93");? I don't know if we need a separate #ifdef for each SCCS_ID subtree in our build. Either it's there, or it's not. Default: not. It would also let us put them in separate sections ala our freebsd id macros. I'm slightly against removing it altogether, though I can see a good case for it. I have a visceral reaction that puts me in the 'against complete removal' camp, but only just. Warner From owner-freebsd-arch@freebsd.org Fri Apr 27 23:45:48 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02561FB4971 for ; Fri, 27 Apr 2018 23:45:48 +0000 (UTC) (envelope-from mike@karels.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 908E37C97A for ; Fri, 27 Apr 2018 23:45:47 +0000 (UTC) (envelope-from mike@karels.net) Received: by mailman.ysv.freebsd.org (Postfix) id 47125FB4970; Fri, 27 Apr 2018 23:45:47 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 343D5FB496F for ; Fri, 27 Apr 2018 23:45:47 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id A70777C978; Fri, 27 Apr 2018 23:45:46 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id w3RNNksd002470; Fri, 27 Apr 2018 18:23:47 -0500 (CDT) (envelope-from mike@karels.net) Message-Id: <201804272323.w3RNNksd002470@mail.karels.net> To: John Baldwin cc: arch@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: Re: LIBC_SCCS In-reply-to: Your message of Fri, 27 Apr 2018 15:19:06 -0700. <1711113.VelFtdTVS7@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2468.1524871426.1@mail.karels.net> Date: Fri, 27 Apr 2018 18:23:46 -0500 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 23:45:48 -0000 > I suspect no one cares, but for whatever reason our current handling of the > LIBC_SCCS macro in some of our libraries annoys me. In theory it seems like > LIBC_SCCS's purpose is to control whether or not old SCCS IDs from Berkeley > are included in libc's sources when libc is built. (Similar to how macros > control the behavior of __FBSDID().) However, we use an odd construct in > the tree. First, we define LIBC_SCCS by default in the CFLAGS of various > libraries (libkvm, libutil, libthr, libc, etc.) which in theory would enable > the IDs, but then we explicitly wrap them in #if 0, e.g.: > #if defined(LIBC_SCCS) && !defined(lint) > #if 0 > static char sccsid[] = "@(#)kvm_hp300.c 8.1 (Berkeley) 6/4/93"; > #endif > #endif /* LIBC_SCCS and not lint */ > I'd rather that we make LIBC_SCCS actually work by removing the #if 0 (and > perhaps the lint baggage) but then remove it from the default CFLAGS to > preserve the existing behavior by default. Does anyone else care if I do > this? I don't object to this, but I wonder whether anyone will ever want these ancient IDs in libc. They were useful when libc was not a shared library, but (a) libc is shared, and (b) the sccsid is not changing much, at least not for the last 25 years. But "#ifdef LIBC_SCCS" is as good a way as any to turn this into a comment. You picked an interesting example; I wonder when someone last ran a BSD system on an HP 300. IIRC, it was a 68030-based system. Mike From owner-freebsd-arch@freebsd.org Fri Apr 27 23:48:33 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2AEAFB4A58 for ; Fri, 27 Apr 2018 23:48:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 32EE97CAA2 for ; Fri, 27 Apr 2018 23:48:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id E6FE3FB4A57; Fri, 27 Apr 2018 23:48:32 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF822FB4A56 for ; Fri, 27 Apr 2018 23:48:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C8E27CA9F for ; Fri, 27 Apr 2018 23:48:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id r9-v6so4332710iod.6 for ; Fri, 27 Apr 2018 16:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZgpfS3oVkLfX6jp4mV/UoHjI5PL4ZANKAn2LKaKduEU=; b=y7xIWWzwavIQHqiNypKeVwbIrEEPPVrKuwjghHgpSo1GoTz5XOws2YXcRvPSMwTRHA qT/kUqOszLXYTPI2l2w8znWg6vBcVHn1UK7S/+C50TdkOCR3EvwWMKIQuB7gLzt0TYmd nVG2l++3+H60TtRW4JFWs13rwDMkIk//9jQ8WomUtz6jWwsqMihadSZH1OuHkMMxpPte XYNoV+EX6J+SN2n3joF+wMGfHJVqPzlJHdmngdjbthGxkUNeoCP8tpAUmBmwiYuZdcHF iP1YDmZBqBgPIO8KwdMtKHB+PwGw1ApUk2C8LhznLPDKqy+jGWF3cR3oAcmLbKEyZ8ik x0nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZgpfS3oVkLfX6jp4mV/UoHjI5PL4ZANKAn2LKaKduEU=; b=lwTE1A2zfIfUVskLDPtl9bgonrw4GqQtWuz8ir3pDu49cDznLs3UJnE+hi+Yu52cfZ jE6NnBG0sgh3fB3yajR/Zl9tZqGBbM4nN3qOMx+Mk4yMQOJ0ZTr/FB0TQrw5mV75sMw7 d8ggXAAVCEzPechhAfwCdn+5Tm4Fq3ql5g5whMqK+hzHM2vKB1+Bi69GKkOiNHcII6ZC KQtSi9XgJBf8IrvDJKDkV4XfTjYfu3A1RkSnrKceA4J2R0a/v2dIoxMkxfY2u3ikXg+V Eg9HMq94m3K9wYaLV8FtgAkpb7zkvoCcMKyXkN7coXIjfBgLV7fFqXcFjwlVC33wdeXl QkRw== X-Gm-Message-State: ALQs6tC1PtzogE1X3iqfAuyK1V7dNpE0bqEwvah12eUXn7Ht5GsPLDY7 h2eNUekAVx39qLmefTzBSii1oIrbSCy9gA2U1gkPOQ== X-Google-Smtp-Source: AB8JxZrFmpJTnIosb5mXLKY9KHTqLDlTtAYHV67952H44ZjOZOJvLE7Q1+LetI9yPkBLQyhFJph9Yk8ZvTBrUOUrKFQ= X-Received: by 2002:a6b:5a0d:: with SMTP id o13-v6mr4294819iob.39.1524872911665; Fri, 27 Apr 2018 16:48:31 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a65a:0:0:0:0:0 with HTTP; Fri, 27 Apr 2018 16:48:31 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <201804272323.w3RNNksd002470@mail.karels.net> References: <1711113.VelFtdTVS7@ralph.baldwin.cx> <201804272323.w3RNNksd002470@mail.karels.net> From: Warner Losh Date: Fri, 27 Apr 2018 17:48:31 -0600 X-Google-Sender-Auth: -jVbWo_OCBH-yD5RqPg3VR5kXCU Message-ID: Subject: Re: LIBC_SCCS To: Mike Karels Cc: John Baldwin , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 23:48:34 -0000 On Fri, Apr 27, 2018 at 5:23 PM, Mike Karels wrote: > You picked an interesting example; I wonder when someone last ran a > BSD system on an HP 300. IIRC, it was a 68030-based system. A buddy of mine moved out of his college apartment maybe 10 years ago. He had several HP 68k machines that went to recycling, but a few that he retained since they still worked and were running OpenBSD. Warner From owner-freebsd-arch@freebsd.org Sat Apr 28 01:39:07 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63870FB7C25 for ; Sat, 28 Apr 2018 01:39:07 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0758972FC7 for ; Sat, 28 Apr 2018 01:39:07 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id BC482FB7C24; Sat, 28 Apr 2018 01:39:06 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AAC12FB7C23 for ; Sat, 28 Apr 2018 01:39:06 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 2E44472FC4; Sat, 28 Apr 2018 01:39:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id 0FDE71A3312; Sat, 28 Apr 2018 11:39:03 +1000 (AEST) Date: Sat, 28 Apr 2018 11:39:02 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin cc: arch@freebsd.org Subject: Re: LIBC_SCCS In-Reply-To: <1711113.VelFtdTVS7@ralph.baldwin.cx> Message-ID: <20180428110152.Q4737@besplex.bde.org> References: <1711113.VelFtdTVS7@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=yx2sZqNwYUSPZrZwlfMA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 01:39:07 -0000 On Fri, 27 Apr 2018, John Baldwin wrote: > I suspect no one cares, but for whatever reason our current handling of the > LIBC_SCCS macro in some of our libraries annoys me. In theory it seems like > LIBC_SCCS's purpose is to control whether or not old SCCS IDs from Berkeley > are included in libc's sources when libc is built. (Similar to how macros > control the behavior of __FBSDID().) However, we use an odd construct in > the tree. First, we define LIBC_SCCS by default in the CFLAGS of various > libraries (libkvm, libutil, libthr, libc, etc.) which in theory would enable > the IDs, but then we explicitly wrap them in #if 0, e.g.: > > #if defined(LIBC_SCCS) && !defined(lint) > #if 0 > static char sccsid[] = "@(#)kvm_hp300.c 8.1 (Berkeley) 6/4/93"; > #endif > #endif /* LIBC_SCCS and not lint */ Most aren't actually wrapped with '#if 0'. E.g., in libc/*/*.c there are 839 files but only 47 of these have any '#if 0' at all. SO this can be fixed without much churn. I thought there is a problem with the above not actually compiling if LIBC_SCCS is defined, but WARNS is only 2 for libc and it takes WARNS >= 4 to give -Wwrite-strings. style(9) says to use '#if 0', but not as above. It says to put the #if 0 around everything, but only if there is not already a suitable ifdef like the LIBC_SCCS one. The above style is apparently from NetBSD. It is now used a lot on libedit, with further ugliness and bugs: - first there is an #if-#else clause with a NetBSD __RCSID() in the #else clause, so that the #if 0 selects between the sccsid and the NetBSD id - __RCSID() may be killed by defining NO__RCSID. It is a bug that the application identifier NO__RCSID affects and system header. sys/cdefs.h is an especially important system header and is one of the few that tries to avoid namespace pollution bugs like this. The default is to keep the NetBSD id. - after this idfef tangle, there is an unconditional __FBSDID() to give the FreeBSD id - __FBSDID() may also be killed by defining either lint or STRIP_FBSDID. sys/cdefs.h is actually careless about namespace pollution bugs like this. > I'd rather that we make LIBC_SCCS actually work by removing the #if 0 (and > perhaps the lint baggage) but then remove it from the default CFLAGS to > preserve the existing behavior by default. Does anyone else care if I do > this? I don't mind removing FreeBSD mistakes like the '#if 0'. Editing to add const poisoning is hopefully not often needed. Bruce