Version 10.00 (RC1) is now available

[bitcoin]

Pelle, what you think about adding:
- ASLR support ( in compiler options in IDE, such as https://forum.pellesc.de/index.php?topic=5185.msg19922#msg19922 )
- retry instruction (in LCC: Provokes a jump to the start of the try/except block );

Or this is bad ideas?

[Marco]

I just found out that a program of mine crashes when compiled with PellesC v10. This does not happen when I compile it with Pellesc v6.50. To be more precise, the program is executed correctly, but it crashes when it tries to show a Save dialog box (it uses the IFileOpenDialog COM interface). This Save dialog box checks the selected file name before closing the window (it uses the IFileDialogEvents:OnFileOk method). I used the same code used in the FileDlgs.zip file, located in the source code section of the Web site. So, I compiled that demo file, and it also crashes when the executable tries to show the Save dialog box (it shows the Open dialog box with no problems instead). It seems that the crash occurs when the program executes the instruction "hr = IFileSaveDialog_Advise(pfsd, pfde, &dwCookie);" (line 234 of the "main.c" file). I'm not a COM expert, so I don't know if it's a compiler problem or a code problem. I thought it was worth reporting it.

[Pelle]

Pelle, what you think about adding:
- ASLR support ( in compiler options in IDE, such as https://forum.pellesc.de/index.php?topic=5185.msg19922#msg19922 )

It's enabled automatically by the linker when the major subsystem version is >= 6 (Windows Vista+). The default subsystem version depends on the selected subsystem type, but for "Console" and "Windows" it's 6.0 (so enabled by default). Adding an option for "/DYNAMICBASE" will likely add more confusion than help, I suspect...

- retry instruction (in LCC: Provokes a jump to the start of the try/except block );

I'm not familiar with "retry", but it sounds like a normal C statement (like goto) should work. Or am I missing something?

[Pelle]

I just found out that a program of mine crashes when compiled with PellesC v10. This does not happen when I compile it with Pellesc v6.50. To be more precise, the program is executed correctly, but it crashes when it tries to show a Save dialog box (it uses the IFileOpenDialog COM interface). This Save dialog box checks the selected file name before closing the window (it uses the IFileDialogEvents:OnFileOk method). I used the same code used in the FileDlgs.zip file, located in the source code section of the Web site. So, I compiled that demo file, and it also crashes when the executable tries to show the Save dialog box (it shows the Open dialog box with no problems instead). It seems that the crash occurs when the program executes the instruction "hr = IFileSaveDialog_Advise(pfsd, pfde, &dwCookie);" (line 234 of the "main.c" file). I'm not a COM expert, so I don't know if it's a compiler problem or a code problem. I thought it was worth reporting it.

Thanks for reporting this! It looks like a problem with the code. I will upload a new version when I have fixed it (could take a few days).

[Pelle]

I will upload a new version when I have fixed it (could take a few days).

Yes I will, and now it's fixed and uploaded... (that wasn't so hard, was it? "A few days"... bah!)

[Marco]

Thank you very much. Pelle! I applied the fix also in my program and (of course) it does work flawlessly.

[John Z]

Hi,

This error is similar to one reported by Marco.  Under version 9 there is no issue but under version 10
RC1 the following statement always fails, even when it should resolve as TRUE

    if ((_stristr(p_LineIn, "JPEG") != NULL) || (_stristr(p_LineIn, "JPG") != NULL))
unless the left side(s) is/are resolved before executing the if, so changing into

char *po1 = _stristr(p_LineIn, "JPEG") ;
char *po2 = _stristr(p_LineIn, "JPG");
  if (po1 != NULL) || (po2 != NULL))

and then it works perfectly.

John

[John Z]

Hi,

The new UI for Project Options:
On the Linker "Library and objects files:" edit box it needs to be able to auto wrap, horizontal scroll bar, or at least allow the cursor to scroll the text.  Half of the library entries can't be seen or accessed. Attached screen shot.

