On 08/24/2015 10:58 PM, Bartosz Gołaszewski wrote:
2015-08-24 21:29 GMT+02:00 Tito <farmat...@tiscali.it>:


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.
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_.
This suffix being non-existent is a anomaly that probably the caller
would like to be informed about.

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

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

To be honest this is the part of the series I don't really care much
about as opposed to the actual readahead patch that makes use of this
new function. Let's call it is_suffixed_with() to stay consistent with
is_prefixed_with() & make it return true for key="\0". The way it
works (including key="\0") shall be reflected in the comment
describing it. What do you think?

Hi,
this is a step in the right direction.

Thanks for your time and effort.

Ciao,
Tito
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to