| Summary: | the nested function in c code renders busybox not compilable under clang | ||
|---|---|---|---|
| Product: | Busybox | Reporter: | Aleksander Balicki <balicki.aleksander> |
| Component: | Standard Compliance | Assignee: | Doug Gilmore <dgilmore> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | awg, busybox-cvs, carrotwei |
| Priority: | P5 | ||
| Version: | 1.19.x | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| URL: | http://llvm.org/bugs/show_bug.cgi?id=4296 | ||
| See Also: | http://llvm.org/bugs/show_bug.cgi?id=4296 | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: |
build.log
Prototype fix for the problem |
||
I tried to rework code to not use nested function, but it gets bigger. Do you have a patch? nope, sorry, i'm just a passive user. busybox is one of the dependencies of my packages on gentoo. i don't know what this code is supposed to do, only reporting the compilation error. Created attachment 4568 [details]
Prototype fix for the problem
Is it worthwhile cleaning up this patch and committing it?
Yes, it would be desirable to enable busybox to compile with clang and be more compatible with any standards compliant C compiler. I have also met the same problem. When will the proposed patch be in? (In reply to comment #3) > Created attachment 4568 [details] > Prototype fix for the problem > > Is it worthwhile cleaning up this patch and committing it? Sorry, but no. It looks bad. BTW. What is giving you the warning? The declaration (the "auto action* alloc_action(int sizeof_struct, action_fp f);" line) or the definition? Declaration line can be deleted. Then gcc will throw "func without a prototype" warning, but otherwise will compile it just fine. And finally. Maybe you can file a feature request with clang "please support this GCC-ism"? (In reply to comment #6) there is already a bug: http://llvm.org/bugs/show_bug.cgi?id=4296 but the general opinion is that they don't want to support nested functions. tweaking the decl won't help. considering there is a disadvantage to not using nested funcs here, i'm inclined to leave it as is until someone can propose a better solution. I am working on providing clang/llvm-3.2 based toolchain for ARM in next release of EmbToolkit.
To have a working busybox binary, this nested function will not be the only issue.
This[1] hack was also needed to overcome hacks assuming gcc is used as compiler.
This[1] hack basically replaces:
#define barrier() __asm__ __volatile__("":::"memory")
to
#define barrier() __sync_synchronize()
and moves *const {x_}ptr_to_{y} hacks from .data to .bss section
After that you will have a working binary but of course the code size grows
(compared to binary generated by gcc)
[1]
ftp://ftp.embtoolkit.org/embtoolkit.org/busybox/1.20.2/busybox-1.20.2-0005-Embtk-const-x_-ptr_to_-y-also-make-them-work-with-clang-ll.patch
Fixed in git: commit 6db5f679a21342249e6a6eb06ec70a337bf0d0b0 Author: Denys Vlasenko <vda.linux@googlemail.com> Date: Thu May 16 18:36:42 2013 +0200 find: get rid of nested function (it's a gcc-ism) |
Created attachment 3553 [details] build.log the nested function in: findutils/find.c:896 crashes under clang, because of the usage of a nested function: findutils/find.c:896:2: error: illegal storage class on function auto action* alloc_action(int sizeof_struct, action_fp f); ^ findutils/find.c:897:54: error: expected ';' at end of declaration action* alloc_action(int sizeof_struct, action_fp f)