From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 40C4E38330C4 for ; Mon, 27 Feb 2023 00:50:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 40C4E38330C4 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=harmstone.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-x42f.google.com with SMTP id r18so4572304wrx.1 for ; Sun, 26 Feb 2023 16:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=BwUCatiwPWEfSyHdkTbbjT+jpQDiYMm0rIgDKrz095Q=; b=F/X4T+hdnJj3sDAgBB4gIH4jsBC8/hRRcZqNIWEKgOJNMIDDuVPX1pD8qbLZJVXleC JU1yGXgFPn0LZNqTZfK3e7dXJ71DRo2s5O0slLNotvDy+v+2l3rme7SZy7n62k3YwvsO 2zoKSYOn1Se27R+4SgpYGM+kytebBzK2XXevB2pB0nrdhC69a+osiKz65ybZl1E5GhEn 1Qf1/Ls3NmPLKX9Y47j+1sDWp+nvkNAt1EZoAHkTgKc6S5bOxI31oj4dzPFsJEzVv1DQ dxTgl9ctjPAgTk9ruAM3G27+hYSTjYMPy+h7r6vE674rdXh8cFUg2mmjd5cDxq0uQqcb NySQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BwUCatiwPWEfSyHdkTbbjT+jpQDiYMm0rIgDKrz095Q=; b=BoZIv208+vnjXl4uPiE/Pc64peNl/+XM+paernNBM6BublMHEuXwuRZJVHG4asKb6q SHKQ74zOt8zQPBEfcUM3+C1ZkBbbS9KKUqcOA9YyrCQGOGPznS6pctSjGMll3umlV5Ct 62GW6Gk2bB+93zKB7qJP2V9bbcnw5EUdzFCCIBk2YxOuJzKWXjgDl0/eE82+o6zKEXzY 3buJlhglhVH8wD/OuN2sdhQJlIVGnNlMpPfwNZCJ8685VVe/08fR9v9Uynacz46nLxYr XUh/XBiyjyFwOK1Was/82f/skXdrIpjOAFvV3Ojsm1TDASGpVcnJ5FyH+FxKgCs+kV25 zyCQ== X-Gm-Message-State: AO0yUKXY0oIj60xI15dsqmuVHWSnybRGlL0V5monGQpmJtgwiwF9iWtp i3o70V4ywzZDpbAkMkOEOV4= X-Google-Smtp-Source: AK7set+E0J65acwjsWNTo1ImqgVhLgoyMdmzZrwbno4jEeF61vo+XZXszvJvfHGb6Owf2uTvrGN4mg== X-Received: by 2002:adf:ef8e:0:b0:2c7:adb:db9 with SMTP id d14-20020adfef8e000000b002c70adb0db9mr13044607wro.63.1677459018685; Sun, 26 Feb 2023 16:50:18 -0800 (PST) Received: from ?IPV6:2a02:8010:64ea:0:8eb8:7eff:fe53:9d5f? ([2a02:8010:64ea:0:8eb8:7eff:fe53:9d5f]) by smtp.googlemail.com with ESMTPSA id p2-20020adfe602000000b002c561805a4csm5621809wrm.45.2023.02.26.16.50.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Feb 2023 16:50:18 -0800 (PST) Sender: Mark Harmstone Message-ID: <14a49f11-73c5-8758-f566-5f918420a731@harmstone.com> Date: Mon, 27 Feb 2023 00:50:17 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH] ld: Sort section contributions in PDB files Content-Language: en-US To: Alan Modra , Jan Beulich Cc: Nick Clifton , binutils@sourceware.org References: <20230220141328.20441-1-mark@harmstone.com> <5176ad2d-747f-71a1-27d1-5e6458402a2d@suse.com> From: Mark Harmstone In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 22/2/23 10:52, Alan Modra wrote: > 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. > Thanks all, I'll resubmit with the changes suggested. Jan, something to bear in mind is that doing such a thing would be counter-productive if binutils were ever to be converted to C++. I don't know if anybody's looked into such a thing in earnest - I'm guessing the project's too large for it to be worth anyone's time. But it'd be much more pleasant if the files in emultempl etc. were nice templated cpp files, rather than what's there at present :-) Mark