Kai Tietz

Hello, I think it would be better to keep them for gcc at the place they are ... gcc is sadly a bit picky about the place for it ... as VC is too. But why not using macro specific for gcc, and another set for VC, which are placed at their most beloved places? Btw great that you try to port winpthread for VC :) Cheers, Kai Am Fr., 27. Nov. 2020 um 16:55 Uhr schrieb Long Nguyen kurumigaming@users.sourceforge.net: [bugs:#866] winpthreads: WINPTHREAD_API after type name causes errors in MSVC Status:...

Hello, fread actually returns a size_t. So maximal size of read per attempt is on 32-bit 2^32-1, and on 64-bit 2^64-1 bytes. If you want to process bigger data, I would recommend to operate here in junks. The maximal read bytes by the streaming API depends on the used open() variant for the file-descriptor. That is indeed a bit annoying. So we provide here an alternative for fopen(). You could try to replace fopen-call by fopen64()-call instead. See also there is the fsetpos64, fgetpos64, _fseeki64,...

Hello, Sorry for telling you, but your assumptions about passing va_list as argument, and how it behalfs is plain wrong. So your test-code is invalid. Why you assume that a local variable va is modified under the hood by a different function? As long as you don't pass reference to it, you are not able to modify its contents for an outer function. int foo(va_list argp) { return va_arg(argp, int); } void zoo(const char *fmt, ...) { va_list argp; argp=va_start(argp, fmt); fprintf(stderr, fmt, foo(argp),...

Hmm, sorry. I mixed your report up. There was another report with code sample, which claimed that va_list would be broken. Sorry about that. Nevertheless you should report this to gcc people too. As it is more a target-library issue in gcc AFAICS. Regards, Kai Am Mo., 28. Sept. 2020 um 15:27 Uhr schrieb Brecht Sanders brechtsanders@users.sourceforge.net: @ktietz70 I'm sorry, but I'm not following where you think this wrong assumtion was made. Is this in both gcc and pkg-config source code? Or are...

Hello, Sorry for telling you, but your assumptions about passing va_list as argument, and how it behalfs is plain wrong. So your test-code is invalid. Why you assume that a local variable va is modified under the hood by a different function? As long as you don't pass reference to it, you are not able to modify its contents for an outer function. int foo(va_list argp) { return va_arg(argp, int); } void zoo(const char *fmt, ...) { va_list argp; argp=va_start(argp, fmt); fprintf(stderr, fmt, foo(argp),...

Hello, I am pretty sure that our fread/fwrite routines work pretty well. The underlying issue here seems to be the missing use of "binary"-mode on the fopen-call. Not sure what Intel's runtime assumes as default mode on open for fopen, but MS' variant assumes text-mode, if no "b" is within the mode-option. Cheers, Kai Am So., 27. Sept. 2020 um 04:59 Uhr schrieb Sanmayce sanmayce@users.sourceforge.net: [bugs:#855] Possible fread() malfunction of GCC 7.3.0 Status: open Group: v1.0 (example) Created:...

That seems to me like a change to linker-script on binutils. The import/export tables are binutils related. Gcc doesn't produce them at all. As I suspected that nothing like LTO tries to be clever here, that issue should be solvable by the linker script, which should make sure that last element of table is NULL. Regards, Kai Am Do., 25. Juni 2020 um 10:52 Uhr schrieb jpa jpa-@users.sourceforge.net: Thanks to Martin Storsjö / wbs on IRC for some hints: problem is probably in binutils, related to bugs...

Hello, Well, I would not say that diagnostic is wrong here. As for wide-character routine '%s' still represents an array of characters, means here an array of wchar_t. For futher reading please see https://man7.org/linux/man-pages/man3/wprintf.3.html Regards, Kai Am Fr., 19. Juni 2020 um 10:48 Uhr schrieb David Macek elieux@users.sourceforge.net: [bugs:#846] wprintf, swprintf etc. don't check format specifiers vs. arguments on compile Status: open Group: v1.0 (example) Created: Fri Jun 19, 2020 08:48...