[comp.lang.c] ANSI C questions

jlevy@teknowledge-vaxc.UUCP (07/13/88)

I am porting some old "K&R" C to a new compiler which claims to be as close 
to ANSI draft standard as possible.  This has generated some questions:

1. Is this code legal:

     #include <string.h>
     static char *foo = "" ;
     char bar[20] ;
     strncpy(bar,foo,strlen(foo)) ;
    
     The compiler that I have treats a zero third argument to strncpy as a
     run time error, and aborts the program.  Does the standard permit this
     behavior? 

2. Is this code legal:

    void func(n,a,p) int n ; int a[] ; int (*p)() ;
    {
        int r ;

        switch (n) {
	  case 0:
		(*p)(r) ;           break ;
	  case 1:
		(*p)(r,a[0]) ;      break ;    /* compiler error here */
	  case 2:
		(*p)(r,a[0],a[1]) ; break ;    /* compiler error here */
	  default:
	    /* error message */
	}
    }
    
    The compiler generates errors (function used with wrong number of
    arguments) after the two lines marked.  The programmer supporting 
    the compiler claims that this is legal.  His argument is that since 
    there is no functional prototype in scope for p, the compiler can 
    take the first time p is used and generate a prototype for p, 
    comparing all future uses of p with that prototype.  He refers to
    this as the "Miranda Rule", and claims it is in the Draft standard,
    or the Rationale.  I can not find it.  

    I hold that since there is not a prototype in scope for p, the compiler
    must treat it as a function taking a constant number of arguments [1].
    Since it is a variable, each time it is used it should be treated
    as different function (since it often will be a different function).

3. Is this code legal:

    long big = 600000L ;
    int small ;

    small = (int) big ;

    Code compiled with this new compiler will suffer a fatal run time error
    when this code is run.  Note that 600000 will not fit into an int on
    this machine, but will fit into a long.  I thought that my explicit cast
    would tell the compiler to do whatever was needed to stuff the long into
    the int [2].  Does the ANSI standard allow the run time lib to overflow 
    here?  If the run time library is correct in generating an error then all 
    (portable) casts from long to int must be done like this:

    small = (int) (big&UINT_MAX) ;  /*I'm assuming that UINT_MAX is all ones*/

In which (if any) of these three cases is the compiler broken?

[1] This is my interpretation of page 55 of the Rationale, dated Jan. 11, 1988:
"An implementation may thus assume that all other [non prototyped] functions 
are called with a fixed  argument list"

[2] K&R says (on page 42): "Longer int's are converted to shorter ones or to 
char's by dropping the excess high-order bits." Did ANSI drop this requirement?

Josh

Name:         Joshua Levy  (415) 424-0500x509
Disclaimer:   Teknowledge can plausibly deny everything.
Pithy Quote:  "Keep your lawyers off my computer!"  -- GNU (?)
jlevy@teknowledge-vaxc.arpa or 
{uunet|sun|ucbvax|decwrl}!jlevy%teknowledge-vaxc.arpa

demon@desire.wright.edu (08/22/90)

	1)	In standard C, when you pass a structure bigger than four
longwords, is the structure passed as a value parameter, or just a pointer to
the structure (thus making it a var parameter)?

	2)	Are structure assignments allowed only for initializations
or can I do:

struct_thing = other_struct_thing;
struct_thing -= still_more_struct;
struct_thing *= even_more_struct;

etc...

	I thought I knew the answer to there but VAX C (I know it's not 100%
ansi) barfs on question #2 type statements of the  -= += etc. kind.

	Thanx,

Brett
demon@wsu.bitnet
bkottmann@falcon.aamrl.wpafb.af.mil

vu0310@bingvaxu.cc.binghamton.edu (R. Kym Horsell) (08/23/90)

In article <1081.26d26274@desire.wright.edu> demon@desire.wright.edu writes:
>
>	1)	In standard C, when you pass a structure bigger than four
>longwords, is the structure passed as a value parameter, or just a pointer to
>the structure (thus making it a var parameter)?

