Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: C wish list Date: Sun, 24 Mar 2019 21:54:36 -0700 Organization: None to speak of Lines: 37 Message-ID: References: <18RkE.296542$DH4.255445@fx24.am4> <1d54b052-49e7-4aee-a4cc-a394a0a77886@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="784bbd8fb1c90ff7036d4663e7b2295d"; logging-data="1232"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1858smDCV7NxpY3WOB9a/Vq" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:MEWvJe/6SaXLb2oDMJG0YJ/LNhU= sha1:56y6HAUkYtyb8NIStT/TwwpLBJI= Xref: csiph.com comp.lang.c:142393 Howard Chu writes: [...] > The rule that pointers from different objects can't be compared is somewhat > meaningless. The malloc and free functions need to be able to compare their > arguments against their heap boundaries, at least. And for that to be legal > for them to do, the heap itself must be a single character array. But if the > heap *is* a single character array, that means that all pointers returned > from malloc are actually part of a single object, and thus should be legal > to compare to each other, regardless of what kind of structure/type the > caller uses them for. The heap might be *implemented* as a single character array, but it's not an object as far as C is concerned. This code fragment: char *a = malloc(1); char *b = malloc(1); a < b; has undefined behavior (unless, I think, one of the pointers happens to point just past the object pointed to by the other pointer) -- regardless of how malloc is implemented. > Meanwhile, on a system where the heap is implemented by something like mmap() > which can return discontiguous memory regions on subsequent calls, the C spec > says you're screwed, you can't legally compare the pointers from different > map regions. Which is utter nonsense. > > One of the essential traits of K&R C was that you could implement the language > in itself. With modern C you can't do that any more. I'm not sure it was ever possible to implement the entire standard library in *portable* C. You can implement it in *non-portable* C. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */