[Bro-Dev] [JIRA] (BIT-757) Change split* to return a string_vec rather string_array

Jon Siwek (JIRA) jira at bro-tracker.atlassian.net
Tue Jan 20 09:59:00 PST 2015


    [ https://bro-tracker.atlassian.net/browse/BIT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19506#comment-19506 ] 

Jon Siwek commented on BIT-757:
-------------------------------

Bah, this is related to BIT-924: these functions are using 1-based indexing.  So changing them to return a vector also begs to treat them like vectors commonly are w/ 0-based indexing.  And changing the indexing scheme deserves a method of deprecating or ability to switch between a 0-based versus 1-based indexing "policy", so that we don't silently break code that people have written which depends on the original 1-based indexing.

I am thinking the easiest/quickest way is to add new functions, name them appropriately w/ intention that they'll stick around for the long haul, add a sort of &deprecated attribute to split() and friends, and then later remove those deprecated functions.  Let me know if there's other opinions.

> Change split* to return a string_vec rather string_array
> --------------------------------------------------------
>
>                 Key: BIT-757
>                 URL: https://bro-tracker.atlassian.net/browse/BIT-757
>             Project: Bro Issue Tracker
>          Issue Type: Problem
>          Components: Bro
>    Affects Versions: git/master
>            Reporter: Matthias Vallentin
>            Assignee: Jon Siwek
>              Labels: language
>             Fix For: 2.4
>
>
> Currently, `{{split}}{{ and friends return a }}{{string_array}}{{, which is a }}{{table[count] of string}}{{. However, these BiFs should return a }}{{string_vec}}{{ or }}{{vector of string}}{{ to allow for sequential iteration over the result. The problem with the current approach is not only that it is wrong modeled (the associative container does not make sense), but also that iteration over the elements, which are obviously ordered, is neither deterministic nor sequential. Presumably this mismatch exists because vectors were not available when the }}{{split*}}` functions have been created.



--
This message was sent by Atlassian JIRA
(v6.4-OD-13-026#64011)


More information about the bro-dev mailing list