chip@ateng.uucp (Chip Salzenberg) (09/20/88)
According to news@ism780c.isc.com: >But consider what might have happened had dpANS mandated that the compution >of a pointer to x[-1] be a valid operation. Okay, let's imagine: X3J11 says that x[-1] must be valid. then: int must be 32 bits. then: address space must be linear. etc. until only the SPARC is conforming. (no smileys here) Each time you make a "beneficial" restriction, you're condemning present users of real, useful computers to the purgatory of enforced non- conformance. I don't think anyone really wants X3J11 to make decisions about which hardware will be permitted to run C programs. In addition, it should be observed that on this issue, X3J11 stuck to its charter and codified existing practice. -- Chip Salzenberg <chip@ateng.uu.net> or <uunet!ateng!chip> A T Engineering My employer may or may not agree with me. The urgent leaves no time for the important.
jones@ingr.UUCP (Mark Jones) (09/21/88)
In article <1988Sep19.164701.11136@ateng.uucp>, chip@ateng.uucp (Chip Salzenberg) writes: > According to news@ism780c.isc.com: > >But consider what might have happened had dpANS mandated that the compution > >of a pointer to x[-1] be a valid operation. > > Okay, let's imagine: X3J11 says that x[-1] must be valid. > then: int must be 32 bits. Excuse my ignorance, but why must an int be 32 bits for the above to work? > then: address space must be linear. Does X3J11 say that the contents of x[-1] must be valid? Mark Jones
kyriazis@rpics (George Kyriazis) (09/22/88)
In article <2583@ingr.UUCP> jones@ingr.UUCP (Mark Jones) writes: >In article <1988Sep19.164701.11136@ateng.uucp>, chip@ateng.uucp (Chip Salzenberg) writes: >> According to news@ism780c.isc.com: >> >But consider what might have happened had dpANS mandated that the compution >> >of a pointer to x[-1] be a valid operation. >> >> Okay, let's imagine: X3J11 says that x[-1] must be valid. >> then: int must be 32 bits. > >Excuse my ignorance, but why must an int be 32 bits for the above to work? > >> then: address space must be linear. > >Does X3J11 say that the contents of x[-1] must be valid? > >Mark Jones Excuse for the question, but that is the first time I am looking at that subject and I don't see any reason why x[-a] can't be permitted, mainly for two basic reasons: (a) x[a] == *(x+a) therefore x[-1] == *(x-1), which looks perfectly ok to me. (b) yacc uses array[-1]. If it is considered invalid, that will mean that yacc has to be rewriten for the new standard? Am I missing something? George Kyriazis kyriazis@turing.cs.rpi.edu ------------------------------
swilson%thetone@Sun.COM (Scott Wilson) (09/22/88)
I'm not quite sure what is being discussed. I assume the standard says that the -1'th element on an array is not guaranteed to be accessible, not that negative array indices are disallowed. For example, this is legal is it not: int array[10], *ip = array; ip++; foo(ip[-1]); I assume when yacc uses array index of -1 it is doing something similar. -- Scott Wilson arpa: swilson@sun.com Sun Microsystems uucp: ...!sun!swilson Mt. View, CA
djones@megatest.UUCP (Dave Jones) (09/23/88)
From article <1237@imagine.PAWL.RPI.EDU>, by kyriazis@rpics (George Kyriazis): ... > > (b) yacc uses array[-1]. If it is considered > invalid, that will mean that yacc has to be rewriten for the new standard? > There's more. Here's some code I ripped directly from a y.tab.c (yacc output) of a compiler I'm working on: case 28: # line 160 "gram.y" { Mpc_insert_with_searchdir(yypvt[-3],yypvt[-1]); yyval = tree(N_INSERT_DECL3);} break; case 29: # line 166 "gram.y" { yyval= tree(N_CONST_DECL); } break; case 30: # line 171 "gram.y" { yyval= list(L_CONST_DECL_LIST, (Node*)0, yypvt[-0]); } break; 'Nuff said? I missed some of the early postings on this subject. Could someone be kind enough to bring me up to date? Is the committee going to break this code? If so, why, fer Pete's sake?
pardo@june.cs.washington.edu (David Keppel) (09/23/88)
djones@megatest.UUCP (Dave Jones) writes: >[ yacc example ] The C standard does not tsy that computing a negative offset off of a pointer is illegal, it says that computing one that is outside of the array that the pointer points in to (the a single object is an array of size 1) iis not standard C. In the case of the YACC example, consider the following: int a[10]; int *ip; ip = &a[0]; &ip[-1]; /* iplementation-defined behavior */ &ip[0]; /* just fine */ &ip[9]; /* just fine */ &ip[10]; /* just fine */ ip[10]; /* iplementation-defined behavior */ ip = &a[5]; &ip[-6]; /* iplementation-defined behavior */ &ip[-5]; /* just fine */ &ip[4]; /* just fine */ &ip[5]; /* just fine */ ip[5]; /* iplementation-defined behavior */ And that's the way it is. ;-D on ( My goodness and my badness ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
mills@kaa.eng.ohio-state.edu (Christopher Mills) (09/23/88)
>(yacc output) of a compiler I'm working on: >{ Mpc_insert_with_searchdir(yypvt[-3],yypvt[-1]); > yyval = tree(N_INSERT_DECL3);} break; >Is the committee going to >break this code? If so, why, fer Pete's sake? This should be OK, I believe. As I understand the internals of yaccpar, yypvt is a pointer into yyv[], so you're not going outside of the bounds of the array. The problem is in the initialization of the stack where it's pointed to the -1th element which doesn't exist. -=- _________________________________________________________________________ | Christopher Mills | "If you see someone without a smile, | | mills@baloo.eng.ohio-state.edu | give them mine - I'm not using it." | ====== My thoughts are not my own--I'm posessed by mailer daemons. ======
gwyn@smoke.ARPA (Doug Gwyn ) (09/23/88)
In article <816@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >Is the committee going to break this code? If so, why, fer Pete's sake? You should know by now not to believe every raving you hear on the net. The discussion was about computing out-of-range pointers, then somebody who hadn't understood the discussion made noises about [-1] array indexing being outlawed, which is plain silly.
carroll@s.cs.uiuc.edu (09/23/88)
/* Written 1:42 am Sep 22, 1988 by kyriazis@rpics in s.cs.uiuc.edu:comp.lang.c */
Excuse for the question, but that is the first time I am looking at that
subject and I don't see any reason why x[-a] can't be permitted (...)
Am I missing something?
kyriazis@turing.cs.rpi.edu
------------------------------
/* End of text from s.cs.uiuc.edu:comp.lang.c */
The problem arises on machines with non-linear address spaces. The classic
example is the 80x86 family from Intel. Address on this machine consist
of two parts - the segment and offset. For large arrays, it is handy
to have the array start at the beginning of segment, and make the segment
large enough to hold the array. Therefore, array arithmetic is done only
with the offset, making the code run much faster. Unfortunately, the
price you pay is that negative absolute indices 'wrap around' the segment,
and give bizarre results. This can be finessed in YACC by declaring
the array and a pointer, and then if YACC has a 'largest' negative index
of 1 or 2, set pointer = array + 1 or 2, and things work fine. I hope
this makes things clearer.
Alan M. Carroll carroll@s.cs.uiuc.edu
Grad Student / U of Ill - Urbana ...{pur-ee,convex}!uiucdcs!s!carroll
"Too many fools who don't think twice, too many ways to pay the price" - AP&EWpeter@ficc.uu.net (Peter da Silva) (09/24/88)
In article <816@goofy.megatest.UUCP>, djones@megatest.UUCP (Dave Jones) writes: > I missed some of the early postings on this subject. Could someone > be kind enough to bring me up to date? Is the committee going to > break this code? If so, why, fer Pete's sake? No, the comittee isn;t going to break that code. Those array references are from a pointer pointing into the middle of an array back into the earlier part of the array. This is legal. What is not legal is to have a pointer point back before the beginning of an array, even if it is not dereferenced, because there are architectures that do bounds checking on pointer calculations and there are architectures like the intel 8086 family for which this is may not even be meaningful. Personally, I think these architectures are the result of severe brain damage or overdependence on marketing claims. But they're out there, and have to be accomodated. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net
henry@utzoo.uucp (Henry Spencer) (09/25/88)
In article <69575@sun.uucp> swilson@sun.UUCP (Scott Wilson) writes: >I'm not quite sure what is being discussed. I assume the standard >says that the -1'th element on an array is not guaranteed to be >accessible, not that negative array indices are disallowed... More precisely, what it says is that even *computing* a pointer to the -1th element of an array can send you off into the Twilight Zone. This is not new -- if you read K&R, that's always been the rule. However, there is no objection to subtracting 1 from a pointer that already points to the Nth element of an array, where N > 0. (&a[1])[-1] is legal. -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
terry@wsccs.UUCP (Every system needs one) (09/28/88)
In article <1237@imagine.PAWL.RPI.EDU>, kyriazis@rpics (George Kyriazis) writes: > Excuse for the question, but that is the first time I am looking at that > subject and I don't see any reason why x[-a] can't be permitted, mainly > for two basic reasons: > (a) x[a] == *(x+a) therefore x[-1] == *(x-1), which looks > perfectly ok to me. > > (b) yacc uses array[-1]. If it is considered invalid, that will mean > that yacc has to be rewriten for the new standard? > > Am I missing something? Yes. The source for who contains the following type of thing: char *str = "hello world"+6; where printf( "'%c'", str[ -6]); gives 'h'. This is is used in the "who am i" command. It works on most C compilers (with 1 exception still in developement). The exception is due to the method of compilation requiring a "fake node" to make it work. DMR is quoted as saying it should work by the compiler writer, even in ANSI C. | Terry Lambert UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'I have an eight user poetic liscence' - me |