ben@home[1]:.../darcs/screened>cabal run darcs-test -- -j4 -s=u -
q=10000 -t betweenLinesPS -r=-4849332720703066203
Up to date
Using darcs executable in /home/ben/src/darcs/screened/dist-
newstyle/build/x86_64-linux/ghc-8.2.2/darcs-2.17.1/build/darcs/darcs
Locale encoding is UTF-8
:
  Darcs.Util.ByteString:
    betweenLinesPS behaves like its spec: [Failed]
*** Failed! Falsified (after 5306 tests):
"\STX"
"\n"
"\SOH\n\STX\n\n"
(used seed -4849332720703066203)

         Properties  Total      
 Passed  0           0          
 Failed  1           1          
 Total   1           1          

I am not sure what the precise precondition is but I guess it hardly 
matters: betweenLinesPS is obviously only meant to work for start/end 
*lines* IOW non-empty ByteStrings w/o any newlines in them. Indeed, 
strenghtening the precondition in this way rules out the above test 
case and seems to work, so I'll go for that. And document the 
precondition in the haddocks.

It turned out this QC test is almost worthless because with the given 
test case distribution the probability that the call to betweenLinesPS 
succeeds is practically zero. One way to improve the test is to choose 
characters from a (much) smaller set: with only ['a','b','\n'] allowed, 
we have at least a 6% chance that the arbitrary start and end lines 
actually appear (in order, i.e. first start, then end). This change 
quickly uncovered actual bugs in the implementation! Indeed, if the 
start or end line appears in the input but not as a complete line but 
rather as the end of an existing line, betweenLinesPS fails instead of 
searching further for a complete line.

See patch2237