I std doesn't care much about 2 bytes, 4 bytes, etc. When you
*ask* for a struct to be passed by value you *get* it otherwise
your code would probably upchuck.

>
>	2)	Are structure assignments allowed only for initializations
>or can I do:
>
>struct_thing = other_struct_thing;

Sure.

>struct_thing -= still_more_struct;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^?

How should a struct be interpreted as a number (even if it contains only 
a single numeric field)? No, this isn't valid.

-Kym Horsell

henry@zoo.toronto.edu (Henry Spencer) (08/23/90)

In article <1081.26d26274@desire.wright.edu> demon@desire.wright.edu writes:
>	1)	In standard C, when you pass a structure bigger than four
>longwords, is the structure passed as a value parameter, or just a pointer to
>the structure (thus making it a var parameter)?

When you pass a structure, it is passed by value, regardless of size.

>	2)	Are structure assignments allowed only for initializations
>or can I do:
>struct_thing = other_struct_thing;

Yes, you can.

>struct_thing -= still_more_struct;
>struct_thing *= even_more_struct;

No; plain assignment (and the implicit assignments in passing and
returning) are the *only* operators that work on whole structures.
-- 
Committees do harm merely by existing. | Henry Spencer at U of Toronto Zoology
                       -Freeman Dyson  |  henry@zoo.toronto.edu   utzoo!henry

richard@aiai.ed.ac.uk (Richard Tobin) (08/23/90)

In article <1081.26d26274@desire.wright.edu> demon@desire.wright.edu writes:
>	1)	In standard C, when you pass a structure bigger than four
>longwords, is the structure passed as a value parameter, or just a pointer to
>the structure (thus making it a var parameter)?

Structures are passed by value regardless of their size.

Whether this is implemented by actually putting the structure on the
stack, or by passing a pointer to a copy of it, is invisible to the
programmer.

[Actually, it's only invisible to the *correct* programmer.  I recently
forgot to put "&" before the name of a structure I was passing.  This
made no difference on a Sun 4 (which passes the structure by putting
the address in a register) and I didn't discover the error until I
compiled it on a Sun 3.]

>	2)	Are structure assignments allowed only for initializations

No.  Structure assignments are fine in ANSI C.

>struct_thing -= still_more_struct;
>struct_thing *= even_more_struct;

But I don't know what these are supposed to mean.  What do you expect
subtracting structures to do?

-- Richard

-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin

steve@taumet.com (Stephen Clamage) (08/24/90)

demon@desire.wright.edu (Brett) writes:
>	1)	In standard C, when you pass a structure bigger than four
>longwords, is the structure passed as a value parameter, or just a pointer to
>the structure (thus making it a var parameter)?

The standard only says that the structure passing must behave AS IF it were
copied to the called function's parameter.  No conforming compiler can
generate code which allows you to modify the original structure from
within the called function.

Compiler implementors have free reign in the details of how this is
done.  Some compilers pass a pointer to the original struct, and in the
called function preamble copy the data to a local space.  Since no
programmer-written code gets executed before the copying is done, this
is allowable.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com

cc100aa@prism.gatech.EDU (Ray Spalding) (08/24/90)

In article <1990Aug23.154013.28712@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <1081.26d26274@desire.wright.edu> demon@desire.wright.edu writes:
>>	2)	Are structure assignments allowed only for initializations
>>or can I do:
>>struct_thing = other_struct_thing;
>
>Yes, you can.

Provided, of course, that the two structs are of the same type.
-- 
Ray Spalding, Technical Services, Office of Information Technology
Georgia Institute of Technology, Atlanta Georgia, 30332-0275
uucp:     ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!cc100aa
Internet: cc100aa@prism.gatech.edu

dgil@pa.reuter.COM (Dave Gillett) (08/24/90)

In <1081.26d26274@desire.wright.edu> demon@desire.wright.edu writes:

