What is the blocker for the libs to move to gitlab.
I was under the impression that the librarians where the people most keen
on moving to gitlab.
On Wed, 27 Nov 2019 at 21:39, Seth Hillbrand wrote:
> On 11/27/19 11:42 AM, Rene Pöschl wrote:
>
> On 26/11/2019 21:54, Seth Hillbrand wrote:
>
> On
Hi Folks-
It looks like a recent commit broke the QA tests for Arc bbox checks.
../../qa/common/geometry/test_shape_arc.cpp(91): error: in
"ShapeArc/BasicCPAGeom": check KI_TEST::IsBoxWithinTol(
aArc.BBox(), aProps.m_bbox, pos_tol ) has failed for ( BOX[ [ 273 | 100
] + [ 27 | 100 ] ], BOX[ [
I'm guessing because mingw is providing a special implementation for printf
(and related functions) that supports %zu instead of linking to the old C89
one, but the GCC attribute checker is not aware of that.
On Fri, Jan 3, 2020 at 12:43 PM jp charras wrote:
> After some tests:
>
> printf("test
After some tests:
printf("test %zu", size_t(1) );
works, and there is no compil warning.
Functions that generate a warning about %zu format are:
StrPrintf()
OUTPUTFORMATTER::Print()
(see richio.h)
they have the attribute:
__attribute__ ((format (printf, 2, 3)))
or
__attribute__ ((format
Le 03/01/2020 à 16:02, Ian McInerney a écrit :
> JP, is that mingw32 directly, or was it provided by mingw-w64
> indirectly? It appears that mingw32 (the original compiler version)
> doesn't have the compatibility enabled but the forked version mingw-w64
> does. (there was discussion about this on
wxWidgets has a interesting maze of macros to determine how to do
printf on Windows. I wonder what it ends up doing. There is a special
case just for MINGW32 but not MINGW64.
https://github.com/wxWidgets/wxWidgets/blob/cc931612eec2e3ea49200ebff45042135f3c3f9c/include/wx/wxcrtvararg.h#L84
On
Le 03/01/2020 à 15:58, Jon Evans a écrit :
> So maybe it's a 32-bits vs 64-bits thing.
> If you add a line like
> #define __USE_MINGW_ANSI_STDIO 1
> at the top of that source file, does it work?
No.
I still have the compil message:
warning: unknown conversion type character 'z' in format
JP, is that mingw32 directly, or was it provided by mingw-w64 indirectly?
It appears that mingw32 (the original compiler version) doesn't have the
compatibility enabled but the forked version mingw-w64 does. (there was
discussion about this on the mingw users mailing list:
So maybe it's a 32-bits vs 64-bits thing.
If you add a line like
#define __USE_MINGW_ANSI_STDIO 1
at the top of that source file, does it work?
On Fri, Jan 3, 2020 at 9:32 AM jp charras wrote:
> Le 03/01/2020 à 15:10, Jon Evans a écrit :
> > I found it defined in
> >
I found it defined in
C:\msys64\mingw64\include\c++\8.3.0\x86_64-w64-mingw32\bits\os_defines.h on
my machine.
@JP -- what platform did you use (Windows version / MSYS version / etc)
where you saw the issue?
On Fri, Jan 3, 2020 at 9:02 AM Seth Hillbrand wrote:
> On 2020-01-02 17:19, Jon Evans
Le 03/01/2020 à 15:10, Jon Evans a écrit :
> I found it defined in
> C:\msys64\mingw64\include\c++\8.3.0\x86_64-w64-mingw32\bits\os_defines.h
> on my machine.
> @JP -- what platform did you use (Windows version / MSYS version / etc)
> where you saw the issue?
I confirm the %zu is not working on
My text:
---
license: CC BY-SA 4.0
Copyright (add name when editing/extending):
Tjeerd J. Pinkert, 2020
contact: alumnus.utwente.nl>
---
Dear Quabache, Eeli, list
It took me a while to answer, reading below might explain why.
Ouabache Designworks wrote:
-
> Kicad implemented
On 2020-01-02 17:19, Jon Evans wrote:
Hi all,
Context:
https://gitlab.com/kicad/code/kicad/merge_requests/28#note_264910682
I have heard there are issues using "%zu" format specifier on
Windows/mingw, because mingw links against a very old Windows library
that does not support the C99
Is __USE_MINGW_ANSI_STDIO actually defined in the wxWidgets builds we use?
A quick search through their codebase for that symbol only shows them
testing for it and never actually defining it.
-Ian
On Fri, Jan 3, 2020 at 1:20 AM Jon Evans wrote:
> Hi all,
>
> Context:
>
14 matches
Mail list logo
