Re: actual for variable name must be variable compiler error

[Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>]

On 2014-09-29, Georg Bauhaus <bauhaus@futureapps.invalid> wrote:
> On 29.09.14 21:37, Simon Clubley wrote:
>> void update_value(unsigned long int a)
>> 	{
>> 	printf("Value of a on entry to update_value() is %lu\n", a);
>> 	a = a + 7;
>
> Once you submit to contradictions like "a equals a + 7" being signs
> of advanced understanding---though wondering how that could be---
> you are well prepared for an introduction to more programming quizzes,
> such as why and when `5' may become a name of 4.

The only time I've ever done anything like that was back in my student
days with an old (even at the time) Fortran IV compiler which passed
everything, including integer constants, by reference and the constants
were shared between program statements in a literal pool. There was also
no read-only memory protection within a process on this miniframe.

One day I passed an integer constant (4, IIRC) into a subroutine.
I'll let you work out what happened next. However, it taught me one hell
of a lesson which I've never forgotten. :-)

To return to the issue at hand, I posted the example without comment
instead of the rant about the "wonders" of C I was feeling while
creating it.

However, I want to make it clear I don't write production code like
that. If an in parameter needs modifying in a C program it gets copied
into a local variable and worked on there. Modifying an in parameter
in the way it's done in my example just feels so very wrong to me even
when the language lets you do it...

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world