Hi Alejandro,
Looking at the naming discussion — strpfx vs. strprefix vs.
str_startswith — and at the pointer-result vs. bool-result discussion,
I have to get back to the fundamentals.
* What is the point of standardizing a function in ISO C ?
There are three cases, ordering in decreasing necessity of standardization:
A. Some functionality that requires kernel support.
Examples: The fopen(), remove(), thrd_create() functions.
B. Some functionality that is hard to optimize for an ordinary
programmer, or otherwise extraordinarily complex.
Examples: The strcmp(), gmtime() functions.
C. Convenience for programmers.
The benefit is that programmers from different projects should
recognize the function names because they have seen it in use
elsewhere.
Your proposal is in category C, and therefore the questions
"what is the point of this proposal?" and "does it have a positive or a
negative impact on the C programmers community?" are sensitive to details,
and need to be re-evaluated each time a detail has changed.
In my opinion,
* With the proposed naming 'strsfx', 'strpfx' etc. it has a *negative*
impact on the community of C programmers. Because, as explained, they
teach programmers that it is OK to have shortened and unpronounceable
identifiers.
Therefore, I am opposing any attempt to push through with this proposal.
* With the proposed naming 'strprefix' and 'strsuffix' that return
pointers (after all, as you noted, 'strchr' and 'strstr' also return
pointers and don't have a 'p' as third letter), I don't see a positive
nor a negative impact.
I think that the cases where the programmer wants a pointer (not just
a bool value) is 10% of the use-cases or less.
No positive impact because projects which want readable function names
will do things like
inline bool str_startswith (const char *s, const char *sub)
{
return strprefix (s, sub) != NULL);
}
inline bool str_endswith (const char *s, const char *sub)
{
return strsuffix (s, sub) != NULL);
}
and they could have gotten the same result by just slightly different
inline functions:
inline bool str_startswith (const char *s, const char *sub)
{
return strncmp (s, sub, strlen (sub)) == 0;
}
inline bool str_endswith (const char *s, const char *sub)
{
size_t len = strlen (s);
size_t n = strlen (sub);
return len >= n && streq (s + len - n, sub);
}
So, what is the point of attempting this standardization if the
majority of the uses are better expressed with a bool-returning
function anyway? And where different projects will choose
different function names? Then you can just as well leave it
unstandardized.
* With the proposed naming 'str_startswith', 'str_endswith',
'str_prefix_end', 'str_suffix_start', there would be a *positive*
impact, because
- programmers will recognize 2 of these function names when
they are/get familiar with 10 out of 15 other programming languages,
- programmers get accustomed to understandable identifiers.
Therefore, this one I am willing to give my support to.
> About names from other languages, I don't necessarily like that
> reasoning. We almost had _Countof() named _Lengthof() because committee
> members wanted that name from other languages which have it as length.
> That would have been harmful, as it would have mixed sizes and lengths
> in string-handling code, promoting off-by-one bugs. In general, I'd
> take other languages with a pinch of salt.
Sure, I am all for evaluating things on a case-by-case basis.
Would 'str_startswith' be confusing or harmful? I don't think so.
Would 'str_suffix_start' be confusing or harmful? I think less than
'strsuffix'; a programmer may wonder what the difference between 'strcat'
and 'strsuffix' is. (The name 'strsuffix' does not include a verb.
It can mean "test for a suffix" or "find a suffix" or "append a suffix"...)
> Consistency with libc is important too. If I see str_startswith(), I
> would guess it's a projec-specific API.
Wrong guess, because libc also has identifiers with underscores:
fe_dec_getround
atomic_compare_exchange
atomic_flag_test_and_set
atomic_flag_test_and_set_explicit
stdc_first_leading_zero_ull
memset_explicit
> > - I tried thinking in terms of parsing, i.e. "str_parse_prefix",
> > but what about the one with suffix then? "str_backwardparse_suffix"?
> > Backward parsing is rarely seen in code.
>
> That induces confusion. Does the function reverse the string as if by
> rev(1) before searching?
Yep, I agree that the verb "parse" is confusing in this context.
Bruno
