ANSI C questions (parameters, structure assignment)

[Dave Gillett]

In <3636 at goanna.cs.rmit.oz.au> ok at goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:

>In article <360 at saxony.pa.reuter.COM>, dgil at pa.reuter.COM (Dave Gillett) writes:

>> First of all, it's not obvious to me that this is the semantics that "demon"
>> had in mind.

>He later said that it was.

Oh, but he didn't.  The semantics that he gave were *considerably* less
ambitious than what you're suggesting.  The result would be the same for trivial
cases, but it's not hard to construct an example that does one thing under his
semantics and another under yours.


>> But secondly, we have the assertion that "there is nothing in the language
>> which would make it especially difficult to implement", and I'm not sure
>> that's true at all.

>There is nothing in C to make it harder than COBOL.  Pointers could cause
>problems, but addition (subtraction) of pointers is not defined (does not
>yield a pointer) so would continue to be illegal.

That's true, "-=" and "+=" require that the result be stuffed back into one of
the operands, and so should not work on pointers.  No disagreement here.


>> I can envision a number of scenarios where it would
>> have to be extremely awkward, some cases where a diagnostic message should
>> be issued but it could be extremely diifficult to pinpoint the error being
>> diagnosed, and 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"?  I seriously doubt it.  It's quite possible that a
convention has been agreed upon, but the fact is that you have parallel
operations (pieces of an atomic operation) whose result depends on the
order in which they are evaluated.  AT VERY LEAST, YOU MUST GET A COMPILER
WARNING ON THIS.  Probably a compiler that allows this will produce results
in a reliable and consistent manner, but if anybody has managed to get the
agreement of a standards committee (or even of two programmers!) on this,
I'd be very surprised.  That it can occur in COBOL I have no doubt.  That
it is a "solved problem" in any sort of general sense, is harder to believe.


>Do bear in mind that I was *NOT* recommending it as an extension to C,
>merely observing (a) that it wasn't completely loony and (b) that the same
>methods COBOL compilers use for the job could be adapted if anyone wanted
>to hack their copy of GCC or of Holub's code or whatever.

Do bear in mind that I was merely observing that it was (a) not well-enough
defined to determine whether it was loony or not, and (b) that it was not
well-enough defined to tell whether the methods that COBOL compilers use for
the job, assuming it was defined to be the same job as COBOL compilers do, was
an appropriate approach--and that adding these methods to C compilers was
likely to be much more complex a job than you seemed to realize.


>> C is a structured language.  COBOL is not.

>Where have you been?  Every control structure that C has, COBOL has.
>The current version of COBOL even has nested "programs", something
>that C lacks.  (Yes, I *do* mean that a single COBOL text is no longer
>restricted to one global pool of variables.  And yes, modern COBOL
>control structures are not tied to labelled paragraphs.)

And if you think that "structured language" simply means "supplies the
control structures recommended for doing structured programming" then
you clearly didn't understand the distinction I was making.  The
characteristics that I refer to are not extra features that can be grafted
on--they have to do with how various language structures combine and
nest, with the syntax of the language rather than its semantics.

Being able to do, in modern COBOL, everything you can do in C, doesn't
qualify.  In order for COBOL to become a structured language, you'd have to
stop being able to do things that were allowed in it 15 years ago, which means
that you break an awful lot of existing code and probably can't call it
COBOL any more.


>> The distinction is *not* moot.

>Perhaps you might like to explain in comp.lang.misc precisely what it
>is that makes C (according to the current standard) "structured" but
>COBOL (according to the current standard) "not structured".  

Oops, I just did that in general terms above.  I expect that most of the
people in comp.lang.misc already understand the distinction.  (I could be
wrong about that....)


>> "CORRESPONDING" is a powerful feature, and its implementation cost is, I'm
>> sure. much higher than you think--and places non-trivial demands on the
>> data declaration portions of the language.

>Corresponding has no *RUN-TIME* consquences whatsoever.  Basically all that
>is required to implement <op> CORRESPONDING <source> TO <destination> is to
>walk over the symbol table, doing
>	for each <field> in FieldsOf(<source type>) intersection
>			    FieldsOf(<destination type>) do
>	    compile the statement
>		"<op> <field> OF <source> TO <field> OF <destination>"
>I oversimplify, but it is is a *well* understood problem, and there would
>be no impact on the data declaration portion of the language whatsoever.

Okay, I phrased it badly.  Currently, a compiler trying to resolve a name
reference has a fairly easy time of it--take the explicit name from the 
source line, and match it in the symbol table to get (a) type information,
and (b) location information, typically as an offset from some base to be
determined at link/load time.  The type information can be used to determine
whether the operation specified by the source is correct or not.

Now in the CORRESPONDING case, the compiler has to generate a whole bunch of
implicit references from doing symbol table lookups, try to match each one of
those with another symbol table lookup (can you say O(n^2)?), and determine from
the type information whether the specified operation is to be done--with the
added proviso that illegal operations are not errors, but are just to be 
ignored.  (The idea of a compiler that "knows" that I didn't mean to specify
an illegal operation, so it can safely ignore it, contradicts everything my
experience with software engineering has taught me.)


>> I'm pretty certain that trying to add this feature to C would be a
>> monumental mistake.

>That's a completely different question.  I repeat, my point was that the
>original poster seemed to be talking about something which was present
>in at least one other langauge, whose implementation is well understood,
>and for which the *only* change to the C language would be to render more
>expressions defined.  Whether it would be a good idea to *do* it is quite
>a different question.  I don't think it would be myself, and I always
>shunned CORRESPONDING when I used COBOL (on program maintenance grounds;
>to someone reading the program it was never clear just what was going on).

Well, I don't consider the feature, or its implementation, well understood.
(And since you failed to grasp the differences between CORRESPONDING and the
semantics that "demon" turned out to actually have in mind, and also that
"structuredness" is a syntactic feature of a language and not a collection
of semantic features, I don't accept your assertion that it is well
understood.  Fair enough?)
                                               Dave