~peter0x44

Recent activity

Re: My favorite C compiler flags during development 3 months ago

From Peter0x44 to ~skeeto/public-inbox

On 2025-01-12 17:48, Christopher Wellons wrote:
> Several times now your -D_GLIBCXX_DEBUG suggestion has reminded me to 
> use it when testing or reviewing a conventional C++ program. Otherwise 
> I would have forgotten! I'm forming a habit of enabling it 
> automatically alongside sanitizers to cover the gaps.

Great! This feature of libstdc++ definitely goes underused.

On a related point, GCC 15 is enabling _GLIBCXX_ASSERTIONS by default 
for -O0 builds. That's good progress.
https://gcc.gnu.org/gcc-15/changes.html

Re: My review of the C standard library in practice 4 months ago

From Peter0x44 to ~skeeto/public-inbox

I figured you would be happy to know one of the issues you brought up in 
this post seems to be getting fixed in C2y.

https://developers.redhat.com/articles/2024/12/11/making-memcpynull-null-0-well-defined

Great news!

Re: My favorite C compiler flags during development 5 months ago

From Peter0x44 to ~skeeto/public-inbox

I know this article is titled "C compiler flags" but one of the most 
underused for C++ is `-D_GLIBCXX_DEBUG` which gives bounds checks on 
standard containers. Beginners are particularly prone to this and it 
helps a lot.

Maybe it deserves a mention here, it is really unfortunate how lacking 
education is here.

Regards,

Re: Cleaning up DOS/PE headers in w64devkit 10 months ago

From Peter0x44 to ~skeeto/public-inbox

3 Jun 2024 4:55:03 am Pali Zer <skype1234@waifu.club>:

> Hey Chris!
>
> Just thought I'd ask your opinion on the gunk that MSVC link.exe and
> ld.exe put in the executable headers of binaries. Personally, I really
> dislike them, especially the Rich headers that MSVC link.exe adds by
> default (fortunately, it's at least opt-out). I have noticed that 
> ld.exe
> also populates unused fields of the DOS header and still inserts the 
> DOS
> dummy program, even though that hasn't been relevant for over 2 decades 
> now.
>

[PATCH] lto: Don't assume a posix shell is usable on windows [PR110710] 1 year, 28 days ago

From Peter Damianov to ~sircmpwn/email-test-drive

lto-wrapper generates Makefiles that use the following:
touch -r file file.tmp && mv file.tmp file
to truncate files.
If there is no suitable "touch" or "mv" available, then this errors with
"The system cannot find the file specified".

The solution here is to check if sh -c true works, before trying to use it in
the Makefile. If it doesn't, then fall back to "copy /y nul file" instead.
The fallback doesn't work exactly the same (the modified time of the file gets
updated), but this doesn't seem to matter in practice.

I tested this both in environments both with and without sh present, and
observed no issues.
[message trimmed]