>	1)	In standard C, when you pass a structure bigger than four
>longwords, is the structure passed as a value parameter, or just a pointer to
>the structure (thus making it a var parameter)?
     I believe that all "modern" C compilers pass structures of any size as
value parameters, regardless of size.  Some compilers on some hardware may
pass small structures in registers and larger ones on the stack, or as a pointer
to a copy, or some other mechanism, but it's still a value parameter and your
code should reflect that.

>	2)	Are structure assignments allowed only for initializations
>or can I do:

>struct_thing = other_struct_thing;
>struct_thing -= still_more_struct;
>struct_thing *= even_more_struct;

>etc...

>	I thought I knew the answer to there but VAX C (I know it's not 100%
>ansi) barfs on question #2 type statements of the  -= += etc. kind.

     Recall that "x -= y" is equivalent to "x = x - y".  Will your VAX C let
you get away with "struct_thing = struct_thing - still_more_struct"?  How
have you declared "struct_thing" that lets it both (a) be a structure, and 
(b) be in the domain of subtraction, which normally works on *numbers*???
                                   Dave

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (08/24/90)

In article <352@saxony.pa.reuter.COM>, dgil@pa.reuter.COM (Dave Gillett) writes:
: In <1081.26d26274@desire.wright.edu> demon@desire.wright.edu writes:
: >struct_thing -= still_more_struct;
: >struct_thing *= even_more_struct;
: 
:      Recall that "x -= y" is equivalent to "x = x - y".  Will your VAX C let
: you get away with "struct_thing = struct_thing - still_more_struct"?  How
: have you declared "struct_thing" that lets it both (a) be a structure, and 
: (b) be in the domain of subtraction, which normally works on *numbers*???

Let that stand as typical of the answers.

I'd like to point out that given
	struct SomeTag this, that;
statements like
	this += that, this -= that, this *= that
and so on are perfectly reasonable things to do as such.  In COBOL,
	ADD CORRESPONDING THIS TO THAT.
	SUBTRACT CORRESPONDING THIS FROM THAT.
and so on will do the trick.  Given the equivalent of
	struct { int a, b; float c; } x;
	struct { int b, c, d; } y;
the COBOL equivalent of x += y would be
	ADD CORRESPONDING y TO x.
which would do
    /*	x.a : no change, as there is no y.a field */
	x.b += y.b;
	x.c += y.c;	/* only the names have to match */
    /*  y.d : not used, as there is no x.d field */

As it happens, this facility is not present in C.  There is nothing in
the language which would make it especially difficult to implement, it's
just that nobody ever thought it worth while.  It was a sensible question.

-- 
The taxonomy of Pleistocene equids is in a state of confusion.

dgil@pa.reuter.COM (Dave Gillett) (08/28/90)

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

>In article <352@saxony.pa.reuter.COM>, dgil@pa.reuter.COM (Dave Gillett) writes:
>: In <1081.26d26274@desire.wright.edu> demon@desire.wright.edu writes:
>: >struct_thing -= still_more_struct;
>: >struct_thing *= even_more_struct;
>: 
>:      Recall that "x -= y" is equivalent to "x = x - y".  Will your VAX C let
>: you get away with "struct_thing = struct_thing - still_more_struct"?  How
>: have you declared "struct_thing" that lets it both (a) be a structure, and 
>: (b) be in the domain of subtraction, which normally works on *numbers*???

>Let that stand as typical of the answers.

>I'd like to point out that given
>	struct SomeTag this, that;
>statements like
>	this += that, this -= that, this *= that
>and so on are perfectly reasonable things to do as such.  In COBOL,
>	ADD CORRESPONDING THIS TO THAT.
>	SUBTRACT CORRESPONDING THIS FROM THAT.
>As it happens, this facility is not present in C.  There is nothing in
>the language which would make it especially difficult to implement, it's
>just that nobody ever thought it worth while.  It was a sensible question.

You've suggested a possible semantics for "this -= that" and its ilk.

