Re: Micro-optimizations to avoid some strlen calls.

Em qua., 21 de jul. de 2021 às 09:28, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
escreveu:

> Em qua., 21 de jul. de 2021 às 07:44, David Rowley <dgrowleyml(at)gmail(dot)com>
> escreveu:
>
>> On Tue, 20 Jul 2021 at 10:49, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
>> > There are some places, where strlen can have an overhead.
>> > This patch tries to fix this.
>>
>> I'm with Michael and David on this.
>>
>> I don't really feel like doing;
>>
>> - snprintf(buffer, sizeof(buffer), "E%s%s\n",
>> + buflen = snprintf(buffer, sizeof(buffer), "E%s%s\n",
>> _("could not fork new process for connection: "),
>>
>> is a good idea. I'm unsure if you're either not aware of the value
>> that snprintf() returns or just happen to think an overflow is
>> unlikely enough because you're convinced that 1000 chars are always
>> enough to fit this translatable string. I'd say if we were 100%
>> certain of that then it might as well become sprintf() instead.
>> However, I imagine you'll struggle to get people to side with you that
>> taking this overflow risk would be worthwhile given your lack of any
>> evidence that anything actually has become meaningfully faster as a
>> result of any of these changes.
>>
> I got your point.
> Really getting only the result of snprintf is a bad idea.
> In this case, the right way would be:
>
> snprintf(buffer, sizeof(buffer), "E%s%s\n",
> _("could not fork new process for connection: "),
> buflen = strlen(buffer);
>
> Thus doesn't have to recount buffer over, if rc fails.
> Thanks for the tip about snprintf, even though it's not the intention.
> This is what I call a bad interface.
>
Here the v1 version, with fix to snprintf trap.

regards,
Ranier Vilela