I'm confident that strings are both null terminated and not null terminated
I'm confident that strings are both null terminated and not null terminated
Kit depends
Kas anything
Kthere is a special field
Kexhibit a)
Kagain, strings are generally considered to be null terminated
Kbut this is not a guarantee by any means
Kin fact, depending on roslyn codegen, it may even be null terminated three times
Kbut strings are apparently stored only in increments of two, so sometimes part of the string is stored in the sync block
Tpretty sure that strings are meant to be null-terminated as part of the spec
K(that last behaviour is apparently specific to BStr, and also one of the reasons external marshalling code like ours are never 1:1 correct)
Kyes, they should be if marshalled correctly
KI don't think the spec lines out anything about how a runtime needs to lay out it's types
Tok the c# spec does not outline it. although it has been discussed on the c# server before
it was a "all runtimes do it so it's basically safe to rely on it"
it was a "all runtimes do it so it's basically safe to rely on it"
Ayup, pretty much that's that
Abut that's implementation detail, probably added in order to speed up Win32 calls
Amatter-of-factly, you can't even check if C# string has a null terminator or not from safe context
Tref arithmetic wants to know your location
Aso some safe-only runtimes may have non-null-terminated strings just fine and no one would ever know
Thold on. do safe-only runtimes even exist?
Ayeah, if you're old enough to remember Windows Phone and Silverlight and WinRT and company
AI coded on Windows Phone 7 back in a day, that was quite a performance shitshow with all the limitations
Tso it was basically microsoft java, got it
Apretty much, yes
Aoh, also, no emit
and mostly no reflection in general
probably something else too...
and mostly no reflection in general
probably something else too...
SIs that so called
ILStub?Encoding.UTF8.GetByteCount ewwKThat is the official P/Invoke stubs yes
Aand what's wrong with GetByteCount?
SIt actually does conversion behind the scenes (afaik)
Athat's normal C++ish pattern for doing stuff when memory is caller-allocated
Ayou do a dry run to figure out the memory requirements, allocate memory and then do actual run with allocated memory
SI allocate
(len+1)*3+1 bytesSAnd then encode utf8 data to it
Athat's because you're not developing any frameworks
Aor runtimes 
Aotherwise you'd be rather hated for wasting THAT much memory
A...or even not running your code in 32bit mode
SIt actually isn't used here.
I use 1024 bytes of stack memory
I use 1024 bytes of stack memory
SRegardless of what i actually need
SCuz performance
S(That i never had problems with there)
SI have defines for CONSERVATIVE STACK and CONSERVATIVE HEAP btw, they're compiling options
KI mean that is literally what is done in other places, the P Invoke stubs are generate very well optimized. I'm assuming they have a good reason why the length was required here (feel free to go back and check, can't be bothered rn)
Aeasy: imagine string with 1073741791 characters
Aor even 715827882
Aand before you ask - yeah, I've seen systems operating on such strings
PI mean, all you’d need to do is try to marshal the bee movie script and suddenly your system doesn’t cut it
Aalso, memory is not always free, there's cost for having 3x mem usage
P@alexx999_ sorry for the delay, will have a poke around your draft PR now!
Abtw, I can prove that moving structs is not a breaking change
Khate to brag, but 14 lines of change to go from empty struct to struct with full member functionality https://github.com/dotnet/Silk.NET/commit/f948995066801ddd53b0cc9d8363f1ca84c18485
Don't think I've ever managed incremental dev to this degree
Don't think I've ever managed incremental dev to this degree