Musl git 0d......455eee8 and recent compilers

Musl git 0d......455eee8 and recent compilers

[Igmar Palsenberg]

Hi,

I was using Musle as a test for investigating a (completely unrelated) clang-analyser problem, and I've stumbled upon a couple of issues

1) The struct dirent in include/dirent.h uses a 1 byte array for d_name. In reality, it's larger : We allocate more space than the struct. Since muscle requires a C99 compiler anyway, what's keeping use from using d_name[0] or d_name[] ? If a C89 compiler includes dirent.h, we're screwed anyway :). That will probably silence GCC 4.5 and clang, and severely reduce the warnings it gives in similar cases.

2) The NULL pointer dereference in src/time/__asctime.c won't work with clang : It removes it. I suggest using either __builtin_trap() or an abort(). If you get to that point, you're in trouble anyway.

3) Clang does't seem to grasp the weak_alias thingy. It need to check if those parts actually are correct

4) Is there a muscl testsuite somewhere ?


regards,



	Igmar

Re: Musl git 0d......455eee8 and recent compilers

[Szabolcs Nagy]

* Igmar Palsenberg <musl@palsenberg.com> [2011-06-06 10:48:08 +0200]:
> I was using Musle as a test for..

musl


> 1) The struct dirent in include/dirent.h uses a 1 byte array for d_name. In reality, it's larger : We allocate more space than the struct. Since muscle requires a C99 compiler anyway, what's keeping use from using d_name[0] or d_name[] ? If a C89 compiler includes dirent.h, we're screwed anyway :). That will probably silence GCC 4.5 and clang, and severely reduce the warnings it gives in similar cases.
> 

what kind of warnings do you get?
char foo[1] gives warning but a flexible array member char foo[] does not?

> 2) The NULL pointer dereference in src/time/__asctime.c won't work with clang : It removes it. I suggest using either __builtin_trap() or an abort(). If you get to that point, you're in trouble anyway.
> 

i guess __builtin_trap is compiler specific
i don't think it's a big deal..
there could be 0/0 as well i guess
i wonder what
 main(){ return *(int*)0; }
or even
 main(){ return ((int(*)())0)(); }
does on clang..

> 3) Clang does't seem to grasp the weak_alias thingy. It need to check if those parts actually are correct
> 

well it uses the alias __attribute__ extension of gcc

> 4) Is there a muscl testsuite somewhere ?
> 

musl

http://git.etalabs.net/cgi-bin/gitweb.cgi

Re: Musl git 0d......455eee8 and recent compilers

[Igmar Palsenberg]

> * Igmar Palsenberg <musl@palsenberg.com> [2011-06-06 10:48:08 +0200]:
>> I was using Musle as a test for..
> 
> musl

Sorry.... It's also the name of a cleaning substance here, so I usually het the name wrong :)
 
> 
>> 1) The struct dirent in include/dirent.h uses a 1 byte array for d_name. In reality, it's larger : We allocate more space than the struct. Since muscle requires a C99 compiler anyway, what's keeping use from using d_name[0] or d_name[] ? If a C89 compiler includes dirent.h, we're screwed anyway :). That will probably silence GCC 4.5 and clang, and severely reduce the warnings it gives in similar cases.
>> 
> 
> what kind of warnings do you get?

Array out of bounds :

src/misc/nftw.c:77:11: warning: array index of '1' indexes past the end of an array (that contains 1 elements) [-Warray-bounds]
                                 && (!de->d_name[1]

The compiler is strictly speaking right in this case.

> char foo[1] gives warning but a flexible array member char foo[] does not?

Correct. 

>> 2) The NULL pointer dereference in src/time/__asctime.c won't work with clang : It removes it. I suggest using either __builtin_trap() or an abort(). If you get to that point, you're in trouble anyway.
>> 
> 
> i guess __builtin_trap is compiler specific
> i don't think it's a big deal..
> there could be 0/0 as well i guess
> i wonder what
> main(){ return *(int*)0; }
> or even
> main(){ return ((int(*)())0)(); }
> does on clang..

Hmm.. Despite the warning :

int main(int argc, char **argv)                                                 
{                                                                               
    *(int*)0 = 0;                                                               
    printf("XXX\n");                                                            
    return 0;                                                                   
}

segfaults. Clang is allowed to remove the dereference, we might to use abort() in this case. With O3, it gives an illegal instruction (probably an ud2). I either misread the warning, or clang doesn't do what it says :).

> 
>> 3) Clang does't seem to grasp the weak_alias thingy. It need to check if those parts actually are correct
>> 
> 
> well it uses the alias __attribute__ extension of gcc

I need to check if the offending function / alias is there, or as clang says, isn't emitted.

>> 4) Is there a muscl testsuite somewhere ?
>> 
> 
> musl
> 
> http://git.etalabs.net/cgi-bin/gitweb.cgi

I'll try that.


Regards,


	Igmar

Re: Musl git 0d......455eee8 and recent compilers

[Rich Felker]

On Mon, Jun 06, 2011 at 10:48:08AM +0200, Igmar Palsenberg wrote:
> Hi,

Hi! Thanks for the reports.

> I was using Musle as a test for investigating a (completely
> unrelated) clang-analyser problem, and I've stumbled upon a couple
> of issues
> 
> 1) The struct dirent in include/dirent.h uses a 1 byte array for
> d_name. In reality, it's larger : We allocate more space than the
> struct. Since muscle requires a C99 compiler anyway, what's keeping
> use from using d_name[0] or d_name[] ? If a C89 compiler includes
> dirent.h, we're screwed anyway :). That will probably silence GCC
> 4.5 and clang, and severely reduce the warnings it gives in similar
> cases.

While musl requires a C99 compiler, my intent was to minimize breakage
when building programs against it using a lesser compiler. This could
probably just be changed though. I think the time of caring about
compilers that don't support [] is past..

> 2) The NULL pointer dereference in src/time/__asctime.c won't work
> with clang : It removes it. I suggest using either __builtin_trap()
> or an abort(). If you get to that point, you're in trouble anyway.

The best fix is adding volatile. __builtin_trap is compiler-specific
and calling abort will pull on bloat for no reason. (Note that raise
is actually a rather heavy function due to Linux not directly
supporting the correct POSIX semantics with regard to threads, and
having to hack it to be async-signal-safe from userspace...)

> 3) Clang does't seem to grasp the weak_alias thingy. It need to
> check if those parts actually are correct

Does it really not support making non-static aliases for static
functions? If so that's a major pain that will bloat the symbol table.
You can't just remove static though; the functions from which static
is removed will have to be renamed so as not to use reserved external
names.

> 4) Is there a muscl testsuite somewhere ?

A partial one:

git://git.etalabs.net/libc-testsuite

That's mostly quick examples I wrote just to make sure things were
basically working while writing musl; it's not exhaustive. Luka is
working on a much more extensive set of tests as a GSoC project.

Rich