Matthew Maurer <mmaurer@xxxxxxxxxx> writes:
>> Sorry I realise it's version 7, but although the above looks correct it's
>> kind of dense.
>>
>> I think the below would also work and is (I think) easier to follow, and
>> is more obviously similar to the existing code. I'm sure your version is
>> faster, but I don't think it's that performance critical.
>>
>> static void dedotify_ext_version_names(char *str_seq, unsigned long size)
>> {
>> char *end = str_seq + size;
>> char *p = str_seq;
>>
>> while (p < end) {
>> if (*p == '.')
>> memmove(p, p + 1, end - p - 1);
>>
>> p += strlen(p) + 1;
>> }
>> }
>>
>> The tail of str_seq will be filled with nulls as long as the last string
>> was null terminated.
>
> As you alluded to, what you're providing is potentially O(n^2) in the
> number of symbols a module depends on - the existing code is O(n).
> If leading dots on names are rare, this is probably fine. If they're
> common, this will potentially make loading modules with a large number
> of imported symbols actually take a measurable amount of additional
> time.
It should only be a single symbol these days, .TOC., for both big and
little endian builds.
But maybe someone out there is still building their kernel ELFv1, in
which case every function will begin with '.'.
I still don't think it will be measurable, but n^2 is asking for
trouble.
So forget it, just use your version, you've already written it anyway.
Sorry for the noise.
cheers
