Bug 6398

Summary:	CONFIG_USE_PORTABLE_CODE switch is backwards (and useless)
Product:	Busybox	Reporter:	bugdal
Component:	Other	Assignee:	unassigned
Status:	RESOLVED INVALID
Severity:	minor	CC:	busybox-cvs
Priority:	P5
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Host:		Target:
Build:

Description bugdal 2013-07-20 04:00:53 UTC

The only place this setting is used is in findutils/find.c:

#if ENABLE_USE_PORTABLE_CODE
	char **argv = alloca(sizeof(char*) * (ap->exec_argc + 1));
#else /* gcc 4.3.1 generates smaller code: */
	char *argv[ap->exec_argc + 1];
#endif

The code under ENABLE_USE_PORTABLE_CODE is using a non-portable GCC feature, alloca. The code in the #else block is using portable code (VLA).

With that said, having this option makes no sense at all if this is the only place it's used. I'm pretty sure busybox makes plenty use of alloca elsewhere already, so why not just pick whichever case generates better code and remove this useless (and very confusing) option?

Comment 1 Denys Vlasenko 2013-07-22 02:29:57 UTC

(In reply to comment #0)
> The only place this setting is used is in findutils/find.c:
> 
> #if ENABLE_USE_PORTABLE_CODE
>     char **argv = alloca(sizeof(char*) * (ap->exec_argc + 1));
> #else /* gcc 4.3.1 generates smaller code: */
>     char *argv[ap->exec_argc + 1];
> #endif
> 
> The code under ENABLE_USE_PORTABLE_CODE is using a non-portable GCC feature,
> alloca. The code in the #else block is using portable code (VLA).

alloca is supported by any C compiler, whereas variable-length arrays are not.

> With that said, having this option makes no sense at all if this is the only
> place it's used. I'm pretty sure busybox makes plenty use of alloca elsewhere
> already, so why not just pick whichever case generates better code and remove
> this useless (and very confusing) option?

This code was requested by people who use C compiler which doesn't support variable length arrays.