Fix the characteristic that the trim() and trim_end() functions do not remove the \0 character.#620
Fix the characteristic that the trim() and trim_end() functions do not remove the \0 character.#620Enet4 merged 2 commits intoEnet4:masterfrom bowenxuuu:master
Conversation
…_matches([' ', '\u{0}']) function. Because the trim() / trim_end() function in Rust does not remove the \0 character.
Enet4
left a comment
There was a problem hiding this comment.
I have standardized the codebase by uniformly substituting the
trim()andtrim_end()functions with thetrim_end_matches([' ', '\u{0}'])function, which was replicated from theto_str()function within theprimitive.rsfile.I am rather uncertain as to the rationale behind the concurrent existence of the
trim()andtrim_end()andtrim_end_matches([' ', '\u{0}'])functions in the previous implementation. Was this a deliberate design choice?
I believe that the occurrences of both trim* and trim_end* are indeed deliberate. This is because some values admit both leading and trailing whitespace. https://dicom.nema.org/medical/dicom/2024d/output/chtml/part05/sect_6.2.html In the cases where trim() was called, please retain the begin trimming.
Moreover, I am pondering whether it might be more apt to utilize the
trim_matches(|c: char| c == '\0' || c.is_whitespace())function instead. However, I remain indecisive on this matter.
I would stick to checking specifically for spaces, as that is what's listed by the standard. is_whitespace may cover more cases of whitespace than necessary and/or intended.
|
Hello @Enet4 , |
Enet4
left a comment
There was a problem hiding this comment.
Should be OK. Anyone depending on the presence of nul characters in the output should be using the raw string method variants intead.
Thank you for your contribution @xb284524239. 👍
fix #618
Hello @Enet4 ,
I have standardized the codebase by uniformly substituting the
trim()andtrim_end()functions with thetrim_end_matches([' ', '\u{0}'])function, which was replicated from theto_str()function within theprimitive.rsfile.I am rather uncertain as to the rationale behind the concurrent existence of the
trim()andtrim_end()andtrim_end_matches([' ', '\u{0}'])functions in the previous implementation. Was this a deliberate design choice?Moreover, I am pondering whether it might be more apt to utilize the
trim_matches(|c: char| c == '\0' || c.is_whitespace())function instead. However, I remain indecisive on this matter.