mcpp Activity
Brought to you by:
kmatsui
Activity for mcpp
-
John Brandwood created ticket #18
Building with C2X fails on mcpp library
-
2.7.2: is not gcc 15.x ready
-
For anyone looking at this thread currently ... this was fixed back in 2019 by the Debian maintainers with 04-gniibe-fix-12.patch I have applied a slightly modified version of that patch here ... https://github.com/jbrandwood/mcpp/commit/1d56f3287b20bb3876be1a0cc132e06dada5256b
-
For anyone looking at this thread currently ... this was fixed back in 2019 by the Debian maintainers with 03-gniibe-fix-11.patch I have applied a slightly modified version of that patch here ... https://github.com/jbrandwood/mcpp/commit/f6f6e7363101e4fd948bea5626d6ba74efa45b73
-
For anyone looking at this thread currently ... this was fixed back in 2019 by the Debian maintainers with 05-gniibe-fix-13.patch I have applied a slightly modified version of that patch here ... https://github.com/jbrandwood/mcpp/commit/70a33a47bbd34af32c58b4bb10bd82392a7836b3
-
This actually turned out to be nothing to do with a heap-use-after-free when debugging! It is caused by get_repl() corrupting the invocation of the 9th or 32nd macro parameter when it is used at the end of the replacement text, because it sees the encoded 0x09 or 0x20 formal parameter index as a trailing space to delete. That corruption then goes on to cause the undefined behavior which results in a segfault. I've checked-in a fix for this here ... https://github.com/jbrandwood/mcpp/commit/f1e1c...
-
This actually turned out to be nothing to do with a heap-use-after-free when debugging! It is caused by get_repl() corrupting the invocation of the 9th or 32nd macro parameter when it is used at the end of the replacement text, because it sees the encoded 0x09 or 0x20 formal parameter index as a trailing space to delete. That corruption then goes on to cause the undefined behavior which results in a segfault. I've checked-in a fix for this here ... https://github.com/jbrandwood/mcpp/commit/60752...
-
If it helps you, I have updated my personal fork of mcpp to autoconf 2.71 and automake 1.16 here ... https://github.com/jbrandwood/mcpp/commit/16313ef80e902677a1786f16c03479b6c6961ef9
-
FWIW, I've imported the SourceForge mcpp repo into github, applied the patches from the Fedora package (except for the Japanese html one, which breaks the file because it isn't actually encoded in UTF-8). I've also started to apply other fixes, including a commit for this gcc 14.x build problem. https://github.com/jbrandwood/mcpp/commit/3b274fe8f31d61996343b17402f30408a6e447cf Best wishes, John
-
FWIW, I've imported the SourceForge mcpp repo into github, applied the patches from the Fedora package (except for the Japanese html one, which breaks the file because it isn't actually encoded in UTF-8). I've also started to apply other fixes, including a commit one for this gcc 14.x build problem. https://github.com/jbrandwood/mcpp/commit/3b274fe8f31d61996343b17402f30408a6e447cf Best wishes, John
-
Tomasz Kłoczko created ticket #16
2.7.2: is not gcc 14.x ready
-
eastdong posted a comment on ticket #15
sorry , the package name is mcpp ,not is mccp
-
Outdated config.guess file cannot recognize riscv64 platform
-
Florian Weimer created ticket #7
Implicit declaration of readlink due to _POSIX_*_SOURCE macro changes (C99 compatibility)
-
Camel Coder created ticket #14
heap-use-after-free in substitute() causes segfault
-
Eric Smith posted a comment on discussion Open Discussion
Just in case anyone else finds this via a search engine, the bug is a typo in the eval_signed function in mcpp_eval.c. The line: v1 = (--*valpp)->val ? v1 : v2; should read valp--; v1 = (valp->val) ? v1 : v2; because later in the code the value of valpp is updated from valp. The eval_unsigned function has this right already.
-
Frederic Cambus modified a comment on ticket #13
The first issue (L2514) got assigned CVE-2019-14274.
-
The first issue (L2514) got assigned CVE-2019-14274.
-
So, ASan calls both issues overflows, but only the first issue (L2514) is technically an actual buffer-overflow, the second issue (L2466) is actually an out-of-bounds read.
-
Multiple Heap-based Buffer Overflow in the do_msg() function
-
Heap-based Buffer Overflow in the parse_line() function
-
Attached the wrong file, here is the reproducer.
-
Heap-based Buffer Overflow in the get_line() function
-
Mohamed Fysal posted a comment on discussion Open Discussion
I am using mcpp to scan through the source files to find whichever defines available and then just enable those lines of code from source depending upon the defines. This is working fine using mcpp. But for some other purposes, I need few of the defines to be intact without changed by mcpp, because those defines I will be using for some other processes I do in the code. Is it possible in mcpp. Please advise me how to do ?
-
dcb created ticket #10
system.c:3686]: (error) Resource leak: fp
-
zunzunzun modified a comment on discussion Open Discussion
mcpp -Dunix x.c x.c is like following #ifdef unix xxxx #endif is not expanded to...
-
mcpp -Dunix x.c x.c is like following ifdef unix xxxx endif is not expanded to "xxxx"...
-
mcpp released /OldFiles/mcpp_2.6.4-1.dsc
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Khosrow Kazemi created ticket #9
bug in mcpp_main
-
King_DuckZ posted a comment on discussion Open Discussion
Hello, I've added a new option to the code -MS (s for "strict") to get the raw inclusion...
-
Jeremy Salwen posted a comment on discussion Open Discussion
When using mcpp as a library, it will throw a segmentation fault if you feed it an...
-
MikeY created ticket #8
mcpp skip some dependencies
1