This may be an issue across the new UI in several screens, for example Define Symbols

Regards,
John

[Marco]

Today I compiled another of my programs and the compiler gave me the following error:

fatal error: Internal error: 'Access violation' at 0x00007ffd3f842503

I spent some time in order to understand what was wrong with code and I found out that the problem was related to an #include preprocessor directive. It seems that the compiler does not "like" the #include preprocessor directive if it does include a relative path similar to "..\..\header.h". So, for example:

#include "..\header.h"        // <-- ok
#include "..\..\header.h"     // <-- fatal error

[Pelle]

The new UI for Project Options:
On the Linker "Library and objects files:" edit box it needs to be able to auto wrap, horizontal scroll bar, or at least allow the cursor to scroll the text.  Half of the library entries can't be seen or accessed. Attached screen shot.

Thanks. Found it myself a few days ago.

[Pelle]

This error is similar to one reported by Marco.  Under version 9 there is no issue but under version 10
RC1 the following statement always fails, even when it should resolve as TRUE
...

I can't reproduce this. Please provide a complete, compilable, example demonstrating the problem.

[Pelle]

Today I compiled another of my programs and the compiler gave me the following error:

fatal error: Internal error: 'Access violation' at 0x00007ffd3f842503

I spent some time in order to understand what was wrong with code and I found out that the problem was related to an #include preprocessor directive. It seems that the compiler does not "like" the #include preprocessor directive if it does include a relative path similar to "..\..\header.h". So, for example:

#include "..\header.h"        // <-- ok
#include "..\..\header.h"     // <-- fatal error

I must be missing something, similar cases works fine here. Can you provide a more complete example?

[John Z]

This error is similar to one reported by Marco.  Under version 9 there is no issue but under version 10
RC1 the following statement always fails, even when it should resolve as TRUE
...

I can't reproduce this. Please provide a complete, compilable, example demonstrating the problem.

MY error a preceding buffer had an overflow by a few bytes that somehow was innocuous when V9 compiles and reorganizing the code in V10 just further obscured the real issue   - Sorry 

Update 6/25
Well it is not that simple either. Still trying to pinpoint and replicate in a smaller code piece. It only happens with optimize for speed selected in V10 but does not happen in V9 with the same optimization selected. Basically a wchar_t pointer ends up pointing at a location within a declared char pointer space even though the wchar_t pointer is never touched after the declaration and assignment to its own space.  It 'seems' that I can prevent this by moving a memset for the wchar_t pointer space earlier in the code.  Strange indeed.  But until I can replicate I'm not faulting the optimizer, most likely I've done something weird. 

[Marco]

I can't reproduce this. Please provide a complete, compilable, example demonstrating the problem.

After reading what you wrote, I investigated the issue further. I use a very simple batch file to compile my programs, and I found out that the problem was related to the declaration of the INCLUDE environment variable. The INCLUDE variable was set as following:

set INCLUDE=\include;%PellesCDir%\Include;%PellesCDir%\Include\Win;%INCLUDE%

The very first "\include" path does not exists, and it "crashes" the compiler. After removing that path, the compiler did work as expected. Of course, that path was erroneously entered (my mistake) and the old compiler (v6.50) never worried about it.

[Pelle]

After reading what you wrote, I investigated the issue further. I use a very simple batch file to compile my programs, and I found out that the problem was related to the declaration of the INCLUDE environment variable. The INCLUDE variable was set as following:

set INCLUDE=\include;%PellesCDir%\Include;%PellesCDir%\Include\Win;%INCLUDE%

The very first "\include" path does not exists, and it "crashes" the compiler. After removing that path, the compiler did work as expected. Of course, that path was erroneously entered (my mistake) and the old compiler (v6.50) never worried about it.

Hmm. The compiler should never crash, but I still have trouble reproducing this (and the code in v10 is ~98% different from v6.50, so no point in comparing them). I will test some more, but if you have any additional info it would be helpful...