If we are talking an ipheader how can the compiler ensure that length field is related to that type ? You would need some sort of special type or attribute that binds them together and if wrong field you are in unsafe.
Note we could creates slices like i suggested above from ip / tcp headers using unsafe code in the standard lib so the user is none the wiser ( the header would need to be in the lib) . We can also hijack string as the variable length byte[] storage underneath or directly use the unmanaged packet and dispose as needed. Ben On Mon, Sep 9, 2013 at 1:40 AM, Jonathan S. Shapiro <[email protected]>wrote: > On Mon, Sep 2, 2013 at 9:44 AM, David Jeske <[email protected]> wrote: > >> This is shap's complaint, as there is nothing "unsafe" about using a >> fixed-size array. As long as it's only for structs (with no subtyping) and >> the size is known at compile-time... >> > > If we really want to get picky, it's not at all hard to imagine using a > dependent type in which a read-only field holds the length and a later > block of data makes reference to that field to describe its length. This is > perfectly type safe. The use case would be network packet data structures. > > But that goes way beyond any type that CLR can describe. > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
