Pelles C forum

Pelles C => Announcements => Topic started by: Pelle on July 14, 2020, 03:43:00 PM

Title: Version 10.00 (RC3) is now available
Post by: Pelle on July 14, 2020, 03:43:00 PM
Pelles C version 10.00 (Release Candidate #3) is now available for download:
http://www.smorgasbordet.com/pellesc/download.htm

Major changes:
http://www.smorgasbordet.com/pellesc/changes_900_1000.htm

Changes for RC3:

Hopefully the last release candidate...

/Pelle
Title: Re: Version 10.00 (RC3) is now available
Post by: briman on July 14, 2020, 05:13:55 PM
Thank You  ;D
Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 14, 2020, 06:23:17 PM
Thank You  ;D
You're welcome  ;D
Title: Re: Version 10.00 (RC3) is now available
Post by: John Z on July 14, 2020, 09:45:28 PM
Great news Pelle - Thanks !

I hope everyone appreciates your hard work.

John Z
Title: Re: Version 10.00 (RC3) is now available
Post by: MrBcx on July 15, 2020, 05:39:13 AM
Thank you Pelle ...

I've tested several large apps and about 200 sample programs with RC3 - all compiled and ran as expected.

Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 15, 2020, 12:25:14 PM
Thank you, John Z and MrBCX.

Hopefully nothing major pops up in the next week or two, and it can be "officially" released...
Title: Re: Version 10.00 (RC3) is now available
Post by: John Z on July 15, 2020, 04:13:36 PM
New in version 10, in code I did not write but I use, for creating zip files I'm seeing
 warning #2805: Possible violation of strict-aliasing rules
this was not shown in version 9.  Version 10 may just detect the issue better?
The version 10 zip file seems to be created ok, even with optimizations on,
but I'd rather be sure.  I'm hesitant to modify the code I did not write so I'm hoping for a lazy solution.

Searching the help file I did not find a pragma or flag to disable strict-aliasing - is there one?

Thanks,
John Z
Title: Re: Version 10.00 (RC3) is now available
Post by: frankie on July 15, 2020, 06:06:20 PM
Seems a great job again  ;)
Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 15, 2020, 06:16:39 PM
Thanks, frankie...  :)
Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 15, 2020, 06:33:04 PM
New in version 10, in code I did not write but I use, for creating zip files I'm seeing
 warning #2805: Possible violation of strict-aliasing rules
this was not shown in version 9.  Version 10 may just detect the issue better?

There is a new version of this warning in version 10, I think it was completely disabled in version 9.0. Hopefully the new variation will have less false positives (but will probably not find all cases).

The version 10 zip file seems to be created ok, even with optimizations on,
but I'd rather be sure.  I'm hesitant to modify the code I did not write so I'm hoping for a lazy solution.

Other compilers are getting more aggressive about optimizing alias violations, at least if told to (or not told to avoid it). This can lead to surprises, which I'm trying to be helpful about. I will never perform optimizations based on this myself.

This may be helpful:
https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8 (https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8)

Searching the help file I did not find a pragma or flag to disable strict-aliasing - is there one?

You can always disable a specific warning through...
Code: [Select]
#pragma warn(disable:number)...or by using the compiler option...
Code: [Select]
/Wdnumber(the number is part of the warning message: ... #number ...)
... but if you have control over the code, it's obviously better to fix the code rather than blindly disabling the warning.
Title: Re: Version 10.00 (RC3) is now available
Post by: John Z on July 16, 2020, 12:08:05 AM
Pelle, thanks for the explanation. It makes sense.

You can always disable a specific warning through...
Code: [Select]
#pragma warn(disable:number)...or by using the compiler option...
Code: [Select]
/Wdnumber(the number is part of the warning message: ... #number ...)
... but if you have control over the code, it's obviously better to fix the code rather than blindly disabling the warning.
In my own code I never disable the warnings. 
Every warning is resolved so that no warnings are issued under a level 2 build.  Totally clean.  So I agree it is better to fix the code, or maybe replace it with a better coded zip library.  One common method to 'fix' this is to use unions so I may see how involved that will be.  If too complex I may seek a new zip lib.


Appreciate your inputs,
John Z
Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 16, 2020, 03:17:43 PM
Yes, unions are good.

For loading values, functions like these should also work (most compilers will optimize properly):
Code: [Select]
/* load 16-bit integer, little-endian */
static inline uint16_t load_uint16_le(const void *vp)
{
    const uint8_t *bp = vp;
    return (uint16_t)bp[0] << 0 |
           (uint16_t)bp[1] << 8;
}

Code: [Select]
/* load 32-bit integer, big-endian */
static inline uint32_t load_uint32_be(const void *vp)
{
    const uint8_t *bp = vp;
    return (uint32_t)bp[0] << 24 |
           (uint32_t)bp[1] << 16 |
           (uint32_t)bp[2] << 8 |
           (uint32_t)bp[3] << 0;
}

(It should be fairly trivial to create the missing functions, I will not post all of them).
Title: Re: Version 10.00 (RC3) is now available
Post by: John Z on July 17, 2020, 01:20:11 AM
 :)
Thanks - got me started....


John Z
Title: Re: Version 10.00 (RC3) is now available
Post by: Marco on July 17, 2020, 05:59:04 PM
I know it's a little bit late, but thank you from me too!
Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 17, 2020, 07:09:04 PM
No problem Marco... thanks!  :)
Title: Re: Version 10.00 (RC3) is now available
Post by: Marco on July 18, 2020, 12:29:20 PM
Hello. I've a very old source program that uses the GlobalAllocPtr/GlobalFreePtr macros. When compiled, the compiler shows the following warning:
Code: [Select]
warning #2046: Expression with no effect removed.

