From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,HEADER_SPAM,
	INVALID_DATE,MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no
	autolearn_force=no version=3.4.4
Xref: utzoo comp.compilers:263 comp.software-eng:636 comp.lang.ada:1302 comp.lang.c:10838 comp.lang.fortran:789 comp.lang.modula2:895 comp.lang.pascal:940 comp.lang.misc:1680
Path: utzoo!utgpu!water!watmath!clyde!ima!compilers-sender
From: byrum@sleet.cs.odu.edu
Newsgroups: comp.compilers,comp.software-eng,comp.lang.ada,comp.lang.c,comp.lang.fortran,comp.lang.modula2,comp.lang.pascal,comp.lang.misc
Subject: Software Transformation Problems
Message-ID: <1130@ima.ISC.COM>
Date: 21 Jun 88 18:12:23 GMT
Sender: compilers-sender@ima.ISC.COM
Reply-To: byrum@sleet.cs.odu.edu
Organization: Old Dominion University, Norfolk, Va.
List-Id: <comp.lang.ada>

I am conducting some research in software transformation. One problem area
involves source-to-source changes in which the new piece of code does not
perform as the original. The source-to-source modifications are assumed to be
"semantically correct." These may be errors induced either by mistakes in the
original code or by the programmer's taking advantage of the compiler's
characteristics. Could all you people in net land send me some of your horror
stories and/or problems encountered during development and/or maintenance?
Examples in any language are welcome.

I thought of some interesting problems with source-to-source transformations
on C code. Below is the example.

The problem is due to several library functions that work with
strings.

Consider:

>> #include <stdio.h>
>> 
>> #define LONGSTRING	"1234567890123"
>> 
>> main()
>> {
>> 	extern char *strcpy();
>> 
>> 	char string[10], a, b, c;
>> 
>> 	strcpy( string, LONGSTRING);
>> 	printf( "the string is {%s}\n", string);
>> 	a = 'A';
>> 	b = 'B';
>> 	c = 'C';
>> 	printf( "a = {%c} b = {%c} c = {%c}\n", a, b, c);
>> }

Notice that the programmer takes advantage of string and the variable space
behind it.  LONGSTRING consist of 13 characters and string has only 10
allocated spaces in the array.

OUTPUT:
>> the string is {1234567890123}
>> a = {A} b = {B} c = {C}

Now consider:

>> #include <stdio.h>
>> 
>> #define LONGSTRING	"1234567890123"
>> 
>> main()
>> {
>> 	extern char *strcpy();
>> 
>> 	char string[10], a = 'A', b = 'B', c = 'C';
>> 
>> 	strcpy( string, LONGSTRING);
>> 	printf( "the string is {%s}\n", string);
>> 	printf( "a = {%c} b = {%c} c = {%c}\n", a, b, c);
>> }

Notice, that the assignments of a, b, and c have been moved to the declaration.
Since a, b, and c have no other dependencies in the program, this is a legal
source-to-source transformation.

OUTPUT
>> the string is {1234567890123}
>> a = {1} b = {2} c = {3}

	I have found that through carelessness this type of problem may occur 
often.  (I realize that the programmer should be responsible for checking the 
array bounds!)  This is just an example of a piece of code that works before 
transformation and not after.

	If people are interested I will compile the best examples and
repost them.  Any help is appreciated.

	Direct flames to /dev/null.  Respond by email, not posting.  If I
get enough responses, I will summarize. 


                                |  Terry Franklin (Frank) Byrum
                                |  Old Universion University
   ___                          |  INET:  byrum@cs.odu.edu
  /__  _.  __. _ _  /_          |  UUCP:  ...!uunet!xanth!brooks!byrum 
 /   _/ \_(_/|_|\|_/ \          |  DISCLAIMER: No one listens anyway! 
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request