Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: BGB Newsgroups: comp.lang.java.programmer Subject: Re: =?UTF-8?B?QW5kcm9pZOKAlFdoeSBEYWx2aWs/?= Date: Fri, 03 Jun 2011 12:45:44 -0700 Organization: albasani.net Lines: 78 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net QXG6U25eMqGqpp1utJfliR0e5qHra2OsdvEWdoLt/AWK/m+jkVHY3rDsLRk+7EOjqTSxd5s+6YetI9i4KSstew== NNTP-Posting-Date: Fri, 3 Jun 2011 19:48:55 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="VMe9edxFAy3gISPH6N7Vs+Wr3n7baH9xrmhCY4FTLeS0HjK03iDerFdjLy0FzHC+Bb3T0lOIiLAZHNJHcATpkPxQDNaqf/fVkiTjBiBOIg3nJYm9FOWZAPyDSiTBzSjg"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:4YhOz3Oi3mcDCC7iVfAzuj7xtJo= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4949 On 6/3/2011 6:31 AM, Michael Wojcik wrote: > BGB wrote: >> On 5/31/2011 8:10 AM, Joshua Cranmer wrote: >>> >>> Besides, all autoconf gets you is setting up the hundreds of #defines. >>> It does nothing else with respect to the #ifdef mess. >> >> yeah, and it doesn't exactly tend to work well for non-Linux operating >> systems (such as Windows...). > > Used properly, autoconf works just fine on Windows - or, at any rate, > as well as it works anywhere. (Like Joshua I am not particularly > impressed with autoconf, though it's not quite as thoroughly > brain-damaged as some of its fellow GNU build tools, such as libtool.) > Wireshark uses it, for example. > > Once again, the real problem is that systems like autoconf only help > with C code that is written to be portable with the help of > conditional compilation. The vast majority of C code is poorly written > (spend some time on comp.lang.c if you don't understand how or why) > and a good portion of that is unportable assumptions. > > Some of the classic non-portable assumptions in C code are becoming > rarer. The prevalence of two's-complement machines over > one's-complement and sign-magnitude (the other two "pure binary > representations" allowed for C integer types) has largely eliminated > one source of bit-twiddling errors, for example; and the popularity of > I32LP64 architectures has made more programmers aware of the problems > of casting between pointer and integer types. > > But we still see a lot of code with character set assumptions, or > assuming CHAR_BIT==8, or assuming huge auto-class objects are fine. > Those are safe assumptions on many platforms, but they limit > portability. So do endianness assumptions, etc. > CHAR_BIT==8 is AFAIK more acceptable, since nearly all major/common hardware at this point (and likely in the near future) has this property. endianess matters if one thinks the code may have a chance of migrating between different sorts of targets, such as between x86 and PPC. usually I handle endianness in my own code though. > And we still see a lot of buffer overflows, integer overflows, unsafe > or erroneous memory allocation. Failures to check for and handle error > returns from library and system calls. TOCTOU races and other forms of > unsafe file handling. Interpositioning vulnerabilities (a huge issue > with Windows right now; not specific to C, but mitigated by runtime > systems that use more-sophisticated dynamic loaders). And so on. > > Autoconf does *not a damn thing* to address any of this. > yes, ok. oddly, Mozilla uses Autoconf+MSVC in their Windows build setup (and apparently also a 'special' version of Autoconf). IMO it looks like a bit of a kludge. more impressive though was that it actually worked, and when one follows their directions (downloading/using MozillaBuild, ...), they can rebuild FireFox/... from source on Windows. I am currently using MSVC, but mostly this was because in 2009 I had been building for Win64, and GCC's Win64 support was not impressive (mostly in the sense that it was occasionally producing broken code apparently mixing together parts of the Win64 and AMD64 ABI's...). I am left wondering if GCC's Win64 support has improved, or if it really matters. I could probably switch back, but it would involve having to mess around some with the makefiles, which is inconvinient. or such...