Re: What is the meaning of an expression?

dave_thompson_2@comcast.net
Sun, 30 Jan 2022 22:51:54 -0500

          From comp.compilers

Related articles
[12 earlier articles]
Re: What is the meaning of an expression? 0xe2.0x9a.0x9b@gmail.com (Jan Ziak) (2022-01-19)
Re: What is the meaning of an expression? christopher.f.clark@compiler-resources.com (Christopher F Clark) (2022-01-19)
Re: What is the meaning of an expression? tkoenig@netcologne.de (Thomas Koenig) (2022-01-19)
Re: What is the meaning of an expression? gah4@u.washington.edu (gah4) (2022-01-19)
Re: What is the meaning of an expression? DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2022-01-20)
Re: What is the meaning of an expression? tkoenig@netcologne.de (Thomas Koenig) (2022-01-22)
Re: What is the meaning of an expression? dave_thompson_2@comcast.net (2022-01-30)
Re: What is the meaning of an expression? johann@myrkraverk.invalid (Johann 'Myrkraverk' Oskarsson) (2022-02-03)
| List of all articles for this month |

From: dave_thompson_2@comcast.net
Newsgroups: comp.compilers
Date: Sun, 30 Jan 2022 22:51:54 -0500
Organization: A noiseless patient Spider
References: <AdgJPKhi/NiNfECvRNaA6+4Wq/M8OQ==> 22-01-052 22-01-060 22-01-066 22-01-067 22-01-068 22-01-069 22-01-070 22-01-076
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="40505"; mail-complaints-to="abuse@iecc.com"
Keywords: C, history
Posted-Date: 31 Jan 2022 10:35:15 EST

On Thu, 20 Jan 2022 13:02:34 +0100, Hans-Peter Diettrich
<DrDiettrich1@netscape.net> wrote:
...
> ARAIR K&R C defined the value of a function call to be the value
> contained in the accumulator after return. A decision with horrible
> consequences if you look at compiler and library source code of that
> time. OTOH it derogates the meaning of an expression if at any time one
> can find a value in the defined result register.
...
> [Early C didn't have default return values, but since the compilers also
> didn't do much type checking, I can believe there was a code that
> worked by accident becaues the value of the last expression in a function
> happened to be in the register where the caller looked for the result. ...]


Through K&R1 C didn't have 'void' -- all functions had some return
type, which if not written defaulted to 'int' (as in BCPL and B). The
_compilers_ did typecheck but not most _linkers_ so a mismatch across
separately-compiled files was one way to get this problem; one of the
features of 'lint' was to catch such. (FORTRAN had the same issue, and
there were some tools for it, but I don't recall one as prominent.
COBOL, at least then, didn't have value-returning subprograms,
although it could have mismatch on arguments. I don't recall what
Pascals did -- when they had separate compilation at all -- and never
saw a non-toy algol. C++ overloading effectively required typesafe
linkage, and Ada assumed a 'repository' preventing mismatches.)


Another way is if you 'fall off the end' of a (non-void) function, or
through the first standard (C89/90) you wrote and executed a return
statement with no expression; before void this was widely used for
functions with no useful value. If the callsite doesn't discard the
notional 'value' of a call that does one of these, it is officially
undefined behavior and in practice usually takes whatever value is
lying about in the register used by the calling sequence -- but on
PDP-11 and Interdata at least that wasn't 'the accumulator' because
they had no such thing.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.