[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120908194646.GC32384@port70.net>
Date: Sat, 8 Sep 2012 21:46:46 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: documenting musl
* Isaac Dunham <idunham@...abit.com> [2012-09-07 23:36:58 -0700]:
> The unofficial musl manual
>
> Feature test macros, standards:
> Musl supports the following standards, with the given feature test macros or parameters:
> X/Open 2008 (SUS4) _XOPEN_SOURCE >= 700
> POSIX 2008 _POSIX_C_SOURCE >= 200809L, _POSIX_SOURCE
> ISO C99 (requires -std=c99 or equivalent; detected using __STRICT_ANSI__, which gcc sets automatically)
>
i might not use the proper terminology here
but the following needs to be made clear:
there is two kinds of "musl supports..":
- the environment in which musl can be built (see INSTALL document)
- the environment musl provides (this is what we document here)
the environment musl provides includes:
- run-time and abi support (eg. binaries built against glibc may work..)
- compile-time environment (with appropriate compiler flags)
> The following standards are partly supported:
> ISO C11 (WIP, threads and atomics aren't supported yet, and
> Annex K is unlikely to be supported in the foreseeable
> future; use -std=c11 or equivalent)
> ANSI C89/ISO C90 A few details are incompatible with C99, and the
> namespace respected is the C99 one. However, there
> shouldn't be breakage.
(+ISO C94/AMD1)
c89 compatibility may worth some investigation
(i'd guess that only math.h breaks c89 compatibility seriously with
union compound literals and probably that could be worked around,
the c99 namespace and library changes and long long for int64
types are minor incompatibilities
for c89 code __STRICT_ANSI__ and __STDC_VERSION__<199901L is nedded
(same is true for c94 conformance which is c89 + the wchar_t mess)
actually even the c99 support is only true with appropriate
compiler extensions, eg. NAN cannot be properly defined using
c99 constructs, you need __builtin_nanf("") but in these
cases musl provides reasonable fallbacks)
> Older POSIX and SUS _POSIX_C_SOURCE < 200809L, _XOPEN_SOURCE < 700
> Exposes legacy extensions as well as the modern
> standard, rather than only the legacy standard.
>
> The following feature test macros are also supported to the extent practical:
> _GNU_SOURCE Partial glibc compatability.
> Nonstandard functions with the same names as standard
> ones (basename and several others) ARE NOT SUPPORTED:
> musl uses the ISO/POSIX/SUS definition unconditionally.
> _LARGEFILE64_SOURCE nop: musl only provides 64bit file io, so this just adds
> *64 aliases to the namespace
it's not a nop then
> _BSD_SOURCE While glibc is still stuck at BSD 4.4, musl provides
> much of the functionality available via _NETBSD_SOURCE
> on NetBSD. This includes strlcpy, strlcat, and fgetln.
>
> By default (-std=gnu* or no arguments for GCC), musl currently sets
> _XOPEN_SOURCE to 700 and defines _BSD_SOURCE.
> With musl 0.9.4 or older, musl defaulted to ANSI C99.
>
i wouldn't write this in gcc specific ways
"if the above feature test macros are not defined musl sets.."
> Detecting musl:
> This is frequently asked about. It is not possible to detect musl for sure.
> Key differences:
> __linux and __ELF will both be defined, unlike with dietlibc.
> unistd.h defines _XOPEN_VERSION to 700 and _POSIX_VERSION to 200809L.
> (This is what you should be checking for, unless you need nonstandard functions)
> features.h defaults to defining _BSD_SOURCE and _XOPEN_SOURCE, rather than _BSD_SOURCE and _SVID_SOURCE; __USE_* macros are not present, nor are the __GLIBC* macros.
> Using GNU basename syntax ( basename("/usr"); ) will make for segfaults.
>
i guess documenting all the implementation defined
behaviour, quality of implementation guarantees
and locale things will be the hard part
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
