mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: Musl git 0d......455eee8 and recent compilers
Date: Mon, 6 Jun 2011 12:47:51 -0400	[thread overview]
Message-ID: <20110606164751.GC191@brightrain.aerifal.cx> (raw)
In-Reply-To: <EE6BD40A-A13D-4A86-843D-A7EA35801573@palsenberg.com>

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


      parent reply	other threads:[~2011-06-06 16:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-06  8:48 Igmar Palsenberg
2011-06-06 10:27 ` Szabolcs Nagy
2011-06-06 10:47   ` Igmar Palsenberg
2011-06-06 16:47 ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110606164751.GC191@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).