Version 6.0, Release Candidate #1 available

[Pelle]

Pelles C version 6.0, Release Candidate #1, is now available for download:
http://www.smorgasbordet.com/pellesc/download.htm

The German translation will be added later.

Pelle

[Romashka]

Many thanks!

BTW, I've noticed that there is no more 'Include files' subtree in filelist.
Is it a bug or an intended change?

[JohnF]

Thanks Pelle.

I have "Invalid jump into 'VLA' block." error - as far as I can see nothing jumps into a VLA block. The error occurs on a goto line.

I use a few goto statements to label cleanup;

Here is the cleanup part

  cleanup:
   // release interfaces
   if (pIDragSourceHelper)
      pIDragSourceHelper->lpVtbl->Release(pIDragSourceHelper);
   if (pIDataObject)
      pIDataObject->lpVtbl->Release(pIDataObject);
   if (pIDropSource)
      pIDropSource->lpVtbl->Release(pIDropSource);
   if (pIDropTarget)
      pIDropTarget->lpVtbl->Release(pIDropTarget);

   RevokeDragDrop(hwndMain);
   if(hbm){
      DeleteObject(hbm);
   }
   if(pp[0]){
      free(pp[0]);
   }
   return ret;

EDIT: That's in the 32 bit version.

John

[Pelle]

Romashka: I now filter out include files located outside the (top-level) project (directory). I had a number of projects where I found it very confusing to see irrelevant include files in the project tree (not my own files).

John: a "VLA block" should never be created unless there actually is variable-length array somewhere. Are you, for example, setting the size of an array using a "const int ..." variable, or similar. In C this *will* create a VLA, unlike C++ and some other buggy C compilers...

If not: is it possible to make a smaller, compilable, example?

[Romashka]

I now filter out include files located outside the (top-level) project (directory). I had a number of projects where I found it very confusing to see irrelevant include files in the project tree (not my own files).

Aha, the problem is that my sources are in a sibling tree of a project directory, not a child tree.
Since they are referred as ..\sources\*.{c,h} in .ppj files - shouldn't IDE know that it should display all header files listed in .ppj?

[ssb]

Just a few UI issues I've noticed so far.

1. Resizable dialog size (IDE) not saved.
2. Installer not using system default dialog font. Quite minor issue, but MS Sans Serif looks really crappy under Vista.
3. Same as #2 but in dialogs of process viewer and registry editor applets (about, find, view from timestamp, etc.).
4. Still no "delete active line" editor command. Dear Pelle, could you please consider implementing this old suggestion in v6 final?

Thank you for the v6. Really appreciated your efforts!

[Pelle]

1) By design.
2) MS Sans Serif looks pretty everywhere, the Vista font looks ugly everywhere.
3) See 2)
4) See 1)

[JohnF]

Pelle,

Here is a small fragment that shows my problem.

As you can see the code does have a VLA but there never used to be a problem.

Code: [Select]

int Drop(void)
{
int ret = 0;

int nItems = 10;
if (!nItems){
goto cleanup;
}

int indexs[nItems];

  cleanup:

return ret;
}

John

[ssb]

1) By design.
2) MS Sans Serif looks pretty everywhere, the Vista font looks ugly everywhere.
3) See 2)
4) See 1)

1. Hmm, I assume I can live with it.
2. I'd agreed if Vista wasn't the current OS version. A simple OS detect - font substitution function could do the job. After all, the standard alternative dialog font (Tahoma) looks pretty everywhere, incuding Vista and Win7.
3. Same as #2.
4. With all respect, is it so hard to implement such a simple functionality? Certainly you are who decide what's useful or not, but do you really know many code editors without a "delete-line" command?

Thanks!

[Pelle]

John,

Yes, it used to work - except maybe for a brief period in some beta, a few versions back, when I tried to add this check the last time.

At least in your example it's possible to put the array in a new block (scope):

Code: [Select]

    /* new block */
    {
        int indexs[nItems];
        ...
    }
My copy of the C99 standard contains the following example, which may be open to some interpretation:

EXAMPLE 2 A goto statement is not allowed to jump past any declarations of objects with variably
modified types. A jump within the scope, however, is permitted.

Code: [Select]

goto lab3; // invalid: going INTO scope of VLA.
{
double a[n];
a[j] = 4.4;
lab3:
a[j] = 3.3;
goto lab4; // valid: going WITHIN scope of VLA.
a[j] = 5.5;
lab4:
a[j] = 6.6;
}
goto lab4; // invalid: going INTO scope of VLA.

[JohnF]

Pelle,

======================
My copy of the C99 standard contains the following example, which may be open to some interpretation:

EXAMPLE 2 A goto statement is not allowed to jump past any declarations of objects with variably
modified types. A jump within the scope, however, is permitted.
======================

Ok I see where you are coming from but surely the VLA in my example is in scope until the end of the function. My label cleanup is therefor in scope. No?

John

[Pelle]

Ok I see where you are coming from but surely the VLA in my example is in scope until the end of the function. My label cleanup is therefor in scope. No?

Yes, but you are also jumping *around* the declaration: int indexs[nItems]; -- but I assume to a point in the code where the array isn't used anymore. The compiler isn't cleaver enough to track variable "liveness" at this point in the process (where the warning is issued), it only looks at blocks (scopes).

I guess the general idea is that "int indexs[nItems];" will generate some form of machine code with any compiler (to allocate the array), and the source code shouldn't be able to jump past that point to a place where it uses the (uninitialized) array.

EDIT: At least one Intel compiler seems to agree with me:
test.c(7): error: transfer of control bypasses initialization of:
            variable length array "indexs" (declared at line 10)
          goto cleanup;
          ^

[Pelle]

snip

2. Since M$ apparently can't be bothered making a better upgrade path for dialog fonts and new visual styles, I'm certainly not going to do the job for them. I will continue to use "MS Shell Dlg" for now.
4. I don't like it, I won't add it. This has now been explained to you many times. Nagging about it some more isn't going to help you. Good bye.

[JohnF]

Pelle,

Ok, I'll find a way around it. Thanks.

John

[jwzumwalt]

Pelle,

I wanted to thank you and the rest of the group for the mature communication that takes place regarding PelleC. I noticed in another post you placed a goal of not having a "jillion" option interface. I agree. Of course everyone likes there particular idiosyncrasies to be catered to... (I would like the cursor to go past the end of the line!). But the last couple of conversations that others have had struck me as unusually civil for strangers with differing views on the internet.

I think it speaks quite well of the users and your development cycle that others are excepting the devotion that a volunteer project requires in time and resources. Keep up the good work!