First of all, it's not obvious to me that this is the semantics that "demon"
had in mind--so the conclusion that the original question was reasonable can
hardly be based on this!  You'll notice, at the end of the passage quoted
from my post, I wonder what kind of semantics were intended.

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.  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.

C is a structured language.  COBOL is not.  The distinction is *not* moot.
"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.  I'm pretty certain that trying
to add this feature to C would be a monumental mistake.
                                            Dave

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (08/29/90)

In article <360@saxony.pa.reuter.COM>, dgil@pa.reuter.COM (Dave Gillett) writes:
> In <3615@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> >In article <352@saxony.pa.reuter.COM>, dgil@pa.reuter.COM (Dave Gillett) writes:
> >: In <1081.26d26274@desire.wright.edu> demon@desire.wright.edu writes:
> >: >struct_thing -= still_more_struct;
> >: >struct_thing *= even_more_struct;
  [and I pointed out that COBOL has the equivalent of it]

> 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.

> 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.

> 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").

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.

> 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.)

> 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".  

> "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.

> 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).

-- 
You can lie with statistics ... but not to a statistician.

dgil@pa.reuter.COM (Dave Gillett) (09/02/90)

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:

>> 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

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (09/03/90)

In article <365@saxony.pa.reuter.COM>, dgil@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 original poster made it clear that *when applied to his specific
problem* adding or subtracting corresponding fields was what he intended
*in that specific case*.  He didn't describe a general 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.

Why doubt it?  Why not go and find out?  It's a solved problem because
"corresponding" is defined so that it *can't* *happen*.  The two fields
simply do *not* "correspond".  No parallelism is involved.

> >> C is a structured language.  COBOL is not.
 
> >Where have you been?  Every control structure that C has, COBOL has.

> 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.

As far as I have been able to find out, "X is a structured language"
means "I like X".  By my standards, C is an incredibly unstructured
language.  (ML is _my_ idea of a structured language, and I'm willing
to concede that Ada is structured.  But C?  Pull the other one.)

> 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.

Surely the syntax of C is widely agreed to be its weakest feature?
Speaking of nesting, how come a language that *doesn't* provide nested
procedures (C) qualify as structured, while one that *does* (modern
COBOL) fails?

Surely the common understnading of what makes a language "structured"
has something to do with semantics (what combinations can be expressed)
rather than syntax (the specific notation used to express things)?  Is
saying, for example, X+Y rather than (plus X Y), so enormously significant?
Are we C-lovers to remain helpless against the onslaughts of Herman Rubin
who complains about having to use functional notation?

> 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 specific things?  Bear in mind that over the years COBOL _has_
dropped several things (such as the ALTER verb).

> Oops, I just did that [described the "structured" distinction] in general
> terms above.  I expect that most of the people in comp.lang.misc already
> understand the distinction.

I'm sure I _shall_ understand the distinction as soon as you take the
trouble to explain what it _is_.  

> 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)?),

I _can_ say O(n^2), but why should I?  It's an O(n) process.  (Basically it
is a set intersection.)

> (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 agree completely.  That's why I never used CORRESPONDING when I used to
write COBOL.  That's why I'm not advocating this as an extension of C, just
pointing out that it wasn't completely loony.

-- 
You can lie with statistics ... but not to a statistician.

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (09/03/90)

In article <365@saxony.pa.reuter.COM>, dgil@pa.reuter.COM (Dave Gillett) writes:
> 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, 

Let's see "demon"'s own words, shall we?

demon>	It was intended that the assignement/operator would only be
demon>	performed on like structure elements, and only on elements
demon>	defined for the operater(s).

What exactly is the difference between this and CORRESPONDING that I have
failed to grasp?

(Explicitly defining "+" for the data type in question, using C++,
is undoubtedly a better approach.)
-- 
You can lie with statistics ... but not to a statistician.

ejp@bohra.cpg.oz (Esmond Pitt) (09/04/90)

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