AW: [RFC/PATCH v2 3/5] libbb: add ends_with() function

[dietmar.schindler at manroland-web.com]

> Von: Tito
> Gesendet: Montag, 24. August 2015 21:29
>
> On 08/24/2015 12:51 AM, Jody Bruchon wrote:
> > On 2015-08-21 17:26, Tito wrote:
> >> what sense would it make to check if str\0 ends_with \0 if all strings
> >> do end with \0 ?
> >
> > In this case, I view this as a problem of handling all possible valid
> > inputs in a robust manner. It can also make the code more efficient
> > since \0 is just another byte and is guaranteed to be at the end of any
> > valid string, thus solving the problem of what to do when passed an
> > empty (but properly zero-terminated) string without having to add code
> > for a special case and/or add parameters for string lengths.
> >
> > It does not matter that "ends with <empty>" is a comparison that almost
> > certainly serves no practical purpose in the code calling it; what
> > matters is that the behavior is consistent if the calling code is silly
> > enough to pass empty strings and expect a meaningful response.
>
> Hi Jody,
> so you pass the buck to the silly caller to guess what is consistent,
> but even in the few replies on this thread there were different views
> about it.

To add a data point: I vote for Jody Bruchon's coherent view.

> In my opinion it would be better to cover such corner cases with
> meaningful responses by analyzing the semantics of this new function
> that checks if a _string_ ends with a specific _string_ or as somebody
> suggested a specific _suffix_.

An empty string is a string also; treating it accordingly is meaningful.

> This suffix being non-existent is a anomaly that probably the caller
> would like to be informed about.

Calling it an anomaly is a personal choice; I'd call it a normal extreme case.

> > If a useless answer for empty strings is a problem, the writer of the calling
> > code needs to handle that themselves, and is in a far more flexible
> > position to do so than the person writing the called function that only
> > answers "yes" or "no."
>
> Why should a function give a useless answer?
> Wouldn't it be better for the caller to give him
> always useful answers (return different values, set errno, etc.).

We cannot predict the usefulness of all possible cases, so this question implies an unprovable assumption.

> > I also say that we're all C programmers if we're here fiddling with the
> > guts of BusyBox and we can all easily understand why returning "yes" for
> > "ends with \0?" is a technically correct result since all C strings end
> > with \0.
>
> This is a somewhat dogmatic argument:
> "The people of the inner circle know it better."
>
> SusV3 instead for the strstr function of which ends_with() could be
> considered a subset of functionality (just looks for s2 at the end of
> s1) says:
>
> "#include <string.h>
>
>      char *strstr(const char *s1, const char *s2);
>
> DESCRIPTION
>
>      The strstr() function shall locate the first occurrence in the
> string pointed to by s1 of the sequence of bytes (excluding the
> terminating null byte) in the string pointed to by s2.
>
> RETURN VALUE
>
>      Upon successful completion, strstr() shall return a pointer to the
> located string or a null pointer if the string is not found.
>
>      If s2 points to a string with zero length, the function shall
> return s1.
>
> ERRORS
>
>      No errors are defined."
>
> So as you can see they explicitly request a specific action for the case
> of a zero length key:
>
>      "If s2 points to a string with zero length, the function shall
> return s1."
>
> Not that I like their solution but still this is a fact and makes me
> think that we should also handle this corner case in better way
> rather than return a "useless value".

We see that the strstr() function also does not handle a string with zero length in any special way; the manual just states explicitly what results from normal proceeding according to the description.
--
Best regards,
Dietmar Schindler
________________________________
manroland web systems GmbH -- Managing Director: Joern Gosse
Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No.: 26816 -- VAT: DE281389840

Confidentiality note:
This eMail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you have received this eMail in error, then please delete this eMail.

! Please consider your environmental responsibility before printing this eMail !
________________________________