From mboxrd@z Thu Jan 1 00:00:00 1970 From: peter at rulingia.com (Peter Jeremy) Date: Wed, 13 Nov 2019 19:37:26 +1100 Subject: [COFF] [TUHS] buffer overflow (Re: Happy birthday Morris worm In-Reply-To: <5d8d9933-1213-3f07-02e0-f3ad5c293de4@kilonet.net> References: <1573592179.5935.for-standards-violators@oclsc.org> <20191112221053.C2009156E80B@mail.bitblocks.com> <20191112221418.GJ16268@mcvoy.com> <20191112224151.GA36336@fuz.su> <5d8d9933-1213-3f07-02e0-f3ad5c293de4@kilonet.net> Message-ID: <20191113083726.GF50716@server.rulingia.com> On 2019-Nov-12 17:49:46 -0500, Arthur Krewat wrote: >On 11/12/2019 5:41 PM, Robert Clausecker wrote: >> Oh please no. One of the things we've hopefully all learned from Pascal >> is that length-prefixed strings suck because you can't perform anything >> useful without copying the entire string. Keep in mind that C doesn't have a "string" type. The use of a NUL terminated char array is purely convention. There's nothing to stop someone using a length-prefixed array (though there's virtually no standard library support for that). >> Rob Pike and friends showed >> how to get strings and vectors right in the Go language where you have a >> builtin slice type which is essentially a structure >> >> struct slice(type) { >> type *data; >> size_t len, cap; >> }; That approach would have incurred a 12-byte overhead for each string or vector on a PDP-11 - that would have been a substantial disincentive on a memory-constrained system. >And none of that stops some programmer from doing slice.cap=255 - or is >it read-only? ;) Slices and strings are built-in types in Go. They can be modelled as the above structure but that is an implementation detail. It is possible to reduce the capacity of a slice (but not a string) but attempting to increase it will result in a runtime exception ("panic" in Go speak). -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: