Re: [patch #4604] Fix left anchors and -w problems

[Julian Foad]

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