Recent Posts

1

General discussion / Re: Love Pelles C

« Last post by MrBcx on Today at 01:33:54 am »

Of all the compilers in my toolbox (Pelles C, MS Visual Studio, Embarcadero C++, Mingw, Clang, Open Watcom, and Lcc-Win32), Pelles absolutely gets the most usage. Pelle's resource editor, C compiler, and linker are rock solid and easy to use. 

Pelles C++ and Pelles C# will never happen, partly because there are many more free compiler alternatives than were available when Pelle's C was first released 18 years ago.  There are a few of us old timers on this forum who have been using Pelles' tools ever since then.  You won't be disappointed using Pelles C.

2

General discussion / Re: Love Pelles C

« Last post by TimoVJL on Today at 12:41:17 am »

C# translator/compiler csc.exe comes with Windows OS.

3

General discussion / Re: Love Pelles C

« Last post by CandCPlusPlus on Yesterday at 10:27:29 pm »

Giving it more thought, I'd actually prefer a Pelles C# over a Pelles C++. lol

I have a whole bunch of suggestions. I'm debating whether to start a separate thread for each feature request or suggestion or whether to put it all into one thread.

4

General discussion / Re: Love Pelles C

« Last post by frankie on Yesterday at 07:32:19 pm »

Hello, welcome 
Happy to hear that you too like this small masterpiece.
Unfortunately I guess that your dreams will remain such... 
Pelle is very focused on keeping his compiler strictly compliant with the 'C' standards, very efficient and well optimized.
The IDE evidently resembles the VS IDE, but is much more simple and easy to use.
Enjoy 

5

General discussion / Love Pelles C

« Last post by CandCPlusPlus on Yesterday at 05:38:52 pm »

I remember seeing a passing reference to Pelles C somewhere on the interwebs but I did not research more into it. I'm glad I finally did. I'm impressed with the IDE and compiler. It's very visual studio like but much more lightweight. I like certain aspects of the design more than Visual Studio Code and Visual Studio itself. I like how it just includes everything needed to compile C code and make Windows applications while also being lightweight. I am surprised by how little attention Pelles C gets.

I have a bunch feature suggestions and requests coming though. Be ready. lol

I will say that I'd love to see a separate Pelles C++ and Pelles C# as well. I only say that here instead of in the feature requests because it's unrealistic and it would likely be a huge undertaking for the author.  I can dream though.

6

Bug reports / Re: Misalignment of buffers allocated with malloc

« Last post by TimoVJL on July 18, 2022, 06:56:54 pm »

Win 7 OS system msvcrt.dll
32-bit

Code: [Select]

max_align_t alignment: 16
malloc: 00290E78
malloc: 00290E90
malloc: 00290EA8
malloc: 00290EC0
malloc: 00290ED8
malloc: 00290EF0
malloc: 00290F08
malloc: 00290F20
malloc: 00290F38
malloc: 00290F50
malloc: 00290F68
malloc: 00290F80
malloc: 00290F98
malloc: 00290FB0
malloc: 00290FC8
malloc: 00290FE0
malloc: 00290FF8
malloc: 00291010
malloc: 00291040
malloc: 0029105864-bit

Code: [Select]

max_align_t alignment: 16
malloc: 000000000033FC90
malloc: 000000000033FCB0
malloc: 000000000033FCD0
malloc: 000000000033FCF0
malloc: 000000000033FD10
malloc: 000000000033FD30
malloc: 000000000033FD50
malloc: 000000000033FD70
malloc: 000000000033FD90
malloc: 000000000033FDB0
malloc: 000000000033FDD0
malloc: 000000000033FDF0
malloc: 000000000033FE10
malloc: 000000000033FE30
malloc: 000000000033FE50
malloc: 000000000033FE70
malloc: 000000000033FE90
malloc: 0000000000466EC0
malloc: 0000000000466EE0
malloc: 0000000000466F00


7

Bug reports / Re: Misalignment of buffers allocated with malloc

« Last post by frankie on July 18, 2022, 10:08:20 am »

With reference to the "fundamental alignment" (as defined in C17, section 7.22.3, paragraph 1), I think it should be considered that 128bits and 256bits objects aren't actually defined, so the 8byte alignment is suitable for all types defined in the standard and should be the effective one (at least until larger types, 128-256bits, will be introduced).
At least this is my personal interpretation, maybe Pelle could add points...

