kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I seem to remember the z specifier causing issues on some platforms but
that may have been in the 2.8 branch of wx but it's been a while so my
memory is not so clear on the issue.  If you choose use the z specifier
(which is the correct way to do this), it will need to be thoroughly
tested on all platforms.  Casting size_t to unsigned (although often
size_t is typedeffed from unsigned) is ugly but it will most likely be
the path of least resistance.

On 2/28/2017 5:17 AM, Sergey A. Borshch wrote:
> On 28.02.2017 10:33, Julius Schmidt wrote:
>> I know about %zu, but this is wx Printf, not C99 printf. Does it also
>> support
>> %zu?
> Yes, it does:
> http://docs.wxwidgets.org/3.1/classwx_string.html#a9588b7f2684b9a6a924dc3746a2b2f8d
> 
> --- quote: ----
> Note
> This function will use a safe version of vsprintf() (usually called
> vsnprintf()) whenever available to always allocate the buffer of correct
> size. Unfortunately, this function is not available on all platforms and
> the dangerous vsprintf() will be used then which may lead to buffer
> overflows.
> ---------------
> so it use C99 (vs(n))printf itself and must have %zu "from the box".
> 
>> Do we use it anywhere else?
> Is it a reason to do it wrong way here?
> 
>> On Tue, 28 Feb 2017, Sergey A. Borshch wrote:
>>
>>> On 28.02.2017 01:54, Julius Schmidt wrote:
>>>>  This patch fixes a format string assertion.
>>> ...
>>>>  -            txt.Printf( wxT( "%u" ), net->m_PadInNetList.size() );
>>>>  +            txt.Printf( wxT( "%u" ), (unsigned)
>>>>  net->m_PadInNetList.size() );
>>>
>>> std::vector::size() returns size_t type. Why should you typecast
>>> variable type
>>> instead of fixing format specifier to be consistent with actual
>>> variable type?
>>> There is %zu format specifier designed specially for size_t type
>>> since C99.
>>>
>