All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
To: Fredrik Kuivinen <freku045@student.liu.se>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/9] Add has_extension()
Date: Thu, 10 Aug 2006 20:42:09 +0200	[thread overview]
Message-ID: <44DB7E01.4000901@lsrfire.ath.cx> (raw)
In-Reply-To: <20060810182117.GA13446@c165.ib.student.liu.se>

Fredrik Kuivinen schrieb:
> On Thu, Aug 10, 2006 at 05:02:30PM +0200, Rene Scharfe wrote:
>> +static inline int has_extension(const char *filename, int len,
>> const char *ext) +{ +	int extlen = strlen(ext); +	return len >
>> extlen && !memcmp(filename + len - extlen, ext, extlen); +} +
> 
> Wouldn't this function be much easier to use if len is computed from 
> filename with strlen? (after a quick look through the other patches I
>  couldn't find a call site where filename wasn't NUL-terminated)

Yes, it would be a bit easier, and my first version had only two
arguments.  Then I found out that the length of the first string is
already known at _all_ potential callsites, using this command to
identify candidates:

	$ grep 'cmp.*"\..*"' *.[ch]

We could add something like this:

	#define has_ext(a, b) has_extension(a, strlen(a), b)

to make it easier to use for code that doesn't already determine the
string length.  I think we should add it only after a user has been
identified, though.

Thanks,
René

  reply	other threads:[~2006-08-10 18:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-10 15:02 [PATCH 0/9] git-verify-pack: clean up and make builtin Rene Scharfe
2006-08-10 15:02 ` [PATCH 1/9] Add has_extension() Rene Scharfe
2006-08-10 16:25   ` Johannes Schindelin
2006-08-10 17:48     ` Rene Scharfe
2006-08-10 18:21   ` Fredrik Kuivinen
2006-08-10 18:42     ` Rene Scharfe [this message]
2006-08-10 21:47       ` Fredrik Kuivinen
2006-08-10 15:02 ` [PATCH 2/9] git-verify-pack: show usage when no pack was specified Rene Scharfe
2006-08-10 15:02 ` [PATCH 3/9] git-verify-pack: more careful path handling Rene Scharfe
2006-08-10 15:02 ` [PATCH 4/9] git-verify-pack: insist on .idx extension Rene Scharfe
2006-08-10 15:02 ` [PATCH 5/9] git-verify-pack: get rid of while loop Rene Scharfe
2006-08-10 15:02 ` [PATCH 6/9] git-verify-pack: free pack after use and a cleanup Rene Scharfe
2006-08-10 15:02 ` [PATCH 7/9] git-verify-pack: buffer overrun paranoia Rene Scharfe
2006-08-10 15:02 ` [PATCH 8/9] git-verify-pack: no need to count errors Rene Scharfe
2006-08-10 16:23   ` Johannes Schindelin
2006-08-10 17:37     ` Rene Scharfe
2006-08-10 15:02 ` [PATCH 9/9] git-verify-pack: make builtin Rene Scharfe
2006-08-10 16:24   ` Johannes Schindelin

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=44DB7E01.4000901@lsrfire.ath.cx \
    --to=rene.scharfe@lsrfire.ath.cx \
    --cc=freku045@student.liu.se \
    --cc=git@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.