If this is the intention, then max_align_t should have an alignment requirement of 8. (And none of the types required to have a fundamental alignment should have a greater alignment requirement.) What is improper is for max_align_t to have a greater alignment requirement than what the implementation considers fundamental.

I understand your point. You're right.
This behavior differs from MS that keeps 8bytes alignment. But MS stay to C standards like a fish to its bike.
I can't say if it is correct or not. In this case Pelle's comment would be appropriate.

8

Bug reports / Re: Misalignment of buffers allocated with malloc

« Last post by aaaaaa123456789 on July 18, 2022, 08:09:03 am »

So did you build a 32 bit or 64 bit exe?

As 64-bit. (That's why the output to the %p format specifier is 16 characters long.)

With reference to the "fundamental alignment" (as defined in C17, section 7.22.3, paragraph 1), I think it should be considered that 128bits and 256bits objects aren't actually defined, so the 8byte alignment is suitable for all types defined in the standard and should be the effective one (at least until larger types, 128-256bits, will be introduced).
At least this is my personal interpretation, maybe Pelle could add points...

If this is the intention, then max_align_t should have an alignment requirement of 8. (And none of the types required to have a fundamental alignment should have a greater alignment requirement.) What is improper is for max_align_t to have a greater alignment requirement than what the implementation considers fundamental.

The standard mentions above does include the words "less than OR equal to"  isn't that dispositive?

That quote is defining what a fundamental alignment is: any alignment that meets that requirement.
This is the full paragraph:

A fundamental alignment is a valid alignment less than or equal to _Alignof (max_align_t) . Fundamental alignments shall be supported by the implementation for objects of all storage durations. The alignment requirements of the following types shall be fundamental alignments:

• all atomic, qualified or unqualified basic types;
• all atomic, qualified or unqualified enumerated types;
• all atomic, qualified or unqualified pointer types;
• all array types whose element type has a fundamental alignment requirement;
• all types specified in clause 7 as complete object types;
• all structure or union types all of whose elements have types with fundamental alignment requirements and none of whose elements have an alignment specifier specifying an alignment that is not a fundamental alignment.

This interpretation (where max_align_t has the greatest alignment considered fundamental) is made clear in the definition of the type (section 7.19, paragraph 2), which says that max_align_t is "an object type whose alignment is the greatest fundamental alignment".


EDIT: note that, in frankie's example above, there is no bug, as the alignment for max_align_t is reported to be 8. Therefore, it's valid for malloc to return pointers aligned to 8 bytes. Likewise in the first example from John Z, where max_align_t has an alignment of 16 and malloc returns pointers aligned to 16 bytes. The second example from that post seems to exhibit the same bug as my test case on wine.

9

Add-ins / Re: Capture Tab data

« Last post by MrBcx on July 17, 2022, 07:36:00 pm »

Had examples attached but get some sort of upload folder full error.

John .. You might want to send Christian a private msg.

 

10

Add-ins / Re: Capture Tab data

« Last post by John Z on July 17, 2022, 01:15:56 pm »

A while back I wrote this Add-In to capture and save the debugger tabs data and put them into text files.
It works just as well on the normal IDE tabs as well but they also already have 'Select All'.
To me this is very useful to track change from code changes from debug session to debug session.

It works for every Debugger Tab except for the Memory.  However I have been struggling
unsuccessfully to improve the output from the Grouped listview tabs, for example 'Globals'.

As is the Add-In works well to capture and save the Grouped ListView tab(s) in whatever state
is being displayed.  So if Groups are un-expanded that is how the save output appears
and if the user expands the group(s) the saved output then shows the expanded data.
Examples attached.

I would like to be able to Expand all Groups programmatically. Everything I've tried has
failed to change the Group display, except I can hide it or show it not too useful in this case.
I've scoured the WEB and MS sites and tried unsuccessfully everything I could find or think of.
Even tried sending keystrokes .  So I'm doing it wrong, or it just can't be done in this
situation.  Maybe it is 'Owner Draw' and it can't be done, I don't know. 

Has anyone tried something similar?  Recognize that all I have access to is the Listview Handle.

John Z

Had examples attached but get some sort of upload folder full error.