[OE-core] [PATCH 1/5] go-native: fix PATH issue when len(TMPDIR) == 410
Robert Yang
liezhi.yang at windriver.com
Fri Dec 1 01:40:50 UTC 2017
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
>
More information about the Openembedded-core
mailing list