On Wednesday, January 24, 2018 18:46:38 Walter Bright via Digitalmars-d wrote: > On 1/23/2018 7:22 PM, Jonathan M Davis wrote: > > We need to do that anyway for the overly large > > objects (and unfortunately don't last I heard). > > I put a limit in at one time for struct/class sizes to prevent this issue, > but got a lot of pushback on it and it was reverted. > > Perhaps we can revisit that - and have large struct/classes be allow only > in non-@safe code. > > In general, though, if you don't have struct/class object sizes larger > than the protected memory at null, you're safe with null dereferences.
Yes, but we need to do _something_ about the overly large structs/classes if we want @safe to be bulletproof like it's supposed to be (barring misuse of @trusted, of course). I'd be inclined towards adding extra null-checks in those cases just because you'd end up with a balooning of @system code in your code if we made dereferencing pointers/references to them @system, but regardless, the important thing is that we do something with them (whatever that may be) so that we don't have code that the compiler claims to be @safe and then goes and does something naughty with memory. Right now, those types are a lot like dynamic arrays with -noboundscheck except that the programmer didn't knowingly choose to be unsafe. Personally, I doubt that I've ever written code with types that large, but I really have no idea, because I don't know what the boundary is. I just know that I don't usually have really large types. But right now, it probably wouldn't be all that hard to shoot yourself in the foot by having a particularly large static array, and most folks would probably have no idea that they were making it so that they wouldn't get segfaults on null. The only reason that I know that that's possible is because of previous discussions on the topic here in the newsgroup, and I'm sure that plenty of other folks are in the same boat except that they haven't read those discussions and so still have no clue about it. - Jonathan M Davis
