* [COFF] [TUHS] buffer overflow (Re: Happy birthday Morris worm [not found] ` <CANCZdfrnOfxV-TP09Ye15FVLKuZAAudEd=FQ-iULgE1js4ra4Q@mail.gmail.com> @ 2019-11-13 1:11 ` dave 2019-11-13 1:14 ` dave 0 siblings, 1 reply; 3+ messages in thread From: dave @ 2019-11-13 1:11 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1300 bytes --] (Narrowly diverted in time to COFF from TUHS when I saw Warren's email, so I hope Warner is on it.) On Tue, 12 Nov 2019, Warner Losh wrote: > POSIX can't even recognize that leap seconds exist :( There's a movement afoot to abolish leap seconds because they are "inconvenient" or something; that will upset the astronomers and other people who care about the exact time. > All is not lost, though; use strncpy() instead of strcpy() etc. > > strncpy has two issues. First, it doesn't guarantee NUL termination. > Second, it always writes N bytes. It's for a fixed width data field, not > a variable length string whose buffer size is known. strlcpy is much > better, but still has some issues... Yeah, I knew about the NUL termination (or lack of it) - I didn't think to mention it. When I use it, I copy n-1 bytes and plant the NUL in there myself (depending on how I'm using it). And I wasn't aware of strlcpy() - thanks. Too many functions to keep track of these days.... Trivia: curious to see how Australia's "talking clock" (long gone in favour of NTP, alas) handled the leap second, I recorded it (it puts a gap before the last beep). It can be heard (and seen!) over on www.horsfall.org/leapsecond.webm . And yes, that old long-haired hippie is me... -- Dave ^ permalink raw reply [flat|nested] 3+ messages in thread
* [COFF] [TUHS] buffer overflow (Re: Happy birthday Morris worm 2019-11-13 1:11 ` [COFF] [TUHS] buffer overflow (Re: Happy birthday Morris worm dave @ 2019-11-13 1:14 ` dave 0 siblings, 0 replies; 3+ messages in thread From: dave @ 2019-11-13 1:14 UTC (permalink / raw) On Wed, 13 Nov 2019, Dave Horsfall wrote: > Trivia: curious to see how Australia's "talking clock" (long gone in favour > of NTP, alas) handled the leap second, I recorded it (it puts a gap before > the last beep). It can be heard (and seen!) over on > www.horsfall.org/leapsecond.webm . Jeeze; that didn't take long :-) Yes, I monitor my logs... -- Dave ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <20191112221418.GJ16268@mcvoy.com>]
[parent not found: <20191112224151.GA36336@fuz.su>]
[parent not found: <5d8d9933-1213-3f07-02e0-f3ad5c293de4@kilonet.net>]
* [COFF] [TUHS] buffer overflow (Re: Happy birthday Morris worm [not found] ` <5d8d9933-1213-3f07-02e0-f3ad5c293de4@kilonet.net> @ 2019-11-13 8:37 ` peter 0 siblings, 0 replies; 3+ messages in thread From: peter @ 2019-11-13 8:37 UTC (permalink / raw) On 2019-Nov-12 17:49:46 -0500, Arthur Krewat <krewat at kilonet.net> 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: <http://minnie.tuhs.org/pipermail/coff/attachments/20191113/0564e548/attachment.sig> ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-11-13 8:37 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1573592179.5935.for-standards-violators@oclsc.org> [not found] ` <20191112221053.C2009156E80B@mail.bitblocks.com> [not found] ` <alpine.BSF.2.21.9999.1911130944090.11612@aneurin.horsfall.org> [not found] ` <CANCZdfrnOfxV-TP09Ye15FVLKuZAAudEd=FQ-iULgE1js4ra4Q@mail.gmail.com> 2019-11-13 1:11 ` [COFF] [TUHS] buffer overflow (Re: Happy birthday Morris worm dave 2019-11-13 1:14 ` dave [not found] ` <20191112221418.GJ16268@mcvoy.com> [not found] ` <20191112224151.GA36336@fuz.su> [not found] ` <5d8d9933-1213-3f07-02e0-f3ad5c293de4@kilonet.net> 2019-11-13 8:37 ` peter
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).