[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