From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id B8DEC3858D33 for ; Wed, 22 Feb 2023 10:52:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B8DEC3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x102b.google.com with SMTP id u10so8391735pjc.5 for ; Wed, 22 Feb 2023 02:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=76VcPPeHz+NY06SlDdgoj2BuTPY/a6OWu8OHfGuifso=; b=it1439+MJe1H1xyFtgxIyUevkwBene9u7vUD1q/ESwCRe0698LhgNZxSgkmurfKrgr N5uiQ3vbI5Lh66HqbaH1VF7k/EbPyN0kVpHKOI9lTymznxSUMm2cXSPrnwzIfhwTyC5t 4MjYzNBHoKtIppbjjwjQx3WCPV4/yU7I549kiPhN+34/ivtWgdrDyqjnPkQsyzGZYP+U KbNLmgEF67T+mCDomyg0sKQQPFqmwk9kk5cZrK5/MVj2gCdtmlLUCExyS+qzE0uTxO5A yVtLWsAc2Pw1E3/pyZ3jH9u9VdK2Cn6ipmGD+zlX6rFl48yCNIpRFygfsafllhfCzNJF auvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=76VcPPeHz+NY06SlDdgoj2BuTPY/a6OWu8OHfGuifso=; b=u12kHh8m6D1XYs5DeEsEFKmD5BCcHPBaoU/b0K/cog3XgkCKjCCrZ2K5xoelV2R6FZ 29W7+sA8654zhTl0mneL1pTspO/sOVdrHbek8MAxQe/DGWRGK+Z5q0gRm/d1qs8adD/h xnI0ChW2x/pxpLlHRvf9JwUtR2IvtjaBceDazdwWmo+WRaQhPyKC8JZZ8yabnk2gVboI 2oUyPMQdlYxs6XJKI1mA0BfbOaJYSiNfOg9rtejsxQOsiIgm98dG+Yg69oEC3qBSdorw a9s1YnM083d184djScR7ZbmU00Sh//qBvbZS50RUaI0QumDtIC3vWhvV/MvzwnMuCGvN wNkw== X-Gm-Message-State: AO0yUKXMeP0ONToj9vd25ZUhClOFO7S0tFZdUFERTA/UhVNpThMs0Lj0 1fM37WmcYsJrMH3+5jAl7xbNOK+OkfA= X-Google-Smtp-Source: AK7set/GIY+HFjwrRZzrfNUiipz5uc0y42GU/fPtiFpsZixBLHnJdSnKAJRcfiWUmJQd9sXQCms4pw== X-Received: by 2002:a17:902:e745:b0:198:adc4:22a4 with SMTP id p5-20020a170902e74500b00198adc422a4mr9569599plf.31.1677063142751; Wed, 22 Feb 2023 02:52:22 -0800 (PST) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:815a:53dc:52ea:9cb]) by smtp.gmail.com with ESMTPSA id az8-20020a170902a58800b00198f1de408csm1077170plb.268.2023.02.22.02.52.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Feb 2023 02:52:22 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id D6D4E11404B0; Wed, 22 Feb 2023 21:22:19 +1030 (ACDT) Date: Wed, 22 Feb 2023 21:22:19 +1030 From: Alan Modra To: Jan Beulich Cc: Mark Harmstone , Nick Clifton , binutils@sourceware.org Subject: Re: [PATCH] ld: Sort section contributions in PDB files Message-ID: References: <20230220141328.20441-1-mark@harmstone.com> <5176ad2d-747f-71a1-27d1-5e6458402a2d@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5176ad2d-747f-71a1-27d1-5e6458402a2d@suse.com> X-Spam-Status: No, score=-3027.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Feb 22, 2023 at 08:08:43AM +0100, Jan Beulich wrote: > On 22.02.2023 06:48, Alan Modra wrote: > > On Tue, Feb 21, 2023 at 09:26:33AM +0100, Jan Beulich wrote: > >> On 20.02.2023 15:13, Mark Harmstone wrote: > >>> +/* Used as parameter to qsort, to sort section contributions by section and > >>> + offset. */ > >>> +static int > >>> +section_contribs_compare (const void *p1, const void *p2) > >>> +{ > >>> + const struct in_sc *sc1 = (const struct in_sc *) p1; > >>> + const struct in_sc *sc2 = (const struct in_sc *) p2; > >> > >> In ANSI C there's no need for these casts; it may be that they were > >> needed in pre-ANSI dialects like K&R. Personally I view _any_ cast > >> as latently dangerous, and hence I'd prefer if casts were used only > >> if there's no other option. > > > > I agree that it's fine to write this without the casts, and I've even > > used the cast to void* you mention later in your email to shorten > > lines myself. I agree that casts are inherently dangerous too, and > > that it's a good idea to not use them unless necessary. Also, it's > > really, really annoying to need casts because something like > > os = &lang_os_list.head->output_section_statement; > > gets a ubsan warning when lang_os_list.head is NULL, forcing you to > > use a cast or accessor that loses the type checking or to write > > horrendous code. There have been bugs in ld list handling due to > > casts. > > > > However, I'm inclined to say that a cast in a qsort comparison > > function, or to cast the return of malloc or similar is mostly a > > matter of style. If a contributor wants to write it that way, I'm > > fine with approving new code with these casts. After all, there is > > plenty of such code in binutils already. > > Now that's an interesting perspective. Depending on feedback on the > topic I was meaning to possibly conclude that such unnecessary casts > would be ripe for removal. Perhaps not by hunting them down and > replacing them in an isolated effort, but as code is being touched > anyway. I'm fine with doing that too, particularly as you touch code. What I was trying to say, is that I think it's important for maintainers to allow contributors some freedom in style, to tolerate things that don't matter that much. -- Alan Modra Australia Development Lab, IBM