Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!rpi!crdgw1!camelback!volpe
From: volpe@camelback.crd.ge.com (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: Pointer arithmetic
Message-ID: <15486@crdgw1.crd.ge.com>
Date: 9 Jan 91 16:25:02 GMT
References: <1991Jan5.001607.5915@demott.com> <1991Jan7.173726.1003@alias.uucp> <14794@smoke.brl.mil>
Sender: news@crdgw1.crd.ge.com
Reply-To: volpe@camelback.crd.ge.com (Christopher R Volpe)
Lines: 18

In article <14794@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes:
|>The actual error in this code is the mixing of pointers to char and
|>to unsigned char.  If the compiler still complains after that error
|>is remedied, then it has a problem.  Ensuring that pointer arithmetic
|>involves valid operands in this situation is entirely the programmer's
|>responsibility, not the compiler's.  Assuming that everything is declared
|>properly and that the chars string contains all possible runtime values
|>of toupper(...), the above pointer arithmetic (with types fixed) is
|>strictly conforming and thus the C implementation should NOT issue a
|>diagnostic.

I assume you mean "should NOT fail to generate correct code", right?
It can, of course, issue a diagnostic if it's raining outside or if
it's past 5:00pm on a Friday.               
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com