That is not an issue with modern compliers, like we use in CI:
regex_remap/regex_remap.cc: In function ‘TSRemapStatus TSRemapDoRemap(void*,
TSHttpTxn, TSRemapRequestInfo*)’:
regex_remap/regex_remap.cc:1114:18: error: format ‘%g’ expects argument of type
‘double’, but argument 2 has type ‘int’ [-Werror=format=]
TSError("%g", i);
^
-Bryan
> On Apr 20, 2018, at 9:59 AM, Walt Karas <[email protected]> wrote:
>
> For me the most important benefit is no undefined behavior / memory
> corruption, like the kind you'd get from:
>
> int i = 10;
> TSError("%g", i);
>
> On Fri, Apr 20, 2018 at 9:18 AM, Jason Kenny <[email protected]> wrote:
>> Is the concern bufferwritter or the use fo bufferwritter in TSDebug. I
>> agree the "extra" value is small for TSDebug. I feel the use of
>> bufferwritter is great within our code base.
>>
>> -Jason
>>
>> On Thu, Apr 19, 2018 at 5:42 PM, Bryan Call <[email protected]> wrote:
>>
>>> Replacing Debug()/TSDebug() with BufferWriter/bwformat has little
>>> benefit. Also, I don’t think adding another formatting interface for
>>> strings is something we want to maintain or use.
>>>
>>> The main downside, with snprintf(), I see reading the examples is having
>>> to keep track of the length and position in the buffer if you are calling
>>> snprintf() multiple times. This can be handled writing a simple wrapper
>>> around snprintf(), which I have done before in about 20 lines of code. If
>>> we want to expose a wrapper around snprintf(), I would be in favor of that.
>>>
>>> -Bryan
>>>
>>>> On Apr 19, 2018, at 11:20 AM, Alan Carroll
>>>> <[email protected]>
>>> wrote:
>>>>
>>>> I have several pull requests up currently involving updates to output
>>>> formatting for BufferWriter. I was asked to provide more detail on the
>>>> point of these pulls requests. Anyone who is interested can read this
>>>> document - https://solidwallofcode.github.io/buffer-writer.en.html for
>>> that
>>>> detail.
>>>
>>>
