Hi Alexander,
On 11/30/2017 07:33 PM, Alexander Kanavin wrote:
On 11/30/2017 03:45 AM, Robert Yang wrote:
+- char buf[4096];
++ char buf[8192];
I understand it would take more time, but the proper way to fix this (and
similar issues in patches 2, 3, 5) is to use dynamic allocation. Swapping one
arbitrary value for another arbitrary value may still not be enough for everyone.
There are two reasons that it isn't worth to use dynamic allocation (e.g.,
malloc):
1) The path length has a limit defined in /usr/include/linux/limits.h,
usually it is 4096, but a lot of tools would be failed (include python IIRC)
when len(tmpdir) > 410 (then len(path) is about 500 since it is in workdir)
in our testing, so make it work when len(tmp) == 410 should be enough for
everyone in the real world, otherwise, other errors will happen.
2) Look at the context of go/src/cmd/dist/unix.c:
char*
bprintf(Buf *b, char *fmt, ...)
{
va_list arg;
char buf[4096];
breset(b);
va_start(arg, fmt);
vsnprintf(buf, sizeof buf, fmt, arg);
[snip]
There is no easy way to know how much memory is needed, we need some ways look
tricky which makes the code complex: (fake code)
if (length = vsnprintf(NULL, 0, fmt, arg)) >= 0) {
char *buf = (char*) malloc(length + 1);
if (buf){
va_start(arg, fmt);
vsnprintf(buf, length + 1, fmt, arg);
[snip]
free(buf)
}
}
So I don't think that it is worth to use malloc here, the similar to 2 3 5.
And we had used a few similar ways to fix this kinds of issues before.
// Robert
Alex
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
