Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!munnari.oz.au!mel.dit.csiro.au!yarra!bohra!ejp
From: ejp@bohra.cpg.oz (Esmond Pitt)
Newsgroups: comp.lang.c
Subject: Re: ANSI C questions (parameters, structure assignment)
Message-ID: <602@bohra.cpg.oz>
Date: 4 Sep 90 03:13:02 GMT
References: <360@saxony.pa.reuter.COM> <3636@goanna.cs.rmit.oz.au> <365@saxony.pa.reuter.COM>
Organization: Computer Power Group, Melb, Australia
Lines: 33

In article <365@saxony.pa.reuter.COM> dgil@pa.reuter.COM (Dave Gillett) writes:
> In <3636@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>
>>In article <360@saxony.pa.reuter.COM>, dgil@pa.reuter.COM (Dave Gillett) writes:
>>> ... at least one killer case:  where two names appear in a union
>>> in the destination struct but as separate components of the source struct.
>>> The result should store two different values into a single location.
>
>>This is not a killer case at all.  It's a solved problem.  The very
>>same situation can occur in COBOL (look up "level 66 items").
>
> "A solved problem"?

In COBOL the "problem" is "solved" by the following two rules:

	1. For two items from two scopes to "correspond" they must have
	not only the same name but the same qualification within both
	scopes. E.g. a1.b.c and a2.b.c correspond, but a1.b.c and a2.c do not;
	nor do a1.b.c. and a2.b.z.c.

	2. If any target items overlap the results are undefined.
	
Whether this is considered to be a "solution" or indeed a "problem" is
up to the reader.

As for the implementation issues, implementing CORRESPONDING in a COBOL
compiler in compliance with the ANSI standard X3.23 takes about a page
of code, built around an algorithm to be found in Knuth volume I.

Is there any realistic alternative to rule #2?
-- 
Esmond Pitt, Computer Power Group
ejp@bohra.cpg.oz
D