From: Azat Khuzhin <a3at.mail@gmail.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb: set filename-display shortpath support
Date: Mon, 09 Dec 2013 09:02:00 -0000 [thread overview]
Message-ID: <CAG5DWohquGkXjBzVsKyyuPR1=yW69DK41osrNq69xmCRaDH6NQ@mail.gmail.com> (raw)
In-Reply-To: <20131209083216.GB4011@adacore.com>
On Mon, Dec 9, 2013 at 12:32 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> Hello,
>
> Thanks for the patch. I've only had a chance to scan the patch, so
> cannot comment deeply. But I can make a few comments...
Thanks for you review.
I resent new patch with coding style issues resolved. (V2)
>
>> +2013-12-00 Azat Khuzhin <a3at.mail@gmail.com>
>> +
>> + * source.h (symtab_to_shortpath): Add it.
>> + * source.c (filename-display): Add shortpath display.
>> + * source.c (symtab_to_filename_for_display): Use symtab_to_shortpath.
>
> You don't need to repeat the source filename. In your case, the last
> 2 lines of the CL become:
>
> * source.c (filename_display): Add shortpath display.
> (symtab_to_filename_for_display): Use symtab_to_shortpath.
>
> Note also the '-' incorrectly used instead of '_' in filename_display.
>
> One small request, also. It's customary to provide the ChangeLog
> as text, rather than make it a ChagneLog diff. If you take a look
> at a few random messages on this list, you'll probably understand.
> ChangeLog files are always getting new changes, and always at the
> same location, thus constantly generating sources of conflicts.
> Unless you have an automated conflict solver in your setup, it's
> fine to send the diff with the ChangeLog in the revision history,
> and then only add the entry just before pushing the change to
> our repository. Tom also posted some tips on how he was managing
> the ChangeLog entries (search for "ChangeLog management tip" in
> the gdb@sourceware.org mailing list archives, Oct 25th 2013).
>
> Overall, I don't remember if other commented, but this sounds like
> a useful idea.
>
>> +#undef MIN
>> +#define MIN(A, B) (((A) <= (B)) ? (A) : (B))
>
> You don't need that. Use "min", defined in defs.h if not already
> defined.
I searched by MIN (case-sensitive) that's why I didn't find it.
Thanks.
>
>> +const char *
>> +symtab_to_shortpath (struct symtab *symtab)
>
> Can you add a small comment explaining that the description of that
> function is in source.h? The usual form is something minimilistic
> such as:
>
> /* See source.h. */
Forgot that. Thanks.
>
> It just allows us to quickly know that this function is expected to be
> documented elsewhere.
>
>> + char *prev_slash_name = (char *)symtab->filename;
>> + char *prev_slash_dir = (char *)symtab->dirname;
>> + char *slash_name = (char *)symtab->filename;
>> + char *slash_dir = (char *)symtab->dirname;
>> + const char *shortpath = slash_name;
>
> Formatting nit: space after the ')'.
>
>> + if (!slash_dir)
>> + return shortpath;
>
> A recent Coding Style decision requires us to explicitly test against
> NULL -> if (slash_dir != NULL)
>
>> +
>> + while ((slash_name = strstr(slash_name, SLASH_STRING)) &&
>> + (slash_dir = strstr(slash_dir, SLASH_STRING)))
>
> Formatting nit: binary operators should be at the start of the next
> line, not at the end. Also, make sure to have a space before '('
> in function calls. There are other such violations in the rest of
> the code, which I will not repeat - can you fix the rest as well?
>
> But we also frown on assignments inside conditions. Can you rewrite
> the code to avoid that?
>> + {
>> + slash_name++;
>> + slash_dir++;
>> +
>> + if (strncmp(slash_name, slash_dir, MIN(slash_name - prev_slash_name, slash_dir - prev_slash_dir)))
>
> This should should be split to not exceed 80 chars (we like a soft limit
> of 70 characters, as long as practical).
>
>> + basename - display only basename of a filename\n\
>> + relative - display a filename relative to the compilation directory\n\
>> + absolute - display an absolute filename\n\
>> + shortpath - display only non-common part of filename and compilation directory\n\
>
> This line is a little bit too long. It's a bit of PIA to be breaking
> it; I think we should do it, for the sake of consistency, but it's not
> a strong opinion.
I think that there is no need in new line for breaking, so I just
break it in code.
>
> --
> Joel
--
Respectfully
Azat Khuzhin
next prev parent reply other threads:[~2013-12-09 9:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-08 21:29 Azat Khuzhin
2013-12-09 8:32 ` Joel Brobecker
2013-12-09 9:02 ` Azat Khuzhin [this message]
2013-12-09 13:04 ` Pedro Alves
2013-12-09 13:24 ` Azat Khuzhin
2013-12-09 8:55 Azat Khuzhin
2013-12-09 9:01 Azat Khuzhin
2013-12-09 16:34 ` Eli Zaretskii
2013-12-09 21:25 ` Azat Khuzhin
2013-12-09 9:21 Azat Khuzhin
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='CAG5DWohquGkXjBzVsKyyuPR1=yW69DK41osrNq69xmCRaDH6NQ@mail.gmail.com' \
--to=a3at.mail@gmail.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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