Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug in str_splits #124

Closed
SamSandq opened this issue Apr 2, 2024 · 3 comments
Closed

Bug in str_splits #124

SamSandq opened this issue Apr 2, 2024 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@SamSandq
Copy link

SamSandq commented Apr 2, 2024

The function str_splits does not work with empty splits. This works:

    const char_t *test1 = "1|2|3|4";

    ArrPt(String) *pieces1 = str_splits(test1, "|", FALSE);
    bstd_printf("Size: %d\n", arrpt_size(pieces1, String));

    arrpt_foreach(c, pieces1, String);
        bstd_printf("%s ", tc(c));
    arrpt_end();

it prints

Size: 4
1 2 3 4

However, this does not:

    const char_t *test2 = "1|2||4";

    ArrPt(String) *pieces2 = str_splits(test2, "|", FALSE);
    bstd_printf("Size: %d\n", arrpt_size(pieces2, String));

    arrpt_foreach(c, pieces2, String);
        bstd_printf("% \n", tc(c));
    arrpt_end();

It prints:

Size: 3
1 2 4

But it should handle the two consecutive separators correctly, and print:

Size: 4
1 2  4 

(i.e., the 3rd piece is the empty string).

The trim flag does not affect this behaviour, except that it's actually worse: for a string "1|2| |4" it seems to trim first, and then decide to ignore the empty 3rd piece, and print the size as 3, and the pieces as the incorrect example above.

@frang75 frang75 self-assigned this Apr 2, 2024
@frang75 frang75 added the bug Something isn't working label Apr 2, 2024
@frang75
Copy link
Owner

frang75 commented Apr 4, 2024

Fixed in commit: 845c4c0
The trim and add_empty are diferent operations. Added a new function parameter.
https://nappgui.com/en/core/string.html#f52

@SamSandq
Copy link
Author

SamSandq commented Apr 4, 2024

Nice solution, even if not backwards compatible.

@frang75
Copy link
Owner

frang75 commented Apr 4, 2024

Yes it's correct. I am considering introducing a deprecation system. But, for the moment, it will bring more complications than benefits. In general, the public API is quite stable.

@frang75 frang75 closed this as completed Apr 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants