The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Robert Clausecker <fuz@fuz.su>
To: tuhs@tuhs.org
Subject: Re: [TUHS] buffer overflow (Re:  Happy birthday Morris worm
Date: Tue, 12 Nov 2019 23:41:51 +0100	[thread overview]
Message-ID: <20191112224151.GA36336@fuz.su> (raw)
In-Reply-To: <20191112221418.GJ16268@mcvoy.com>

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.  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;
    };

where data points to a buffer, len is the length of meaningful data in
that buffer and cap is the total buffer size.  This allows the language
to take subslices and to append to existing slices without requiring
copies in most cases.  If a copy is necessary, the runtime can allocate
a slightly larger buffer in advance to allow for appending in amortised
linear time.

Overall, much more versatile than Pascal strings.

But let's get back to the topic, after all I promised not to flame as
much as Jörg did.

Yours,
Robert Clausecker

On Tue, Nov 12, 2019 at 02:14:18PM -0800, Larry McVoy wrote:
> On Tue, Nov 12, 2019 at 02:10:46PM -0800, Bakul Shah wrote:
> > On Tue, 12 Nov 2019 15:56:15 -0500 Norman Wilson <norman@oclsc.org> wrote:
> > >
> > > My longer-term reaction was to completely drop my sloppy
> > > old habit (common in those days not just in my code but in
> > > that of many others) of ignoring possible buffer overflows.
> > > I find it mind-boggling that people still make that mistake;
> > > it has been literal decades since the lesson was rubbed in
> > > our community's collective noses.  I am very disappointed
> > > that programming education seems not to care enough about
> > > this sort of thing, even today.
> > 
> > Unfortunately strcpy & other buffer overflow friendly
> > functions are still present in the C standard (I am looking at
> > n2434.pdf, draft of Sept 25, 2019). Is C really not fixable?
> 
> Someone needs to do Strcpy() etc that have the length in the 
> first bytes[s] of the string.
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

  reply	other threads:[~2019-11-12 22:42 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-12 20:56 [TUHS] " Norman Wilson
2019-11-12 22:00 ` Dave Horsfall
2019-11-12 22:10 ` [TUHS] buffer overflow (Re: " Bakul Shah
2019-11-12 22:14   ` Larry McVoy
2019-11-12 22:41     ` Robert Clausecker [this message]
2019-11-12 22:49       ` Arthur Krewat
2019-11-12 23:45       ` Jon Steinhart
2019-11-13  0:38         ` Warren Toomey
2019-11-13  1:09         ` Arthur Krewat
2019-11-13  0:24       ` Larry McVoy
2019-11-12 22:54   ` Dave Horsfall
2019-11-12 23:22     ` Warner Losh
2019-11-12 23:27       ` Arthur Krewat
     [not found]     ` <alpine.DEB.2.20.1911191443530.10845@grey.csi.cam.ac.uk>
2019-11-21 20:02       ` Dave Horsfall
2019-11-21 20:38         ` Warner Losh
2019-11-21 21:04           ` Clem Cole
2019-11-21 22:06           ` Dave Horsfall
2019-11-21 21:48         ` Steffen Nurpmeso
2019-11-13  7:35 ` [TUHS] " arnold
2019-11-13 18:02   ` [TUHS] Happy birthday Morris worm [ really programming education ] Jon Steinhart
2019-11-13 18:49     ` Tyler Adams
2019-11-13 19:15     ` [TUHS] #defines and enums ron
2019-11-13 21:11       ` Warner Losh
2019-11-13 21:22     ` [TUHS] Happy birthday Morris worm [ really programming education ] Chet Ramey
2019-11-15 22:49     ` Adam Thornton
2019-11-15 23:59       ` Theodore Y. Ts'o
2019-11-12 22:39 [TUHS] buffer overflow (Re: Happy birthday Morris worm Norman Wilson
2019-11-13  1:43 ` John P. Linderman
2019-11-21 13:10   ` William Cheswick
2019-11-21 18:04     ` Steve Johnson
2019-11-21 21:51       ` John P. Linderman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191112224151.GA36336@fuz.su \
    --to=fuz@fuz.su \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).