Re: [PATCH v5] Practical Improvement to libgcc Complex Divide

[Jakub Jelinek <jakub@redhat.com>]

On Thu, Dec 10, 2020 at 10:27:46AM -0600, Patrick McGehearty via Gcc-patches wrote:
> Thank you for your rapid feedback.
> I'll fix the various formatting issues (spaces in the wrong places
> and such as well as revise the Changelog magic) in the next submission.
> It will wait for Joseph's review to also make any changes he suggests.
> I'll also try to train myself to be more sensitive to gcc formatting
> conventions while proofreading.
> 
> I'm reluctant to change or use XALLOCAVEC instead of alloca as that
> is not the current style elsewhere in the routine.

If so, I can fix it incrementally.  But, at least fix up the formatting,
that was the reason I've mentioned XALLOCAVEC, because the alloca call
formatting was off.

> On the strcpy, strncpy, and memcpy question, given short length of
> the string being copied, I don't think it makes much difference.
> The two other copy operations in the file are memcpy.
> memcpy might be slightly better since it is generally more frequently
> seen and more likely that gcc has special case code to inline
> short fixed length memcpy as a few assignments. Even if both strncpy
> and memcpy are inlined, the memcpy code may be simplier as it does
> not need to be concerned with special treatment of nulls.
> I'll change the strncpy to memcpy.

Even if short, strncpy is a badly designed API that in 99% cases just
shouldn't be used.  Either the string is shorter than the passed argument,
then in most cases completely useless zeroes the rest of the buffer
(exception is security sensitive code that needs to overwrite everything
that has been before), or it is the same length and then one should use
strcpy instead, or there is string truncation which doesn't zero terminate,
which is very rarely something one wants to do.

	Jakub