Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
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] Copying null String/List introduces bugs #2834

Open
helehex opened this issue May 26, 2024 · 3 comments
Open

[BUG] Copying null String/List introduces bugs #2834

helehex opened this issue May 26, 2024 · 3 comments
Labels
bug Something isn't working mojo-repo Tag all issues with this label mojo-stdlib Tag for issues related to standard library [stdlib] core-library-q3-2024

Comments

@helehex
Copy link
Contributor

helehex commented May 26, 2024

Bug description

This has to do with how the default initializer creates a null pointer, but initializers with capacity=0 will still call alloc(0), and List.__copyinit__() always calls the one with capacity.

This could be solved on multiple different levels:

  • I recommend just checking if the pointer is null in List.__copyinit__() and using the default initializer in that case.
  • Or, we could always have list reserve at least 1
  • Or, we could track the null pointer better on the String level, or use the buffers length in String.__len__() instead of checking the state of the buffers underlying pointer. But this may not solve all the issues.
  • Or, we could call alloc(0) in the default initializer of List
  • Or, we could also check if the capacity=0 in the List initializer and give a null pointer instead, but it might be nice for empty lists to have an identity/address
  • Or, we could even have alloc(0) give a null pointer, but that's probably not the best
  • If List gets SBO, this problem may go away as long as things are handled properly

Steps to reproduce

var s1 = String()
var s2 = s1
print(len(s1)) # prints 0
print(len(s2)) # prints -1

System information

Host Information
  ================

  Target Triple: x86_64-unknown-linux
  CPU: skylake
  CPU Features: adx, aes, avx, avx2, bmi, bmi2, clflushopt, cmov, crc32, cx16, cx8, f16c, fma, fsgsbase, fxsr, invpcid, lzcnt, mmx, movbe, pclmul, popcnt, prfchw, rdrnd, rdseed, sahf, sgx, sse, sse2, sse3, sse4.1, sse4.2, ssse3, x87, xsave, xsavec, xsaveopt, xsaves

mojo 2024.5.2605 (9c328b12)

modular 0.8.0 (39a426b5)
@helehex helehex added bug Something isn't working mojo-repo Tag all issues with this label labels May 26, 2024
@gabrieldemarmiesse
Copy link
Contributor

gabrieldemarmiesse commented May 29, 2024

I think we can put this bug on hold until small buffer optimisation and small string optimisation land, then we'll have more options to fix the bugs and some of them might not even exist anymore

Copy link
Collaborator

Agreed. I'd punt on this for a little bit until the SSO/SBO work lands. We should totally figure out our longer-term null-terminated string strategy and FFI once that dust settles.

@JoeLoser JoeLoser added [stdlib] core-library-q3-2024 mojo-stdlib Tag for issues related to standard library labels Jun 11, 2024 — with Linear
@helehex
Copy link
Contributor Author

helehex commented Oct 13, 2024

The specific example in this issue is fixed, because String.__len__() now returns max(len(self._buffer) - 1, 0).
However, the root of the problem still exists in that copying a null list suddenly turns it into a 0 sized allocation. I'm still concerned that this is a potential point of confusion, and could end up causing other problems downstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working mojo-repo Tag all issues with this label mojo-stdlib Tag for issues related to standard library [stdlib] core-library-q3-2024
Projects
None yet
Development

No branches or pull requests

3 participants