Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Isn't that beauty ? (no it's not) Date: Sun, 15 Mar 2026 13:15:56 -0700 Organization: A noiseless patient Spider Lines: 51 Message-ID: <8634207ssj.fsf@linuxsc.com> References: <10otm7r$1ntrg$1@raubtier-asyl.eternal-september.org> <10ougtt$21vgj$1@dont-email.me> <10ouhm6$22rm2$1@raubtier-asyl.eternal-september.org> <10ouje5$21vgj$5@dont-email.me> <10oul1g$241b4$1@raubtier-asyl.eternal-september.org> <10ov73a$2bugo$3@dont-email.me> <10p03uu$2nho7$1@dont-email.me> <10p07kn$2pg89$1@dont-email.me> <%jVsR.22274$_l2.6511@fx40.iad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sun, 15 Mar 2026 20:16:00 +0000 (UTC) Injection-Info: dont-email.me; posting-host="37fbd2bc0a39a2e0da8dcfefffa00bf6"; logging-data="1460169"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+hp/MDqvg3KnSlonZ5lBif1kGQXwgHs8g=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:LGu9IsRXdGqWRIJxERabGKwnVww= sha1:A9LXBCs1lzzuxoJy49sir8MHHhw= Xref: csiph.com comp.lang.c:397006 scott@slp53.sl.home (Scott Lurndal) writes: > scott@slp53.sl.home (Scott Lurndal) writes: > >> DFS writes: >> >>> On 3/13/2026 12:31 AM, DFS wrote: >>> >>>> On 3/12/2026 8:54 PM, Scott Lurndal wrote: >>>> >>>>> DFS writes: >>> >>> >>> >>>> I took out all 7 instances of error trapping, and it throws: >>>> Floating point exception (core dumped) >>>> at line 61 or 62 >>> >>> Put back in just the stat() call >>> >>> stat(argv[1], &st); >>> >>> and the program works again. >> >> Yes, you can't willy-nilly remove lines from a program. >> >> >>> Question: wordlist was malloced with a size of 0: >>> >>> wordlist = malloc(wordcount * sizeof(const char *)); >>> >>> Why are you allowed to malloc size 0? >> >> "If the size of the space requested is 0, the behavior is >> implementation-defined: either a null pointer shall be returned, >> or the behavior shall be as if the size were some non-zero value, >> except that the behavior is undefined if the returned pointer is >> used to access an object." >> >> https://pubs.opengroup.org/onlinepubs/9799919799/functions/malloc.html > > IIRC, this caveat was added due to differences in the malloc(3) > implementations for System V Unix and BSD Unix. That sounds right, except I might say "put in" rather than "added" since as best I can determine that allowance was present in the earliest drafts of the C standard and POSIX discussions. Note that malloc() is not mentioned in K&R, and apparently was added to AT&T Unix in Unix V7. The timing on that was about the same time as the first BSD Unix.