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