[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch #4604] Fix left anchors and -w problems
From: |
Julian Foad |
Subject: |
Re: [patch #4604] Fix left anchors and -w problems |
Date: |
Wed, 09 Nov 2005 23:08:14 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 |
Other than that, my only comment is please could you put a doc string on
the typedef or #define for the "execute" functions that states, at the very
least, the special meaning of "start_pos == -1". And/or use a defined
constant with a suitable name instead of the "(size_t) -1".
I need the following specific feedback regarding this.
Was choosing to use an offset (integer) for
this the right thing to do? In particular,
would using a character pointer have been better?
A character pointer would have had the following
properties:
-- NULL can be used as the special value to
indicate that a non-exact match is desired.
It is easier to test for NULL, both in source
code and in compiled machine language.
If that makes the source code easier to write and to read, then do that. If it
"feels" more likely to be efficient, so much the better.
-- When comes the time to address the full
64-bit support issue, a chararacter pointer
(i.e., an address) may more automatically
be 64-bit than any integer type. Less to
worry about then. (Or are there hybrid
"architectures" where it's just the
opposite?)
This is a very small piece of the things we'll have to worry about then, so
don't worry about it now. I don't think either way will present much of a problem.
On the other end, the data string's extent is
already specified there by an integer length,
not by an end pointer, so it's unclear what's
best to do.
This "starting point" parameter is logically similar to the "start of data"
parameter (pointer), and in other ways logically similar to the "end of data"
parameter (integer), so either would be good. Use a pointer if it makes the
code clearer (in callers and callees). This is not an inner loop so code
clarity is more important than speed efficiency.
None of these logical values (extent and
start-of-lookup) are made long-lived by this
interface; they are ephemeral. By that, I mean
that sometimes lenghts and offsets are stored
instead of pointers just in case the data string
might be relocalized by other code; this doesn't
appear to be an issue here for this interface.
Indeed.
- Julian
[patch #4604] Fix left anchors and -w problems, Charles Levert, 2005/11/09