Am Montag, 9. Dezember 2024 um 19:50:19 MEZ hat Johannes Khoshnazar-Thoma
Folgendes geschrieben:
> Hi:
>
> When compiling following C program:
>
> #include
>
> int main(int argc, char ** argv)
> {
> volatile unsigned long long a = 0;
> volatile unsigned long long b = a + (1ULL << 63);
gt; `_PVFV` typedef to a
> common header, and reuse it.
>
> 3 is my first suggestion. As with 1 it works in practice, and I believe it
> shouldn't cause warnings
> in reasonable future.
Note that it's also possible to patch gcc to ignore function casts
involving FARPROC
Am Montag, 5. August 2024 um 17:54:53 MESZ hat Pali Rohár
Folgendes geschrieben:
> On Monday 05 August 2024 23:04:21 LIU Hao wrote:
> > 在 2024-08-05 20:14, Antonin Décimo 写道:
> > > C99 in Annex J.5.7 Function pointer casts states:
> > > 1 A pointer to an object or to void may be cast to a point
Am Samstag, 23. Januar 2021, 16:46:18 MEZ hat Jeroen Ooms
Folgendes geschrieben:
> A user of the R programming language has reported that std::regex
> causes a hang for certain regular expressions when running in Japanese
> locale. I was able to reproduce this both with our production
> toolchai
Hello
I've just uploaded a new gdb build on: https://github.com/ssbssa/gdb/releases
The most interesting added feature is that it can read windows minidump files
(similar to how gdb handles core files on linux).
Any comments are welcome.
Regards
Domani Hannes
__
> 在 2018/5/3 9:03, 章成凯 写道:
> > Sorry for that.
> > I upload the attachment to google drive and post the link in the bug report:
> > https://sourceforge.net/p/mingw-w64/bugs/731/
I'm pretty sure that it's this bug I reported a while ago:
https://sourceware.org/bugzilla/show_bug.cgi?id=22854
I also
> (gdb) run
> Starting program: C:\_64\comp\mpfr_bug\ggdb\mpfr-4.0.0\tests\tfprintf.exe
> [New Thread 4680.0x160c]
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> repl-vsnprintf.c:358: GNU M
Am Samstag, 11. November 2017, 10:15:00 MEZ hat Liu Hao
Folgendes geschrieben:
> Debugging in assembly exposes indirection through a null pointer in
> `mingw-w64-crt/stdio/mingw_wvfscanf.c` around or after line 906:
>
> ```
> optimize_alloc ((flags & IS_ALLOC_USED) != 0, pstr, str_sz, (wstr -
>
lhmouse schrieb am 19:00 Montag, 6.Februar 2017:
> Compiling app.c with `-S -masm=intel` produces the following assembly
> code, with directives removed:
>
> _main:
> pushebp
> movebp, esp
> andesp, -16
> call___main
> moveax, DWORD
Hello
Does delay-loading work with 32bit executables?
In the following example it crashes for me on the dll_function() call.
I've used i686-6.3.0-release-win32-dwarf-rt_v5-rev1.7z for my tests.
app.c:
<<
__declspec(dllimport) void dll_function( vo
karol82 schrieb am 16:46 Freitag, 29.Juli 2016:
> I'm writing here because original gcc seems unaffected (asm code
> https://gcc.godbolt.org/ looks right).
> I don't want to post it to bugtracker, because my English skills are strongly
> limited and someone else can write better report, so if yo
In this example any of the (w)printf()'s now call strlen()/wcslen(), even
though the precision is limited to 1 character:
#define __USE_MINGW_ANSI_STDIO 1
#include
#include
int main( void )
{
char *nonTerminated = malloc (1);
wchar_t *nonTerminatedW = malloc (2);
nonTerminated[0] = 'a
Hello
Consider this source (which is partly from SETJMP_FLOAT128):
#include
typedef __attribute__ ((__aligned__ (16))) struct _TEST_FLOAT128 {
__extension__ unsigned long long Part[2];
} TEST_FLOAT128;
int main( void )
{
TEST_FLOAT128 tf;
printf( "alignof(tf) = %d\n",(int)__alignof__(tf
---
mingw-w64-crt/stdio/mingw_wvfscanf.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/mingw-w64-crt/stdio/mingw_wvfscanf.c
b/mingw-w64-crt/stdio/mingw_wvfscanf.c
index 41bdc68..045aba7 100644
--- a/mingw-w64-crt/stdio/mingw_wvfscanf.c
+++ b/mingw-w64-crt/stdio/mi
---
mingw-w64-crt/stdio/mingw_wvfscanf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-crt/stdio/mingw_wvfscanf.c
b/mingw-w64-crt/stdio/mingw_wvfscanf.c
index 3924b54..41bdc68 100644
--- a/mingw-w64-crt/stdio/mingw_wvfscanf.c
+++ b/mingw-w64-crt/stdio/mingw_wvf
Kai Tietz schrieb am 11:39 Donnerstag, 25.Februar
2016:
> thank you for the patch. Nice catch. Patch is ok for apply. JonY
> will you take care?
Great.
I made some tests now to figure out why the wide-variant doesn't have the same
problem:
swscanf( L"1", L"%*u-" );
In mingw_wvfscanf.c
Hello
The leak can be triggered with an example like this:
#define __USE_MINGW_ANSI_STDIO 1
#include
int main( void )
{
return( sscanf( "1", "%*u-" ) );
}
Regards
Domani Hannes
0001-scanf-fix-memory-leak.patch
Description: Binary data
-
Hello
Andrej Balkonski schrieb am 17:44 Montag, 3.August
2015:
> Hello everybody,
> I have a problem with linking-in binary data into a 32 bit Windows executable
> using mingw-w64.
> I'm doing this on Linux (Kubuntu 14.04.2 LTS) but the same thing also
> manifests itself on Windows machine(s)
Hello
Kai Tietz schrieb am 10:14 Donnerstag, 20.Februar
2014:
> I would advice you to look in more detail to license issues. MS
> compiler has them, and gcc & mingw(-w64) do so too. You will be
> wondering what other licenses you are using for just building a simple
> hello-world-application
lh_mouse schrieb am 15:06 Freitag, 17.Januar 2014:
> No std::exception_ptr invoked, still there seems to be memory leaks.
> Run make_test.cmd and you will get a.exe. Then run a.exe.
> I got the following results:
I've tried now your example and came to the same(?) result.
These were the leaks I d
Hello
lh_mouse schrieb am 18:38 Donnerstag, 16.Januar 2014:
> I got memory leaks in this code. Hope someone would help.
> Minimal sample code attached.
> Compiled with g++ test.cpp -std=c++11 -static, then attached with OllyDbg, bp
> malloc, calloc, realloc, free. There > were 2 or 3 blocks of
> In short words, on mingw-gcc 4.9.0 the following code produces a text
file with contents "a\r\nb\r\n", while
> replacing open() + fdopen() with a single fopen() produces "a\nb\n". Any
> ideas?
You have to add O_BINARY to open().
Regards
Domani Hannes
--
Hello
This patch allows overloaded functions in c++, like:
void dothis( pthread_mutex_t *mutex );
void dothis( pthread_cond_t *cond );
I don't know if this should be even possible, but I've seen it in code.
Regards
Domani Hannes
object-types.patch
Description: Binary data
Hello,
> > As it is now, if I link binmode.o to the application, it does nothing. (or
> > is this intended?)
> > With this, I get the expected behavior (all opened files are by default
> > opened in binary mode).
> The binary-mode is default behavior for mingw-w64. So of course there
> is no d
Hello
As it is now, if I link binmode.o to the application, it does nothing. (or is
this intended?)
With this, I get the expected behavior (all opened files are by default opened
in binary mode).
I've mirrored the behavior from txtmode.c in this patch.
Regards
Domani Hannes
binmode.patch
Desc
Hello
Both IID_IPersistFolder and IID_IPersistFolder3 are already there.
Regards
Domani Hannes
IID_IPersistFolder2.patch
Description: Binary data
--
How ServiceNow helps IT people transform IT departments:
1. A cloud s
26 matches
Mail list logo