The above warning is related to the GlobalFreePtr macro. Here is a very simple example to reproduce the warning:
Code: [Select]
char *buf = (char*) GlobalAllocPtr(GPTR, 2048);
if (buf) {
    lstrcpy(buf, "some text");
    GlobalFreePtr(buf);           // <-- warning #2046
}

If I change both macros with the GlobalAlloc/GlobalFree functions, no warning is shown.

I'm just out of curiosity: why does that warning occur?
 
Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 18, 2020, 02:09:32 PM
I'm just out of curiosity: why does that warning occur?
This is an early warning, and it comes from dropping an internal conversion operator created by a type-cast. Pretty unhelpful warning, if you ask me.
If I can find an easy way to silence a warning like this for version 10.0 I will do it, otherwise it will have to wait until the next version.
Title: Re: Version 10.00 (RC3) is now available
Post by: Marco on July 18, 2020, 03:14:53 PM
Thank you for the explanation, Pelle :)
Title: Re: Version 10.00 (RC3) is now available
Post by: algernon77 on July 20, 2020, 05:49:45 PM
First of all, thanks for your effort! I'm using it since v7 and liking it a lot!
Seems to build all my old OpenWatcom projects correctly.

I seem to have a couple of issues with the ide, though. One is that I've checked the "Just-in-time debugging"debugger option, and now it's always checked, even if I uncheck it and click OK in the Options dialog (I'm logged with an administrative account on Win7 x64).

The other would be with the functions database of a particular project. It has about 70 functions declared and defined in a single file, but the browser on the right shows only about 15. On other projects with smaller nr. of functions per module (about 20), all seem to be ok. I tried deleting the tag file and rebuilding, but no luck. I'll attach a screenshot below. Am I doing something really outrageous?  :)
Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 21, 2020, 02:28:03 PM
I seem to have a couple of issues with the ide, though. One is that I've checked the "Just-in-time debugging"debugger option, and now it's always checked, even if I uncheck it and click OK in the Options dialog (I'm logged with an administrative account on Win7 x64).
Hm. I can't reproduce this on my machine. Windows 10, but it shouldn't matter.

The other would be with the functions database of a particular project. It has about 70 functions declared and defined in a single file, but the browser on the right shows only about 15. On other projects with smaller nr. of functions per module (about 20), all seem to be ok. I tried deleting the tag file and rebuilding, but no luck. I'll attach a screenshot below. Am I doing something really outrageous?  :)
The screenshot only contain function prototypes, the project tree will only contain function definitions, but apart from that I can't say very much: not enough information.

The list of functions in the project tree comes from the browse info manager, which is not a full compiler, so there could be something in the syntax that the compiler can handle but not the browse info manager.

If you are comfortable with the command-line, you could try running the following...
pobr -b -f tempname.tag -w -l -kf yourfile.c
... and see how many function definitions are printed on the screen.
Title: Re: Version 10.00 (RC3) is now available
Post by: algernon77 on July 21, 2020, 04:22:42 PM
The other would be with the functions database of a particular project. It has about 70 functions declared and defined in a single file, but the browser on the right shows only about 15. On other projects with smaller nr. of functions per module (about 20), all seem to be ok. I tried deleting the tag file and rebuilding, but no luck. I'll attach a screenshot below. Am I doing something really outrageous?  :)
The screenshot only contain function prototypes, the project tree will only contain function definitions, but apart from that I can't say very much: not enough information.

The list of functions in the project tree comes from the browse info manager, which is not a full compiler, so there could be something in the syntax that the compiler can handle but not the browse info manager.

If you are comfortable with the command-line, you could try running the following...
pobr -b -f tempname.tag -w -l -kf yourfile.c
... and see how many function definitions are printed on the screen.

All the function definition are in the same file, under the prototypes, but it's about 176k of text, so they don't show in the screenshot.
HOWEVER  8) good news: after some sifting through the file with the pobr command line tool, I finally found the culprits: only 2 functions, see below:

Code: [Select]
static LRESULT CALLBACK OpenProc ( DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG FAR * pcb )
/*****************************************************************************************************************/
{
    switch ( g_file_enc )
    {
        case E_DONT_BOTHER:
        case E_ASCII:
            ReadFile ( ( HANDLE )dwCookie, pbBuff, cb, (LPDWORD)pcb, NULL );
            break;

        case E_WHATEVER:
            // check encoding
            break;

    }
   
    if ( g_hProgress )
    {
        SendMessage ( g_hProgress, PBM_SETRANGE, 0, MAKELPARAM ( 0, g_dwsize / cb ) );
        SendMessage ( g_hProgress, PBM_SETSTEP, ( WPARAM ) 1, 0 );
        SendMessage ( g_hProgress, PBM_STEPIT, 0, 0 );
    }

    return FALSE;
}

static LRESULT CALLBACK SaveProc ( DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG FAR * pcb )
/*****************************************************************************************************************/
{
    WriteFile ( ( HANDLE )dwCookie, pbBuff, cb, (LPDWORD)pcb, NULL );
    if ( g_hProgress )
    {
        SendMessage ( g_hProgress, PBM_SETRANGE, 0, MAKELPARAM ( 0, g_dwsize / cb ) );
        SendMessage ( g_hProgress, PBM_SETSTEP, ( WPARAM ) 1, 0 );
        SendMessage ( g_hProgress, PBM_STEPIT, 0, 0 );
    }
    return FALSE;
}

More precisely, it doesn't seem to like the "LONG FAR" combination, tried "const LONG * pcb" and "const FAR * pcb" and it works, but "LONG FAR" no :-)
Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 21, 2020, 05:42:01 PM
More precisely, it doesn't seem to like the "LONG FAR" combination, tried "const LONG * pcb" and "const FAR * pcb" and it works, but "LONG FAR" no :-)
OK, cool. I guess it's mainly "FAR", which has been dead as a dodo for many years...
I will try to fix this in the upcoming release version.

EDIT: When compiling, the FAR/NEAR/far/near macros will expand to nothing, so for consistency the Browse Information Manager will do the same (in the upcoming version).
Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 21, 2020, 06:20:36 PM
algernon77,
Regarding "Just-in-time debugging", what is the output if you run the attached program/project?
Title: Re: Version 10.00 (RC3) is now available
Post by: algernon77 on July 21, 2020, 07:10:12 PM
Hi, I compiled and executed it, it shows:

Code: [Select]
Postmortem debugger        : "d:\PellesC\bin\poide.exe" -p %ld -e %ld
Postmortem debugger (WOW64): "d:\PellesC\bin\poide.exe" -p %ld -e %ld

EDIT:
I just remembered something I've noticed this morning:
If I hover the mouse over a function name (say, CreateFile) it shows CreateFileW,
but the code completion feature (Ctrl+Shift+Space) shows CreateFileA with the corresponding params
(see attachments). Commented #define UNICODE and did a clean build, but still the same. Is it normal behaviour?
Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 21, 2020, 07:24:41 PM
Hi, I compiled and executed it, it shows:

Code: [Select]
Postmortem debugger        : "d:\PellesC\bin\poide.exe" -p %ld -e %ld
Postmortem debugger (WOW64): "d:\PellesC\bin\poide.exe" -p %ld -e %ld
Assuming "d:\PellesC" is the installation + execution path, looks OK so far (=enabled). If you uncheck the "JIT" option, press OK, and then run this program again: is the output exactly the same?


Title: Re: Version 10.00 (RC3) is now available
Post by: algernon77 on July 21, 2020, 07:37:46 PM
I was just editing my previous post when you replied :)

