Re: substr() - copying or not copying, that is here the question.

On 01.06.2025 14:06, Kenny McCormack wrote:

In article <101hecq$22ab2$1@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
...

An alternative (depending on the context) would be to consider an
extension that provides an index function with a third argument giving
the initial offset.  I've not looked at how extensions get access to
GAWK strings, so this many not be as easy as it sounds, but I would
guess that it might be relatively simple to do.

>
This, first of all, sounds like a good idea! It would make it
unnecessary to (mis-)use the substr() function as (sort of) a
costly copying-descriptor.[*]
>
I'm unsure about using an extension here. Would there be a name
clash between an built-in index(haystack,needle) function and an
extension index(haystack,needle,start) function? Should they be
separate functions in the first place? (I don't think so.)

 
Nobody is talking about changing the index() built-in function.

Well, I was.

asort(source [, dest [, how ] ])
gensub(regexp, replacement, how [, target])
gsub(regexp, replacement [, target])
match(string, regexp [, array])
patsplit(string, array [, fieldpat [, seps ] ])
split(string, array [, fieldsep [, seps ] ])
substr(string, start [, length ])  # already standard Awk
close(filename [, how])
mktime(datespec [, utc-flag ])
strftime([format [, timestamp [, utc-flag] ] ])

...there are already standard Awk functions (sensibly!) extended by
optional arguments, and also GNU Awk specific functions that either
have from the beginning optional arguments or got extended later.

 
This would be a brand new function, written as an extension library.
 
You could name it something like index_ex() if you like, or you could give
it a brand new name (**).

None of that I'd find a good solution given the existence of index().
(YMMV.)

[...]
 
(**) My conception of how this would be implemented would handle the
"start"-only case (just add the offset to the "haystack" arg of strstr() -
with error checking to make sure it doesn't overflow, of course).
Implementing "end" would be a bit trickier (but not much).

Yes, I'd second that.

Janis