Hi Collin, The new patch is good. OK to push.
> However with this in my /etc/shells: > > ================ > /bin/bash > / > =============== > > When printing all shells glibc prints both lines. Mine only prints > "/bin/bash". > > Strange function, in my opinion. However, lets trust the BSD and glibc > developers who wrote it over me. :) No need to change it's behavior. Yes, the function is only meant to extract words from a file consisting of lines with comments. Not to eliminate words based on semantic considerations. > Interesting way to think about it, thanks. Do you have a strong math > background? It has been a while since I looked at that interval > notation. Oh, I learned the interval notation at school. It's really nothing fancy. > Typically the way I think of things is using a "cursor", which I guess > is just a pointer to a position in a known data structure. > > So in that patch we have something like this: > > start end > ^ ^ > | | > [1] [2] [3] [4] [5] [6] [7] [8] > '/' 'b' 'i' 'n' '/' 's' 'h' '\0' > > Which would be [start,end] since *start and *end are part of the > string. The problem with the [start,end] convention is that it cannot represent an empty array slice. Therefore, when you are dealing with a problem in which an empty array slice is a valid special case, [start,end] is the wrong representation. Try to formulate a non-trivial algorithm, such as bubble sort or searching an item in a sorted array using binary-search. If you do it ad-hoc with cursors or some such, chances a high that you will introduce off-by-one mistakes or endless loops. Try it with the [start,end) convention, and you will succeed. > I've attached the patch which I think follows your suggestion of > [start, end): > > start end > ^ ^ > | | > [1] [2] [3] [4] [5] [6] [7] [8] > '/' 'b' 'i' 'n' '/' 's' 'h' '\0' > > I guess that probably makes everything easier for others to follow. Yes. Thanks! Bruno