The problem is that after I uncheck the option and click ok, if
I immediately open again the dialog box, the box is checked again  :-\

EDIT:
And yes, the output is the same
Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 21, 2020, 07:58:02 PM
I was just editing my previous post when you replied :)

The problem is that after I uncheck the option and click ok, if
I immediately open again the dialog box, the box is checked again  :-\

EDIT:
And yes, the output is the same
This is weird. I can't explain it. The logic behind this has stayed the same since *at least* 2010 (most recent change, cosmetic).
Title: Re: Version 10.00 (RC3) is now available
Post by: algernon77 on July 21, 2020, 08:44:44 PM
Hmm.. I have a vm with W10 Pro x64, I've just installed RC3 inside and it does the same thing.. once you click it, you have it :)
I've deleted the registry keys and now it shows unchecked, but if I check it again, it's the same. This vm is quite clean,
does not have anything installed.

I've uninstalled RC3, deleted reg keys and installed v9, same behaviour.

If there's more I can do, just say, I still have a couple of days off 'till my vacation expires :)
Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 22, 2020, 02:48:08 PM
OK, finally... if the machine is clean enough, the 'JIT' removal can fail. It will be fixed in the release version (next couple of days).
Title: Re: Version 10.00 (RC3) is now available
Post by: algernon77 on July 22, 2020, 03:56:19 PM
Thanks for all!
Title: Re: Version 10.00 (RC3) is now available
Post by: Pelle on July 22, 2020, 05:01:57 PM
Thanks for pointing out the bugs...  :P