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 Translator Date: Mon, 01 Apr 2019 19:13:00 -0700 Organization: None to speak of Lines: 89 Message-ID: References: <5c9ef544.996282798@core> <_1InE.230560$MT2.63924@fx21.am4> <5c9f93d9.1036879283@core> <87o95s9k7v.fsf@bsb.me.uk> <87imvzaiis.fsf@bsb.me.uk> <877ecf9lyv.fsf@bsb.me.uk> <_DdoE.513530$7F3.198430@fx30.am4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="a8aa2c8b7dd2955eccfe556864ca53e6"; logging-data="6448"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18TTVfDwWXtkBaXrLBnMIbR" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:zX85qLCxZrpa+zx08obL3/kwmOU= sha1:P2xWfAgxCemRMQVbXZTdfwxCpvo= Xref: csiph.com comp.lang.c:142723 Bart writes: > On 02/04/2019 00:25, Keith Thompson wrote: >> Bart writes: >>> That doesn't tell you anything? >> >> Nothing that I didn't already know. > > So how do people end up writing programs that fail with all those > warnings when /you/ try and compile them> I have no idea where that code (lisp.c) came from. I can only assume that author wrote it in a different environment, using a different compiler, than the one I use, likely with a pre-C99 compiler on 32-bit system. The code appears to be non-portable and written in a very questionable style. I can imagine that there might have been valid reasons to write it that way, but I'm not sufficiently interested to look into it. >> [...] >> >>> Even if compilers allowed integer/pointer compares last century, there >>> is no reason to still allow it now. That means having a hard error. >> >> You know how to get a C compiler to treat it as a hard error. > > You keep saying that. But: > > * All C compilers are different > * Not everyone knows how to do it > * Not everyone is aware that that is what needs to be done. > * Not everyone is bothered > * Not everyone tests their code across multiple compilers > * If a compiler is so lax, people might genuinely think that their C > code is fine Yes, we both know all of this. > There must be a reason why there is so much poor code in the first > place, and I think it's a combination of the above. Quite possibly. > And actually, you have a bit of a cheek to suggest that if I knew > everything there was to know about C compiler options, then somehow such > code would not exist. I did not suggest any such thing. I pointed out some problems with the code, while wondering why you posted it. I didn't think you had written it. > IT IS NOT MY FAULT because I didn't write it and I wasn't there when it > was compiled. Fine, I never implied otherwise. > This bit of code is from the Monads thread; it has a missing return value: > > object seq( object p, object q ){ > } > > Some C compilers will report a warning, some will say nothing, others > will only say something depending on options. > > Do you think that function would have survived like that if every C > compiler gave a fatal error? No. This is why there is some poor quality > software around. C does not require a diagnostic for a missing return statement in a non-void function. (The behavior is undefined only if the caller uses the returned value.) This is, I think, because a lot of pre-ANSI code used int functions as a stand-in for void functions, which didn't exist yet, and requiring a diagnostic would break old code. If you think I'm saying that I *like* the fact that no diagnostic is required, I invite you to re-read the previous paragraph as many times as it takes for you to realize that I didn't say that. I just took a look at that article. The seq function is never called. I don't know what the intent was, but my guess is that both the body of the function and any code that calls it is to be filled in later. If you wanted to point out a problem with the seq() function, you could have posted in that thread. The author might even have explained. [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */