Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!newsfeed.bofh.team!paganini.bofh.team!not-for-mail From: antispam@fricas.org (Waldek Hebisch) Newsgroups: comp.lang.c Subject: Re: encapsulating directory operations Date: Fri, 30 May 2025 02:46:48 -0000 (UTC) Organization: To protect and to server Message-ID: <101b66m$2g6n0$1@paganini.bofh.team> References: <100h650$23r5l$1@dont-email.me> <87bjrkxonr.fsf@nosuchdomain.example.com> <87iklrtcys.fsf@nosuchdomain.example.com> <20250523132019.763@kylheku.com> <100qm76$7shk$2@dont-email.me> <20250523140729.787@kylheku.com> <100qru0$9mjb$2@dont-email.me> <101929h$3olom$4@dont-email.me> <10196gn$3pd33$1@dont-email.me> <101aca9$me2$3@dont-email.me> <101afvt$1sm1$1@dont-email.me> <871ps7f8o3.fsf@nosuchdomain.example.com> <101aif2$1sm2$3@dont-email.me> Injection-Date: Fri, 30 May 2025 02:46:48 -0000 (UTC) Injection-Info: paganini.bofh.team; logging-data="2628320"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A"; User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64)) X-Notice: Filtered by postfilter v. 0.9.3 Richard Heathfield wrote: > > Software houses need C90 for the same reason the government needs > IBM 1311s (unless they've finished migrating off them now), > cassette players, WW2 crypto keys, and the boot passwords for > those early 1990s PCs lurking in the cellar. > > I shudder to think how much C90 code is out there, but it has to > be /at least/ in the region of 10^9 LOC, much of it in the > military arena, medical applications, and particularly the world > of comms. Letting C90 compilers fall off the radar (e.g. by > society forgetting how to program in it) really could be a > stupendously bad idea, for all the reasons that people overlook > when they shrug and say `I expect it'll all turn out fine'. Clearly there is a lot of old code there. I am not sure why you think that C90 is very special here. I mean, goverment loves standards and for goverment project may mandate use of "standard" language, which could mean C90 in relevant period. However, business had tendency to use whatever their compilers supported, which frequently meant using vendor extentions. Due to extentions, I suspect that there is very little pure C90 code. Even if C90 was mandated it is not clear if C90 was really deliverd. More precisely, when you look at small snippets of C code there is good chance that they will be valid regardless of version of C that you use. However in large codebase one can expect some constructs that are not valid C90. Even for code born as pure C90, there is notrivial chance that maintanence introduced constructs from later C standards. AFAICS C99 and C11 did not introduced major incompatibilities with C90. OTOH some vendor extentions to C90 were standarized in C99 and C11. So, it is reasonable to suspect that amount of say C99 code is significantly larger than C90 code. Or may be better to say that deviation of C code from C99 is probably smaller than deviation from C90. Concerning new code it makes sense to avoid constructs that are made illegal in later standard, that is write to the latter of later standard even if you use only constructs available in C90. And concerning constructs not in C90, I find ability to mix declarations and statements important to readability. So any code that I write now is unlikely to be valid C90 for this (technically trivial) reason. For computational code multidimensional arrays are useful. In general purpose code sizes of arrays are typically only known at runtime, so it is natural to use variable modified types. Other people may find useful some other features of C99 or later standards, so there is incentive to go beyond C90. There is also historic aspect. C90 is part of history and I fully support preserving it (specification and actual programs) as historic artifacts. But I also think that C90 should be retired from practical use, that is code should be modernized to comply with later standards. If code needs to be very portable, than C90 compatibility makes sense, but for most code it it better to take advantage of newer features. BTW: In the past I used to point out to students that some features that they use in their programs are not C90 but say C99. But now I do not think that it is worth to bother students with information about C90. -- Waldek Hebisch