Re: Micro-optimizations to avoid some strlen calls.

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.

regards,
Ranier Vilela

>
>