Version 10.00 (RC3) is now available

[Pelle]

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:

• Fixed browse information manager (POBR) problem with unexpected EOF in preprocessor #define.
• Fixed IDE problem finding (programming) language-specific 'name' with 'Match whole word only' beyond scope of 'Current document'.
• Fixed compiler problem with certain strict alias violations, like *(long long *)&double_param.
• Fixed compiler problem accessing partial scalar variable through type-casting, like *((BYTE *)&long_integer).
• Fixed compiler problem with aggregate stack interference graph and pointer aliasing.
• Fixed compiler preprocessor problem with infinite loop on malformed input.
• Added truncation of very long source lines for /diag:caret output.
• Corrected some minor typos in the help file.

Hopefully the last release candidate...

/Pelle

[briman]

Thank You 

[Pelle]

Thank You 

You're welcome 

[John Z]

Great news Pelle - Thanks !

I hope everyone appreciates your hard work.

John Z

[MrBcx]

Thank you Pelle ...

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

[Pelle]

Thank you, John Z and MrBCX.

Hopefully nothing major pops up in the next week or two, and it can be "officially" released...

[John Z]

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

[frankie]

Seems a great job again 

[Pelle]

Thanks, frankie... 

[Pelle]

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

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 Expand

#pragma warn(disable:number)
...or by using the compiler option...

Code Select Expand

/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.

[John Z]

Pelle, thanks for the explanation. It makes sense.

You can always disable a specific warning through...

Code Select Expand

#pragma warn(disable:number)
...or by using the compiler option...

Code Select Expand

/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

[Pelle]

Yes, unions are good.

For loading values, functions like these should also work (most compilers will optimize properly):

Code Select Expand


/* 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 Expand

/* 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).

[John Z]

 
Thanks - got me started....


John Z

[Marco]

I know it's a little bit late, but thank you from me too!

[Pelle]

No problem Marco... thanks!