From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 350863858D3C for ; Tue, 21 Feb 2023 10:49:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 350863858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676976556; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=F8oZSUx0GJ9KzUvTHADFnR35DuS79AvOQs0gYuftLKA=; b=KhE9gjZ3qt2OXGoUY+ASJS0SjdhNRDGzELd8b4o83fIf6syregwPgbv7d4colTVom+u18D f/Y0IT1c2QlDkPr+FCodQ5ur6iRyYI40f5hgx6LUqkcaDTLy7DfegOeDsTlBjrP2pR6pXH +obukq3Imh8UJ4PJO3WMmyx9WYhWqR4= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-81-_9ZFm_SZM7-65H-5x6cWpg-1; Tue, 21 Feb 2023 05:49:15 -0500 X-MC-Unique: _9ZFm_SZM7-65H-5x6cWpg-1 Received: by mail-wm1-f70.google.com with SMTP id c7-20020a7bc847000000b003e00be23a70so1838638wml.2 for ; Tue, 21 Feb 2023 02:49:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:content-language :references:cc:to:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=F8oZSUx0GJ9KzUvTHADFnR35DuS79AvOQs0gYuftLKA=; b=Po3vGI3x6VjeCwtaHPZViBYfUrwuJXMQW6dZZ/c+H+zE+vA/wf+i2i9skmcuN0Agbs F8kqvUtkdsGnLUI3YyJ2iWfEvv54z8i7v8L0sh3x/i6R0q1jgAIAklsl9G0uwV06iEvH gGOEKg2wMgfqVZutJjQ09PwIrDDTlY8YayxJ3prDLBMEWFZHsEHG0PXnIIibigMXOx1i ZMy4YutAmVxjwrXM9uCR6KaTpxbmVifBopafLT94d6ibA51d36hwnG8heVirNJ+AcAKA +GpO86tcFugdE76Z/MpBPwWLCzmnNjrhQrHhRQJl0hWBCPYzfDy0IeBatKiLzLUu+0Wg zVfw== X-Gm-Message-State: AO0yUKUEcAE6C7kQrSByvBgpI/FgPBKI20Dyy5+DCXhyrDF7jFqbG2n1 lrNRDNI1gc69+YACwMz/r2+c0uWiAFf/gv5DkYm0/0+eoUrED9v3vuMXXm1XKRMyxgEeuXF8D4v QXg08Qni//QJgCCmYshI/CDI= X-Received: by 2002:adf:f208:0:b0:2c5:9ab9:60f6 with SMTP id p8-20020adff208000000b002c59ab960f6mr4778266wro.62.1676976553888; Tue, 21 Feb 2023 02:49:13 -0800 (PST) X-Google-Smtp-Source: AK7set+bGQtH7zXqc2Sxl2guTmw1g8pjcn0lRYNY2xikGb3uuZboCd2xHJzZDFuQqGzZ66W7KmXMAg== X-Received: by 2002:adf:f208:0:b0:2c5:9ab9:60f6 with SMTP id p8-20020adff208000000b002c59ab960f6mr4778249wro.62.1676976553579; Tue, 21 Feb 2023 02:49:13 -0800 (PST) Received: from [192.168.1.18] ([79.123.86.193]) by smtp.gmail.com with ESMTPSA id x17-20020adff651000000b002c563b124basm4342762wrp.103.2023.02.21.02.49.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Feb 2023 02:49:12 -0800 (PST) Message-ID: <7027c7ac-0e65-0bbb-22d3-167b929247f9@redhat.com> Date: Tue, 21 Feb 2023 10:49:12 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 To: Jan Beulich , Mark Harmstone , Alan Modra Cc: binutils@sourceware.org References: <20230220141328.20441-1-mark@harmstone.com> From: Nick Clifton Subject: Re: [PATCH] ld: Sort section contributions in PDB files In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: Hi Jan, Hi Mark, > In principle okay, but I'd like to re-raise the question of excess > casting (hence including Nick and Alan as the far more experienced > binutils maintainers): Normally I would only be worried about excess casting if it is likely to obscure a problem. Unnecessary casting might be niggling from a readability point of view, but I would not normally consider it to be a reason to reject a patch. Dangerous casting is another matter though... >> +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. Agreed - the casts are not needed here. > Personally I view _any_ cast > as latently dangerous, and hence I'd prefer if casts were used only > if there's no other option. Well I think casts from a void type to something else are usually reasonable, But otherwise I would agree that they are often suspicious. On a related note - I would consider this line to be problematic: sc_in = xmalloc (num_sc * sizeof (struct in_sc)); The code here implies that "sc_in" is a pointer to the "struct in_sc" type. If at some future date the code is changed and the type of "sc_in" is changed then the above line will still work, but the wrong amount of space will be allocated. So I would suggest changing it to either: sc_in = xmalloc (num_sc * sizeof (* sc_in)); Or: sc_in = xmalloc (num_sc * sizeof * sc_in); /* I like this version, but nobody else does ... :-) */ Or: sc_in = XNEWVEC (typeof (sc_in), num_sc); >> + sc = >> + (struct section_contribution *) ((uint8_t *) *data + sizeof (uint32_t)); > > This one's more interesting: Some cast is needed here at least as long as > we don't mean to allow use of GNU extensions (here: arithmetic on pointers > to void). But seeing that this causes a line length issue, at a minimum > I'd recommend to go with > > sc = (void *) ((uint8_t *) *data + sizeof (uint32_t)); > > (Ideally sc would be pointer-to-const and the cast here then also one to > pointer-to-const.) > > Nick, Alan - thoughts? The code certainly is messy. I do not like the implicit casting of a void pointer to a structure pointer, so personally I would keep the assignment cast and try to eliminate the cast of *data by using an intermediary variable: uint32_t * ptr = * data; sc = (struct section_contribution *) (ptr + 1); /* Skip the version word. */ Even this looks wrong to me, since it assumes that it is OK to cast a 4 byte aligned pointer to a structure pointer, with no guarantee that the structure does not need a larger alignment. I get that the code is computing the contents of a section which starts with a version number followed by a set of filled in objects, and that this is hard to express cleanly in C. But still I would not be surprised if a static analysis tool flagged this code as a potential problem. Cheers Nick