public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Martin Storsjö" <martin@martin.st>
To: Nick Clifton <nickc@redhat.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH v4] ld: Make archive member file extension comparisons case insensitive when cross compiling too
Date: Wed, 24 Aug 2022 13:03:17 +0300 (EEST)	[thread overview]
Message-ID: <e24a10fd-a4a0-af14-4b16-5657db136a66@martin.st> (raw)
In-Reply-To: <8451b476-1777-2fb5-74bb-042ee17aefee@redhat.com>

On Wed, 24 Aug 2022, Nick Clifton wrote:

> Hi Martin,
>
>  Sorry to be persnickety, but ...

No problem, I don't mind iterating on it to get it properly right, when 
the iteration time is reasonable :-)

>
>> +/* A case insensitive comparison, regardless of the host platform, used 
>> for
>> +   comparing file extensions. Parameter s1 points at the extension in a 
>> file
>> +   name (pointing at the starting '.'). Parameter s2 is a lower case 
>> string
>> +   without the leading '.'. */
>
> Comment formatting: two spaces before the closing */

Oh, I hadn't noticed that aspect - will fix.

>> +static int fileext_cmp (const char *s1, const char *s2)
>
> Function name formatting - name on a separate line from the return type.

Ok, sure.

> And yes, I know that the same problem exists for the is_underscoring()
> function directly before this one.  A patch to fix that formatting is
> pre-approved. :-)
>
>
>> +  if (*s1 != '.')
>> +    return 1;
>
> Strictly speaking this should be an error return value.  Maybe return
> INT_MAX ?  Or generate an error message and then return 1.  This test
> will probably never trigger however, so just returning 1 is OK really.
> In fact just ignore me on this one...

Ok, keeping this as is. Yes, it'd be unexpected if this isn't true, but 
from the point of view of the comparison, it's at least not a match for 
the extension.

>
>> +      int c2 = *s2++; /* Assumed to be lower case from the caller. */
>
> Assumptions are bad.  But testing this assumption does lead to needless
> performance penalties.  So ignore me on this one too.
>
> But please do fix up the comment formatting.

Ok.

>
>> diff --git a/ld/emultempl/pep.em b/ld/emultempl/pep.em
>
> Similar comment apply here, of course.
>
>
> Hmm.  We really ought to move the code duplicated in pe.em and pep.em into a
> single file...

Yep, totally. Unfortunately that aspect is way out of depth for me at the 
moment - I'm not familiar with binutils nearly well enough to take on 
that.

Currently I try to keep things in sync by doing the modifications on one 
and then applying the patch on the other file.

// Martin


  reply	other threads:[~2022-08-24 10:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-23 13:06 [PATCH v2] ld: Make library member file suffix " Martin Storsjö
2022-08-23 14:01 ` Nick Clifton
2022-08-23 14:19   ` Martin Storsjö
2022-08-23 14:23   ` Jan Beulich
2022-08-23 21:11     ` [PATCH v3] ld: Make archive member file extension " Martin Storsjö
2022-08-24  6:38       ` Jan Beulich
2022-08-24  8:23         ` [PATCH v4] " Martin Storsjö
2022-08-24  9:48           ` Nick Clifton
2022-08-24 10:03             ` Martin Storsjö [this message]
2022-08-24 10:04               ` [PATCH v5] " Martin Storsjö
2022-08-24 10:29                 ` Jan Beulich
2022-08-24 10:46                   ` Martin Storsjö
2022-08-24 10:46                     ` Martin Storsjö
2022-08-24 10:47                     ` [PATCH v6] " Martin Storsjö
2022-08-24 11:17                       ` Jan Beulich
2022-08-24 12:25                         ` [PATCH v7] " Martin Storsjö
2022-08-24 12:39                           ` Jan Beulich
2022-08-24 12:56                           ` Nick Clifton
2022-08-24 20:23                             ` Martin Storsjö
2022-08-25  6:53             ` [PATCH v4] " Martin Storsjö

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e24a10fd-a4a0-af14-4b16-5657db136a66@martin.st \
    --to=martin@martin.st \
    --cc=binutils@sourceware.org \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).