Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: GCC vs Clang Date: Mon, 25 Jul 2016 17:06:20 -0700 Organization: None to speak of Lines: 54 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="2525"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Ij0IW5dtQwLScQkAS4Xjm" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:X1K/TFg39KYZXHLasJriH4eaBEw= sha1:+6mLN5cXlW444K8DfJl4qQMGq/A= Xref: csiph.com comp.lang.c:91071 supercat@casperkitty.com writes: > On Monday, July 25, 2016 at 6:00:20 PM UTC-5, Keith Thompson wrote: >> supercat writes: >> > What other non-Unix microcomputer operating systems have you looked at? >> > I would consider Unix the oddball in that regard rather than Windows, at >> > least in the microcomputer arena. >> >> What other non-Unix microcomputer operating systems are there? >> I know there are a few non-Unix non-Windows operating systems, >> but none of them are particularly common. > > Windows and Unix have together displaced almost everything else, but there > used to be lots of microcomputer operating systems. GEM, AmigaDos, Geos, > MS-DOS, Apple DOS 3.3, Apple ProDOS, CP/M, classic MacOS, etc. I don't > think any but Unix were bundled with C compilers. > >> There's nothing fundamentally wrong with bundling a runtime library with >> a compiler, but there are advantages to distributing them separately. >> For example, even if I didn't have a compiler installed on my system, >> I'd still be able to run dynamically linked executables that were built >> elsewhere. > > If the compiler statically links in parts of the library that are used > within a DLL, it can substitute simplified versions in cases where it can > make inferences about the arguments. For example, if a piece of code > never passes anything other than a literal format string to sprintf, a > compiler could replace sprintf with a collection of small functions that > are customized to support the formatting options the program actually > uses. A compiler can typically do that anyway. For example, gcc can replace printf("hello\n") by puts("hello"). > Separating the library from the compiler makes it unclear what a compiler > is or is not allowed to assume about the way the library is used. For > example, in what cases would a compiler be allowed or not allowed to replace > a matched pair of malloc/free calls with a stack allocation? If the > compiler was supplying malloc/free, it would know of any and all guarantees > and features the get/free might offer beyond what the Standard requires, but > if the compiler links with an external one, it may have no way of knowing > what guarantees the external version might offer and a programmer may have > no way of knowing what guarantees offered by a malloc/free implementation > will be passed through by the compiler. A compiler can assume that sprintf, malloc, and free meet the requirements specified by the standard. I can imagine that a particular implementation might make more guarantees, but I wouldn't expect such guarantees to be massively useful. -- 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"