GSoC :Project Idea(Before final Submission) for review and feedback

[Oleg Endo]

Please reply in CC to the GCC mailing list, so others can follow the
discussion.

On Sun, 2012-03-25 at 09:21 +0530, Subrata Biswas wrote:
> On 25 March 2012 03:59, Oleg Endo <oleg.endo@t-online.de> wrote:
> >
> > I might be misunderstanding the idea...
> > Let's assume you've got a program that doesn't compile, and you leave
> > out those erroneous blocks to enforce successful compilation of the
> > broken program.  How are you going to figure out for which blocks it is
> > actually safe to be removed and for which it isn't?
> 
> I can do it by tracing the code blocks which are dependent on the
> erroneous block. i.e if any block is data/control dependent(the output
> or written value of the erroneous part is read) on this erroneous
> block or line of code will be eliminated.
> 
> > Effectively, you'll
> > be changing the original semantics of a program, and those semantic
> > changes might be completely not what the programmer originally had in
> > mind.  In the worst case, something might end up with an (un)formatted
> > harddisk...*
> >
> > Cheers,
> > Oleg
> >
> Thank you sir for your great feedback. You have understood it
> correctly. Now the programmer will be informed about the change in
> code and the semantics.(Notice that this plug-in is not going to
> modify the original code!, it just copy the original code and perform
> all the operations on the temporary file!!!) Even from the partial
> execution of the code the programmer will get an overview of his
> actual progress.
> 
> suppose the program written by the programmer be:
> 
> 1 int main(void)
> 2 {
> 3    int arr[]={3,4,-10,22,33,37,11};
> 4    sort(arr);
> 5    int a = arr[3] // Now suppose the programmer missed the semicolon
> here. Which generates a compilation error at line 5;
> 6    printf("%d\n",a);
> 7    for(i=0;i<7;i++)
> 8    {
> 9        printf("%d\n",arr[i]);
> 10    }
> 11  }
> 
> 
> Now if we just analyze the data (i.e. variable), we can easily find
> that there is only data dependency exists between line 5 and line 6.
> The rest of the program is not being effected due to elimination or
> commenting line 5.
> 
> Hence the temporary source file after commenting out the erroneous
> part of the code and the code segment that is dependent on this
> erroneous  part would be:
> 
> 1 int main(void)
> 2 {
> 3    int arr[]={3,4,-10,22,33,37,11};
> 4    sort(arr);
> 5    //int a = arr[3] // Now suppose the programmer missed the
> semicolon here. Which generates a compilation error at line 5;
> 6   // printf("%d\n",a);
> 7    for(i=0;i<7;i++)
> 8    {
> 9        printf("%d\n",arr[i]);
> 10    }
> 11  }
> 
> Now this part of the program(broken program) is error free. Now we can
> compile this part using GCC and get the partial executable.
> 
> Now the possible output after compilation using this plug in(if
> programmer use it) with GCC would be:
> 
> "You have syntax error at Line no. 5. and to generate the partial
> executable Line 5 and Line 6 have removed in the temporary executable
> execute the partial executable excute p.out"
> 
> Advantages to the Programmer:
> 1. If programmer can see the result of the partial executable he can
> actually quantify his/her progress in code.
> 2. The debug become easier as this plug-in would suggest about
> possible correction in the code etc.

I don't think it will make the actual debugging task easier.  It might
make writing code easier (that's what IDEs are doing these days while
you're typing code...).  In order to debug a program, the actual bugs
need to be _in_ the program, otherwise there is nothing to debug.
Removing arbitrary parts of the program could potentially introduce new
artificial bugs, just because of a missing semicolon.

> * I did not understand the  worst case that you have mentioned as
> (un)formatted hard disk. Can you kindly explain it?
> 

Let's say I'm writing a kind of disk utility that reads and writes
sectors...

---------------------
source1.c:

bool
copy_sector (void* outbuf, const void* inbuf, int bytecount)
{
  if (bytecount < 4)
    return false;
  
  if ((bytecount & 3) != 0)
    return false;

  int* out_ptr = (int*)outbuf;
  const int* in_ptr = (const int*)inbuf;
  int count = bytecount / 4;

  do
  {
    int i = *in_ptr++;
    if (i & 1)
      i = do_something_special0 (i);
    else if (i & (1 << 16))
      i = do_something_special1 (i);
    *out_ptr++ = i;
  } while (--count);

  return true;
}

---------------------
source0.c:

int main (void)
{
  ...
  int sector_size = get_sector_size (...);
  void* sector_read_buf = malloc (sector_size);
  void* sector_write_buf = malloc (sector_size);

  while (sector_count > 0)
  {
    read_next_sector (sector_read_buf);
    if (copy_sector (sector_write_buf, sector_read_buf, sector_size))
      write_next_sector (sector_write_buf);
  }
  ...
}


Let's assume that in the function copy_sector in source1.c there is a
syntax error:

  do
  {
    int i = *in_ptr++;
    if (i & 1)
      i = do_something_special0 (i);
    else if (i & (1 << 16))
      i = do_something_special1 (i);

    *outptr++ = i;  // misspelled 'out_ptr'.
                    // There is no such variable 'outptr'.
                    // This line will be left out to make it compile.

  } while (--count);


If this broken program is executed it will happily transform data into
garbage.


Another example could be (copy_sector function again):

  if (bytcount < 4)  // syntax error again, if block is removed
    return false;    // to enforce compilation.

Now the copy_sector function will happily accept values <= 0 for
'bytecount', which will most likely end up in an integer overflow and a
page fault...

Those might be overly extreme and/or silly examples.  What I'm trying to
say is that by leaving out program parts, there is a risk of introducing
artificial data corruption or artificial infinite loops that
accidentally overwrite data.

Cheers,
Oleg