Pelles C forum

See https://www.pellesc.se/, Download (and Changes).

Changes from Release Candidate #1:

• Stopped using instruction MOVBE for load/store with byte-swap in the X64 code generator. Ditto for the X86 code generator.
• Fixed infinite recursion in POASM, from a construct like: MessageBoxA TEXTEQU <MessageBoxA>.
• Stopped auto-installing buildver.dll in Bin\AddIns64 directory.
• Minor revision to default manifest for IDE resource editor.
• Minor documentation fix.

Thanks Pelle!

Testing round 2  :)

John Z

Thanks. Maybe not too many more rounds this time? We'll see...

Thanks,
that i can still use my an old PC full of an old C-code for testing new version.

All looking good on my various programs, and other test files.

The only different thing I see is with a single C file that was 'OK' under V13 but is reported as having illegal character(s) under V14.  I could not find any bad character(s) and other text editors did not show or complain either.  Finally I just used TextPad to re-save the file as UTF-8, with BOM, then it was acceptable to V14, nothing looked different...

Perhaps a future enhancement could report the byte position of the 1st offending character so it would be easier to locate and correct.

All good.

John Z

Quote from: TimoVJL on March 30, 2026, 11:14:14 AMThanks,
that i can still use my an old PC full of an old C-code for testing new version.

Thanks. No problem.  8)

Quote from: John Z on March 30, 2026, 12:46:25 PMThe only different thing I see is with a single C file that was 'OK' under V13 but is reported as having illegal character(s) under V14.  I could not find any bad character(s) and other text editors did not show or complain either.  Finally I just used TextPad to re-save the file as UTF-8, with BOM, then it was acceptable to V14, nothing looked different...

1) Can I somehow look at the "broken" file ?
2) What is your setting for "Options" -> "Source editor" -> "Default encoding, source files" ?

Quote from: John Z on March 30, 2026, 12:46:25 PMPerhaps a future enhancement could report the byte position of the 1st offending character so it would be easier to locate and correct.

Properly formed text files should always load. Malformed text files should be uncommon enough that my time is better spent on more important tasks.

Quote from: Pelle on March 30, 2026, 01:36:57 PM2) What is your setting for "Options" -> "Source editor" -> "Default encoding, source files" ?

Turns out to be more than just the one file.  I checked the Option you mentioned above it was set to UTF-8.  Most files in the program were ANSI, including file.c, a few newer additions were UTF-8.  I toggled the default to ANSI and the file(s) loaded into the editor just fine so did all the others I had just found were also indicating error.

I then just toggled the setting back to UTF-8 and everything was still working, even though I did not re-save any file.  But they are all marked UTF-8 (No BOM) now in the editor.

Checked an archived version and it was repeatable.  Easy fix toggle the Option.  Going to check a few older files (ANSI) for this issue.

John Z

Hi Pelle,

Release Candidate #2 for version 14.00 work on Windows 7 Sp1 64-bit, many thanks.

Quote from: John Z on March 30, 2026, 02:36:03 PMTurns out to be more than just the one file.  I checked the Option you mentioned above it was set to UTF-8.  Most files in the program were ANSI, including file.c, a few newer additions were UTF-8.

Sounds like what I stumbled on yesterday, by dumb luck. When debugging a totally unrelated case, the debugger complained about "invalid characters" when trying to load a source file (using the same load function as the source editor). On my machine it boiled down to double quotes (code 34 vs 147).

The revised sequence when loading is now:
1) If the text file begins with a BOM for UTF32LE, UTF32BE, UTF8, UTF16LE, UTF16BE: pass it on as encoded this way (for later processing or "sorry, bad format").
2) If the text file is longer than 32 bytes (for technical reasons), scan the whole file (memory mapped) and check for UTF-8 special encoding. If not invalid, and at least one 'extended' character: pass it on as UTF-8 encoded (no BOM).
3) If "Options" -> "Source editor" -> "Default encoding, source files" is set to UTF-8, scan the whole file (memory mapped) and check for 7-bit ASCII encoding. If not invalid (code above 127, or unwanted control char): pass it on as UTF-8 encoded (no BOM).
4) Pass it on as ANSI encoded (whatever that means, in different parts of the world).

This works on my machine. I really hope this is it, because it's getting complicated...

I don't want to upload yet another Release Candidate just for this. If there is no major breaking bug this will hopefully be in the final version (otherwise Release Candidate 3).

Quote from: Vortex on March 30, 2026, 11:25:39 PMRelease Candidate #2 for version 14.00 work on Windows 7 Sp1 64-bit, many thanks.

Thanks for the info! Good to know...

Some C-code needs _MSC_VER 1500 just for using intrin.h
A new define won't help.
One test was 7Zip code

Quote from: Pelle on March 31, 2026, 10:06:30 AMSounds like what I stumbled on yesterday, by dumb luck.

Thanks Pelle - sorry you had the same dumb luck as I did, but happy that it was not just something unreasonable( or another word beginning with s ending with d) that I did :)

John Z

Quote from: TimoVJL on March 31, 2026, 11:02:19 AMSome C-code needs _MSC_VER 1500 just for using intrin.h
A new define won't help.
One test was 7Zip code

Neither <intrin.h> nor files included by <intrin.h> contains any reference to _MSC_VER.
Do you have an example? As a personal policy, I always stay away from 7Zip...

Just forget this thing.

https://github.com/lvsti/p7zip/blob/master/C/CpuArch.c (https://github.com/lvsti/p7zip/blob/master/C/CpuArch.c)
CpuArch.c line 14
#if !defined(USE_ASM) && _MSC_VER >= 1500
#include <intrin.h>
#endif

Perhaps a that file set have problem, have to check those more, why intrin.h is missing from right headers.

EDIT: A those 7Zip headers are just a total mess.

Quote from: TimoVJL on March 31, 2026, 03:57:36 PMEDIT: A those 7Zip headers are just a total mess.

Hence my personal policy...  ;D

I tested PellesC 14 RC2 using:

• https://github.com/xecronix/JJsRoadRage
• https://github.com/xecronix/crude
• https://github.com/xecronix/MightyEagleC

and a few Windows GDI "projects" I have in my dev folder.  All worked perfectly. 

I have tested PellesC 14 RC2 with WinContig, as well as with other projects that are currently under development. They all compile correctly and run without any issues.

I really appreciate the new warnings that have been introduced (or perhaps this new version is better at identifying potential errors during compilation).

Same here, only some a define hell make testing hard.

Quote from: Marco on April 01, 2026, 12:06:04 PMI have tested PellesC 14 RC2 with WinContig, as well as with other projects that are currently under development. They all compile correctly and run without any issues.

Thanks, good to know!

Quote from: Marco on April 01, 2026, 12:06:04 PMI really appreciate the new warnings that have been introduced (or perhaps this new version is better at identifying potential errors during compilation).

I sometimes add new warnings. It could also be that the analyzer gets better at predicting things like "value ranges", now triggering a warning that was previously skipped because of "unknown" range.