[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    Bug#953: kimgio returns grayscale jpeg
From:       Carsten Prinz <cprinz () mail ! uni-mainz ! de>
Date:       1999-06-29 23:48:01
[Download RAW message or body]


>This appears to be the fault of egcs, and not the code.  Statements should
>be evauluated left to right (well at least it seems this way).  Have you
>tried compiling with lesser optimizations enabled?

Some compilers do evaluate left to right, but in standard c the order of
evaluation ist not defined (exceptions are only &&, ||, ?: and the ","
operator, according to K&R)
If you want to make sure that an expression is
evaluated in a specific order, you have to split the expression and use
temporary variables.

Besides the multiple use of post -increment/decrement operators on the same
variable inside one expression is not defined, too.

The c-faq at comp.lang.c mentions the following:

"3.2:	Under my compiler, the code

		int i = 7;
		printf("%d\n", i++ * i++);

	prints 49.  Regardless of the order of evaluation, shouldn't it
	print 56?

A:	Although the postincrement and postdecrement operators ++ and --
	perform their operations after yielding the former value, the
	implication of "after" is often misunderstood.  It is *not*
	guaranteed that an increment or decrement is performed
	immediately after giving up the previous value and before any
	other part of the expression is evaluated.  It is merely
	guaranteed that the update will be performed sometime before the
	expression is considered "finished" (before the next "sequence
	point," in ANSI C's terminology; see question 3.8).  In the
	example, the compiler chose to multiply the previous value by
	itself and to perform both increments afterwards.

	The behavior of code which contains multiple, ambiguous side
	effects has always been undefined.  (Loosely speaking, by
	"multiple, ambiguous side effects" we mean any combination of
	++, --, =, +=, -=, etc. in a single expression which causes the
	same object either to be modified twice or modified and then
	inspected.  This is a rough definition; see question 3.8 for a
	precise one, and question 11.33 for the meaning of "undefined.")
	Don't even try to find out how your compiler implements such
	things (contrary to the ill-advised exercises in many C
	textbooks); as K&R wisely point out, "if you don't know *how*
	they are done on various machines, that innocence may help to
	protect you."

	References: K&R1 Sec. 2.12 p. 50; K&R2 Sec. 2.12 p. 54; ANSI
	Sec. 3.3; ISO Sec. 6.3; CT&P Sec. 3.7 p. 47; PCS Sec. 9.5 pp.
	120-1."

------------------------------------------------------------------
Carsten Prinz
cprinz@mail.uni-mainz.de
------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]