Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Riches Newsgroups: comp.os.linux.misc Subject: Re: VMS Date: 25 Jun 2025 03:01:33 GMT Organization: none-at-all Lines: 43 Message-ID: References: <87tt4i9nw5.fsf@eder.anydns.info> <102l0h9$fjtb$5@dont-email.me> <4_GdncCsf-Nqe8n1nZ2dnZfqnPSdnZ2d@giganews.com> <103392c$lpbg$5@dont-email.me> <1033o4a$1qj6$3@dont-email.me> <1033tv1$3aqu$3@dont-email.me> <1034pj8$a74s$1@dont-email.me> Reply-To: spamtrap42@jacob21819.net Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net BeuV4cldJ0TBLbSzDW0XBQyz+eXjOlU5t0bHPx1p4/40WcApkH Cancel-Lock: sha1:RR3wBDv2uoSU60icf0gcm2Eniog= sha256:MhsEuEYzAaVJohoPmj91USAeOhvOqq0aRKGH7FS13N4= User-Agent: slrn/1.0.3 (Linux) On 2025-06-24, Richard Kettlewell wrote: > Robert Riches writes: >> On 2025-06-22, candycanearter07 >> wrote: >>> Aren't you supposed to multiply by sizeof as well? >> >> Multiply by sizeof what? sizeof(char)? This was in the >> pre-Unicode days. Even now with Unicode, IIUC sizeof(char) is >> still always 1. > > Yes. char is the unit in which sizeof measures things. Multiplying by > ‘sizeof (char)’ is a completely incoherent thing to do. > > And as noted elsewhere, doing the multiplication yourself is generally > the wrong approach. > >> IIUC, heap-based malloc _usually_ returns a larger allocation >> block than you really asked for. > > Yes. > >> As long as malloc gave you at least 2 extra bytes, you'd never see any >> misbehavior. Even if it didn't give you 2 or more extra bytes, it's >> fairly likely you'd just get lucky and never see the program crash or >> otherwise misbehavior in a significant way. For example, if you >> stomped on the header of the next allocation block, as long as nothing >> ever read and acted upon the data in said header, you'd never see it. > > This is wrong. Exceeding the space allocated by even 1 byte is undefined > behavior, even if the allocation happens to have been sufficiently > padded. What this means in practice is very situational but > optimizations exploiting the freedom that undefined behavior provides to > the compiler routinely result in defects. Please remember that this was an unintended _BUG_ in some old code, _NOT_ a deliberately chosen strategy. What I was describing was one possible explanation for how the bug remained undetected for some number of years. -- Robert Riches spamtrap42@jacob21819.net (Yes, that is one of my email addresses.)