From mboxrd@z Thu Jan  1 00:00:00 1970
From: tfb@tfeb.org (Tim Bradshaw)
Date: Sat, 13 May 2017 13:35:49 +0100
Subject: [TUHS] C declarations.
In-Reply-To: <20170513122050.GF9980@yeono.kjorling.se>
References: <015401d2caa0$79762650$6c6272f0$@ronnatalie.com>
 <68E8DC0A-D1B8-4FF0-AD26-ACDC57E308AF@pobox.com>
 <20170511223232.GM4341@mcvoy.com>
 <015b01d2caa7$c658c020$530a4060$@ronnatalie.com>
 <20170513012415.GZ4341@mcvoy.com>
 <025701d2cb92$ec8182a0$c58487e0$@ronnatalie.com>
 <20170513122050.GF9980@yeono.kjorling.se>
Message-ID: <0CF82AC1-E835-4C06-813F-D9EFD2C12290@tfeb.org>

On 13 May 2017, at 13:20, Michael Kjörling <michael at kjorling.se> wrote:
> 
> Correct me if I am wrong, but _pass by value_ as opposed to _pass by
> reference_ requires making a copy, no? That's the whole point, to
> allow the callee to poke at the value it is given at will. At the very
> least, it would require making a copy when a part of the passed value
> is modified. Where is that memory going to come from, when even
> malloc() isn't a part of the language but rather a part of the
> standard library? Where is all that going to come from if you pass a
> large array on a memory-constrained system of specs common back in the
> days when C was designed, especially one that lacks virtual memory
> support?

Are there languages that copy arrays in function calls defaultly?  Perhaps Fortran has some convention that allows that but I doubt it gets used very much, because it would be insane in most cases:  COMPUTE_MEAN_TEMPERATURE(ATMOS) is really *not* going to work very well if it involves copying the ATMOS array.