Path: csiph.com!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: High level programming in C Date: Tue, 21 Nov 2017 12:52:45 -0800 Organization: None to speak of Lines: 42 Message-ID: References: <979bb888-53e1-410b-b013-1ace6c8dc0ad@googlegroups.com> <1d54853a-79c7-4b7b-8666-51d26cc35b3d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="9437c726f685efabd2d584afa836bd7f"; logging-data="6946"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/EdwEZhkLuWW3xT/uxIua9" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:d815dd2xGETdYnDRR3OXtMmtmks= sha1:PERMoLAUKfihuserktUQ448NtyU= Xref: csiph.com comp.lang.c:123210 supercat@casperkitty.com writes: > On Tuesday, November 21, 2017 at 1:29:36 PM UTC-6, Keith Thompson wrote: >> For example, strlen(NULL) has undefined behavior. The standard >> *could* have specified the behavior of strlen(NULL) somehow (perhaps >> returning (size_t)-1 and setting errno, for example), but there's >> no portable way to check for invalid pointer values other than NULL. > > When the Standard was written, there may quite plausibly have been > implementations where strlen(NULL) would reliably returned zero, and > some code for such implementations may plausibly have relied upon such > behavior. There might also have been implementations where it would > reliably return (size_t)-1 or some other "special" value, and some > code for those implementations might plausibly have relied upon that. I've read an article about, if I recall correctly, the transition from 68k to SPARC for SunOS (not sure of the details, but it doesn't really matter). On the older system, memory location 0 was readable and happened to contain a zero byte, so strlen(NULL) would actually return 0, and some code used null pointers to represent empty strings. When code was ported to the newer system, a lot of it broke because memory location 0 was not writable. (The older and newer systems both used address 0 to represent the null pointer.) > If the Standard had required any particular behavior for strlen(NULL), > that could have made it impossible for some implementations to be made > conforming without breaking existing code--something the authors of > the Standard were very keen to avoid. By contrast, leaving the behavior > undefined won't break anything as long as implementers use the resulting > freedom to implement behavior compatible with existing programs. The standard didn't require any particular behavior for strlen(NULL), and existing code broke. That existing code depended on behavior that was not guaranteed by the language. The code was fixed. That's a risk of using a language like C. Other languages choose different tradeoffs. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"