From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 8740D3858D3C for ; Wed, 22 Feb 2023 05:48:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8740D3858D3C 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-pl1-x629.google.com with SMTP id e9so2563999plh.2 for ; Tue, 21 Feb 2023 21:48:56 -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=aTp06H0Bj0uCg5JOGJURKpO9q4sg61zE201wYxHU0y8=; b=KD7L5FGNGogy4FItUQyWGTXkBEDlRxqvGx9TGhlpYdWDeowQJ8ZSL0Sd9L+xCUPu+o Cdd5mf8cVbkOTDiZX2ReFStMqBQYHi129+0OEEDuIsA6y85PeXlePsrlLLCNWQeeuXDz gycTrlg1U5qv5QZueL07inK1cOEZg3jIWk4eSC/YiL4ORJngORRhZwVjxb+bhRKfX94L AeagiHMQh20KhAamtE8635pSCmnnSRbqXSkkoewT9DYCTgMyEstjk3lKhLw5rO8NBJqo AM9IyFIzETy59JayZI1iOJNRUbasKZwlwiYojNH/9QquWiMejT1PHoOyKCJuqnjWMFKt 0pIQ== 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=aTp06H0Bj0uCg5JOGJURKpO9q4sg61zE201wYxHU0y8=; b=yUdV8a/10gCgzzHS666St4nL7h+0Cg+bBFqvqeCdfWouCOKcK42zcF5uDXKbfUOdih uygsTHyPzQ5EuXiRMj+u2cMbQv0ebXn8fJC/lYh55zcJUIsQZq8rB7wxYggUkUrSYEth 69KS7L3oognfDjUS9eOwC+NEGsBI2P8tGGFHyVF4Pp82J6vzinWAeKFGHBKWzeayLrJA VM5KPTX+b6xSfDJTCbhoo/EipSL7YQufYQIkVeaX0w6Mb3bmmT2zepxDRbqz4gKuNPBC 4AFdxZvjBE9mwqg0LehhPAM+e7kg/H3EF0R7yBrM2UsSS6Kf3uBUlWLWNKrfr3ICgrcj AjYA== X-Gm-Message-State: AO0yUKUPCH6/57SXnksqFhDYDgv00CKAKGOoNSuPRNbY/95UR9B7B/uJ SVlO76U9MKiqvcID0gEH3Ms= X-Google-Smtp-Source: AK7set8sTu/1Gv+u4Vl9eQZS4EGc++HE3/Kb1vsx6efhdAy7QMGxWGz7aN6ynO+6LAd0LAZTf0LVkg== X-Received: by 2002:a05:6a20:8f11:b0:c7:346b:71b5 with SMTP id b17-20020a056a208f1100b000c7346b71b5mr8200705pzk.11.1677044935503; Tue, 21 Feb 2023 21:48:55 -0800 (PST) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:815a:53dc:52ea:9cb]) by smtp.gmail.com with ESMTPSA id p14-20020aa7860e000000b005a8bdc18453sm1687750pfn.35.2023.02.21.21.48.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Feb 2023 21:48:54 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 4CE2811404B0; Wed, 22 Feb 2023 16:18:52 +1030 (ACDT) Date: Wed, 22 Feb 2023 16:18:52 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3027.9 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 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. -- Alan Modra Australia Development Lab, IBM