Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: encapsulating directory operations Date: Tue, 01 Jul 2025 10:09:11 -0700 Organization: A noiseless patient Spider Lines: 59 Message-ID: <86bjq3q1mw.fsf@linuxsc.com> References: <100h650$23r5l$1@dont-email.me> <100j09o$2f04b$1@dont-email.me> <87tt5ezx9y.fsf@nosuchdomain.example.com> <100j4t3$2foah$1@dont-email.me> <87ldqqzfj0.fsf@nosuchdomain.example.com> <100kak8$2q0s6$1@dont-email.me> <87a575zvmb.fsf@nosuchdomain.example.com> <100o3sc$3ll6t$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> <10199t2$3q3mn$1@dont-email.me> <1019kgf$3s5co$1@dont-email.me> <101bt9c$dckn$2@dont-email.me> <101c2p8$eeca$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Tue, 01 Jul 2025 19:09:11 +0200 (CEST) Injection-Info: dont-email.me; posting-host="9e46744e4985b53c2fe54e514d0912ff"; logging-data="3110354"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+mH55iz73R7JQRfQ3u4vuePJ9vd/eoUuQ=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:2aw297pBpdwuikAB8mh4A5HncaI= sha1:+BE3NfG+ISU1wr7KTJqL0m6X+dI= Xref: csiph.com comp.lang.c:393958 Richard Heathfield writes: > On 30/05/2025 10:20, David Brown wrote: > >> On 29/05/2025 14:38, Richard Heathfield wrote: >> >>> This really is a very simple point, but perhaps a simple analogy >>> will help to clarify it. You don't throw out your 3/4" just >>> because you've bought a 19mm. There is room for both in the >>> toolbox, and why write 3/4" on your new spanner? It /isn't/ a >>> 3/4" spanner even though it's very like it, so why pretend >>> otherwise? >> >> Your analogy does not cover C99 vs C90. > > It does if we can construct a program that is legal C90 but not > legal C99, which is easy enough, or (slightly harder but still not > that hard) a program that is legal in both dialects but which > gives different output under C99 than it does for C90. > > $ cat c9099.c; \ > gcc -W -Wall -ansi -pedantic -o c90 c9099.c; \ > gcc -o c99 c9099.c; \ > ./c90; \ > ./c99 > #include > > int main(void) > { > int a = 42; > > int b = a //* comment */ 6; > ; > printf("Soln = %d\n", b); > > return 0; > } > Soln = 7 > Soln = 42 It's a straightfoward exercise to write a program that discovers whether a given .c file has this potential ambiguity. Of course, essentially no actual source code will, but the point is the problem is easy to detect, and also correct. This observation suggests a related question. Is there a source of potential ambiguity between C90 and C99 that is not so easy to detect and correct? I can think of one, but it falls into the realm of depending on implementation-specific behavior, so could just as easily be seen as a portability issue rather than a language version issue. > Obviously it's a contrived example, but then examples pointing out > the consequences of language differences invariably are. Some are. Some are not. In the case of C90 and C99, probably all such cases are contrived, but certainly for other language pairs there are cases that might arise unintentionally, even for similar languages (notably C and C++).