[erlang-bugs] binary:matches/3 fails in R14A

[Tuncer Ayaz]

On Fri, Feb 1, 2013 at 12:04 PM, Jesper Louis Andersen wrote:
> binary:replace/X and binary:split/X do understand the 'global' atom.
> So it depends on what kind of call there is made.

Actually, binary:matches/X searches Subject until exhausted. So, maybe
binary:match/X should allow 'global' to operate like binary:matches/X.
Does that make sense?

> On Thu, Jan 31, 2013 at 10:40 PM, Tuncer Ayaz wrote:
>>
>> On Thu, Jan 31, 2013 at 10:31 PM, Fred Hebert wrote:
>> > I'm looking at the doc at
>> > http://www.erlang.org/doc/man/binary.html#matches-3
>> >
>> > The type spec mentions the following:
>> >
>> >     matches(Subject, Pattern, Options) -> Found
>> >
>> >     Types:
>> >     Subject = binary()
>> >     Pattern = binary() | [binary()] | cp()
>> >     Found = [part()]
>> >     Options = [Option]
>> >     Option = {scope, part()}
>> >     part() = {Start :: integer() >= 0, Length :: integer()}
>> >
>> > It seems [global] as an option is not valid. Could this be the
>> > problem? I was under the impression `re` functions would take a
>> > `global` option, not `binary` module stuff.
>>
>> Yeah, you're probably right, I may have been misled by previous
>> re:run/3 use :).
>>
>> > On 01/31, Tuncer Ayaz wrote:
>> >> Originally reported by Bartosz Kolodziej as part of [1]
>> >> is the following a bug or intentionally throwing badarg?
>> >>
>> >> 1> binary:matches(<<>>,<<"a">>,[global]).
>> >> ** exception error: bad argument
>> >>      in function  binary:matches/3
>> >>         called as binary:matches(<<>>,<<"a">>,[global])
>> >>
>> >> Tested with otp.git at 68b804f.
>> >>
>> >> [1] http://erlang.org/pipermail/erlang-bugs/2010-August/001967.html
>> >> [2] http://erlang.org/pipermail/erlang-bugs/2011-December/002693.html