Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!rutgers!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: C and overflow anomolies
Message-ID: <16905@sun.uucp>
Date: Fri, 17-Apr-87 12:19:50 EST
Article-I.D.: sun.16905
Posted: Fri Apr 17 12:19:50 1987
Date-Received: Sun, 19-Apr-87 12:08:14 EST
References: <15958@sun.uucp> <5716@brl-smoke.ARPA> <14680@cca.CCA.COM> <790@xanth.UUCP> <995@wanginst.EDU> <820@xanth.UUCP> <386@sdd.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Distribution: world
Organization: Sun Microsystems, Mountain View
Lines: 11
Keywords: C overflow anomolies execution order parentheses

>	Why not utilize a #pragma NO_OPTIMIZE & a counter pragma #pragma
>OPTIMIZE around code that is to executed as is  Perhaps we can even create
>various classes of pragmas for different optimizations:  #pragma NO_OPTIMIZE
>LOOPS, #pragma NO_OPTIMIZE_STRENGTH, etc.

"We" can't create any sort of pragma classes.  #pragmas are
compiler-dependent.  There's no guarantee that a particular compiler
knows about the categories of optimization you know about, with the
possible exception of "#pragma OPTIMIZE" and "#pragma NO_OPTIMIZE".
The standard should do as little as possible to constrain the forms
of optimizing technology used in comn M   ~r