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

utf8upr/lwr size issues? #106

Open
ghost opened this issue Nov 30, 2022 · 3 comments
Open

utf8upr/lwr size issues? #106

ghost opened this issue Nov 30, 2022 · 3 comments

Comments

@ghost
Copy link

ghost commented Nov 30, 2022

Hi, I was looking at the docs for utf8upr/lwr, and they don't seem to indicate what happens if the string passed to them doesn't have enough space for the new codepoints. I understand that letters may have different byte sizes in their upper/lowercase variants, so I was wondering whether utf8upr/lwr will allocate extra memory as required.

Looking at the code, though, it seems like they just call utf8catcodepoint, which AFAIK doesn't allocate additional memory. In fact, the size argument in that call is set to the size of the new codepoint, rather than the size of the buffer as it should be. Is this correct?

@sheredom
Copy link
Owner

So utf8upr and utf8lwr rely on the only codepoints we currently support for them are all symmetrically sized - their replacements are the same size. If that ever changed we'd be scunnered!

@ghost
Copy link
Author

ghost commented Dec 1, 2022

@sheredom thanks for the response. Is this documented anywhere? If not, it definitely should.

Also, what happens with the size argument to utf8catcodepoint? Is it correct that we pass the size of the new codepoint instead of the buffer's?

@sheredom
Copy link
Owner

sheredom commented Dec 2, 2022

It isn't documented, so I'll do a PR. I think the size is fine only because all our replacements the size is the same between the original and the new!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant