Change in libosmocore[master]: add osmo_str_startswith()

Harald Welte gerrit-no-reply at lists.osmocom.org
Wed Mar 27 07:48:38 UTC 2019


Harald Welte has posted comments on this change. ( https://gerrit.osmocom.org/13394 )

Change subject: add osmo_str_startswith()
......................................................................


Patch Set 1:

(4 comments)

So I'm happy with adding this new function, but I'm worried about the explanation given in the commitlog and your plan to fix this on the callback side of every VTY function rather than in the libosmovty core.

https://gerrit.osmocom.org/#/c/13394/1//COMMIT_MSG
Commit Message:

https://gerrit.osmocom.org/#/c/13394/1//COMMIT_MSG@20
PS1, Line 20: 
            : One could expect the VTY to then pass the unambiguous match of "apples" to the
            : parsing function, but that is not the case.
why not "simply" change the VTY internals to adjust its behavior around our existing assumptions?


https://gerrit.osmocom.org/#/c/13394/1//COMMIT_MSG@24
PS1, Line 24: Hence a VTY function implementation is faced with parsing a keyword of "app"
            : instead of the expected "apples".
that's *really* unexpected and odd.  It should definitely be fixed inside the VTY library and not in applications.


https://gerrit.osmocom.org/#/c/13394/1//COMMIT_MSG@28
PS1, Line 28: I am now writing new
            : commands in a way that are able to manage only the starts of keywords
Please don't.  Let's rather fix it once in the parser.  If the parser matches "app" against "apples" but then passes "app" into the function, it may very well pass "apples" instead and make everyone happy, including the hundreds of existing functions.

Alternatively, we may simply requrie the user to pres "tab" until the full keyword is entered.  That's how I've used Osmocom VTYs during the past decade.


https://gerrit.osmocom.org/#/c/13394/1//COMMIT_MSG@31
PS1, Line 31: Arguably, strstr(a, b) == a does the same thing, but it searches the entire
> Why is that a problem exactly? Why do we need in our API smth which duplicates <string. […]
see the code. Because strstr would also match strings at other offsets than 0, massively increasing the required CPU to compute something we're not interested in anyway.



-- 
To view, visit https://gerrit.osmocom.org/13394
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: Ib2ffb0e9a870dd52e081c7e66d8818057d159513
Gerrit-Change-Number: 13394
Gerrit-PatchSet: 1
Gerrit-Owner: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-Reviewer: Max <msuraev at sysmocom.de>
Gerrit-CC: Harald Welte <laforge at gnumonks.org>
Gerrit-Comment-Date: Wed, 27 Mar 2019 07:48:38 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190327/e152d940/attachment.html>


More information about the gerrit-log mailing list