Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Azat Khuzhin <a3at.mail@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb: set filename-display shortpath support
Date: Mon, 09 Dec 2013 08:32:00 -0000	[thread overview]
Message-ID: <20131209083216.GB4011@adacore.com> (raw)
In-Reply-To: <1386538152-13461-1-git-send-email-a3at.mail@gmail.com>

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...

> +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.

> +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.  */

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.

-- 
Joel


  reply	other threads:[~2013-12-09  8:32 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 [this message]
2013-12-09  9:02   ` Azat Khuzhin
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=20131209083216.GB4011@adacore.com \
    --to=brobecker@adacore.com \
    --cc=a3at.mail@gmail.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