RFC: Deprecate r_str_new and r_str_dup

[trufae]

• r_str_dup
• r_str_new
• R_STR_DUP
• r_str_ndup / r_str_newlen

It can be tricky for rmalloc as strdup uses libc's malloc and r_str could use r_malloc alternative, causing inconsistencies between new/free and overcomplicates the logic. so maybe we can just move forward and just use strdup and deprecate those.

About r_str_new that could be kept for consistency with r_str_newf()

strdup() is available everywhere and works the same.

[trufae]

its anoying to my eyes. but not really a blocker, moving forward

[Ashishbsharma]

Hi, I'd like to contribute to this issue, please guide me where to start.

[trufae]

As long as this is an abi breaking change this can't be done until we reach 5.9.9.

What can be done before:

• remove the use of all those calls to use only strdup()
• decide/discuss if its needed to have a nullchk version (as a macro) R_STRDUP (or R_STR_DUP?)

What can't be done:

• remove the public functions

[trufae]

Feel free to join the discord for further discussions

[satk0]

Hey, is this issue still not resolved? I can take it if you don't mind.

IMHO, being more careful is more important than being less, so I would opt for creating a new R_STRDUP nullcheck macro and replace all R_STR_DUP occurences with it to avoid any old api confusions.

As far as I understand, the r_str_ndup / r_str_newlen should be replaced with strndup, right?

Moreover, I've found some syntax mistakes with invoking strdup (strdup( instead of strdup (). I could correct it too.

[trufae]

thank you @satk0 !!