* sign (in)consistency between architectures
@ 2013-05-01 17:05 Z. Gilboa
2013-05-01 18:00 ` Szabolcs Nagy
0 siblings, 1 reply; 10+ messages in thread
From: Z. Gilboa @ 2013-05-01 17:05 UTC (permalink / raw)
To: musl
[-- Attachment #1.1: Type: text/plain, Size: 1343 bytes --]
Greetings,
The current architecture-specific type definitions
(arch/*/bits/alltypes.h) seem to entail the following inconsistent
signed/unsigned types:
type x86_64 i386
-------------------------------
uid_t unsigned signed
gid_t unsigned signed
dev_t unsigned signed
clock_t signed unsigned
For *uid_t* and *gid_t*, the GNU documentation specifies /_unsigned int_://
//http://www.gnu.org/software/libc/manual/html_node/Reading-Persona.html#index-uid_005ft-3309/
For *dev_t*, the specification requires /_an integer type no narrower
than int//_/: and given the value it is expected to hold (file device
numbers), making it /_unsigned_/ seems to be the correct choice.
/http://www.gnu.org/software/libc/manual/html_node/Attribute-Meanings.html#index-dev_005ft-1500/
*clock_t* is defined as the value returned by clock(), and the manual
page states that "if the processor time used is not available or its
value cannot be represented, the function returns the value (clock_t)
-1." This in turn suggests that clock_t should be a _signed_ type.
/http://www.gnu.org/software/libc/manual/html_node/CPU-Time.html#index-clock_005ft-2607
/As an additional reference, attached is the output generated by
musl-alltypes (posted on April 18) for the above architectures.
/
/Best regards,
Zvi
[-- Attachment #1.2: Type: text/html, Size: 2262 bytes --]
[-- Attachment #2: musl-alltypes.i386 --]
[-- Type: text/plain, Size: 5875 bytes --]
name size signed
==== ==== ======
wchar_t 4 signed
size_t 4 unsigned
ssize_t 4 signed
ptrdiff_t 4 signed
wint_t 4 signed
wctrans_t 4 unsigned
wctype_t 4 unsigned
int8_t 1 signed
int16_t 2 signed
int32_t 4 signed
int64_t 8 signed
uint8_t 1 unsigned
uint16_t 2 unsigned
uint32_t 4 unsigned
uint64_t 8 unsigned
__uint16_t 2 unsigned
__uint32_t 4 unsigned
__uint64_t 8 unsigned
int_fast8_t 1 signed
int_fast16_t 4 signed
int_fast32_t 4 signed
int_fast64_t 8 signed
uint_fast8_t 1 unsigned
uint_fast16_t 4 unsigned
uint_fast32_t 4 unsigned
uint_fast64_t 8 unsigned
intptr_t 4 signed
uintptr_t 4 unsigned
intmax_t 8 signed
uintmax_t 8 unsigned
float_t 12 signed
double_t 12 signed
time_t 4 signed
useconds_t 4 unsigned
suseconds_t 4 signed
va_list 4
timeval 8
timeval.tv_sec 4 signed
timeval.tv_usec 4 signed
timespec 8
timespec.tv_sec 4 signed
timespec.tv_nsec 4 signed
pid_t 4 signed
id_t 4 signed
uid_t 4 signed
gid_t 4 signed
key_t 4 signed
pthread_t 4
pthread_once_t 4 signed
pthread_key_t 4 signed
pthread_spinlock_t 4 signed
pthread_attr_t 36
pthread_attr_t.__u.__i[0] 4 signed
pthread_attr_t.__u.__s[0] 4 signed
pthread_mutexattr_t 4 unsigned
pthread_condattr_t 4 unsigned
pthread_barrierattr_t 4 unsigned
pthread_rwlockattr_t 8
pthread_rwlockattr_t.__attr[0] 4 signed
pthread_mutex_t 24
pthread_mutex_t.__u.__i[0] 4 signed
pthread_mutex_t.__u.__p[0] 4 unsigned
pthread_cond_t 48
pthread_cond_t.__u.__i[0] 4 signed
pthread_cond_t.__u.__p[0] 4 unsigned
pthread_barrier_t 20
pthread_barrier_t.__u.__i[0] 4 signed
pthread_barrier_t.__u.__p[0] 4 unsigned
pthread_rwlock_t 32
pthread_rwlock_t.__u.__i[0] 4 signed
pthread_rwlock_t.__u.__p[0] 4 unsigned
off_t 8 signed
mode_t 4 unsigned
nlink_t 4 unsigned
ino_t 8 unsigned
dev_t 8 signed
blksize_t 4 signed
blkcnt_t 8 signed
fsblkcnt_t 8 unsigned
fsfilcnt_t 8 unsigned
timer_t 4 unsigned
clockid_t 4 signed
clock_t 4 unsigned
sigset_t 128
sigset_t.__bits: 32 array-size
sigset_t.__bits[0] 4 signed
siginfo_t 128
socklen_t 4 unsigned
sa_family_t 2 unsigned
in_port_t 2 unsigned
in_addr_t 4 unsigned
in_addr 4
in_addr.s_addr 4 signed
nl_item 4 signed
iovec 8
iovec.iov_base 4 unsigned
iovec.iov_len 4 signed
[-- Attachment #3: musl-alltypes.x86_64 --]
[-- Type: text/plain, Size: 5875 bytes --]
name size signed
==== ==== ======
wchar_t 4 signed
size_t 8 unsigned
ssize_t 8 signed
ptrdiff_t 8 signed
wint_t 4 signed
wctrans_t 8 unsigned
wctype_t 8 unsigned
int8_t 1 signed
int16_t 2 signed
int32_t 4 signed
int64_t 8 signed
uint8_t 1 unsigned
uint16_t 2 unsigned
uint32_t 4 unsigned
uint64_t 8 unsigned
__uint16_t 2 unsigned
__uint32_t 4 unsigned
__uint64_t 8 unsigned
int_fast8_t 1 signed
int_fast16_t 4 signed
int_fast32_t 4 signed
int_fast64_t 8 signed
uint_fast8_t 1 unsigned
uint_fast16_t 4 unsigned
uint_fast32_t 4 unsigned
uint_fast64_t 8 unsigned
intptr_t 8 signed
uintptr_t 8 unsigned
intmax_t 8 signed
uintmax_t 8 unsigned
float_t 4 signed
double_t 8 signed
time_t 8 signed
useconds_t 4 unsigned
suseconds_t 8 signed
va_list 24
timeval 16
timeval.tv_sec 8 signed
timeval.tv_usec 8 signed
timespec 16
timespec.tv_sec 8 signed
timespec.tv_nsec 8 signed
pid_t 4 signed
id_t 4 signed
uid_t 4 unsigned
gid_t 4 unsigned
key_t 4 signed
pthread_t 8
pthread_once_t 4 signed
pthread_key_t 4 signed
pthread_spinlock_t 4 signed
pthread_attr_t 56
pthread_attr_t.__u.__i[0] 4 signed
pthread_attr_t.__u.__s[0] 8 signed
pthread_mutexattr_t 4 unsigned
pthread_condattr_t 4 unsigned
pthread_barrierattr_t 4 unsigned
pthread_rwlockattr_t 8
pthread_rwlockattr_t.__attr[0] 4 signed
pthread_mutex_t 40
pthread_mutex_t.__u.__i[0] 4 signed
pthread_mutex_t.__u.__p[0] 8 unsigned
pthread_cond_t 48
pthread_cond_t.__u.__i[0] 4 signed
pthread_cond_t.__u.__p[0] 8 unsigned
pthread_barrier_t 32
pthread_barrier_t.__u.__i[0] 4 signed
pthread_barrier_t.__u.__p[0] 8 unsigned
pthread_rwlock_t 56
pthread_rwlock_t.__u.__i[0] 4 signed
pthread_rwlock_t.__u.__p[0] 8 unsigned
off_t 8 signed
mode_t 4 unsigned
nlink_t 8 unsigned
ino_t 8 unsigned
dev_t 8 unsigned
blksize_t 8 signed
blkcnt_t 8 signed
fsblkcnt_t 8 unsigned
fsfilcnt_t 8 unsigned
timer_t 8 unsigned
clockid_t 4 signed
clock_t 8 signed
sigset_t 128
sigset_t.__bits: 16 array-size
sigset_t.__bits[0] 8 signed
siginfo_t 128
socklen_t 4 unsigned
sa_family_t 2 unsigned
in_port_t 2 unsigned
in_addr_t 4 unsigned
in_addr 4
in_addr.s_addr 4 signed
nl_item 4 signed
iovec 16
iovec.iov_base 8 unsigned
iovec.iov_len 8 signed
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: sign (in)consistency between architectures
2013-05-01 17:05 sign (in)consistency between architectures Z. Gilboa
@ 2013-05-01 18:00 ` Szabolcs Nagy
2013-05-01 20:00 ` Rich Felker
0 siblings, 1 reply; 10+ messages in thread
From: Szabolcs Nagy @ 2013-05-01 18:00 UTC (permalink / raw)
To: musl
* Z. Gilboa <zg7s@eservices.virginia.edu> [2013-05-01 13:05:03 -0400]:
> The current architecture-specific type definitions
> (arch/*/bits/alltypes.h) seem to entail the following inconsistent
> signed/unsigned types:
>
> type x86_64 i386
> -------------------------------
> uid_t unsigned signed
> gid_t unsigned signed
> dev_t unsigned signed
> clock_t signed unsigned
i can verify that glibc uses unsigned
uid_t,gid_t,dev_t and signed clock_t
of course applications should not depend on
the signedness, but if they appear in a c++
api then the difference can cause problems
and cock_t may be used in arithmetics where
signedness matters
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sign (in)consistency between architectures
2013-05-01 18:00 ` Szabolcs Nagy
@ 2013-05-01 20:00 ` Rich Felker
2013-05-01 22:41 ` Rich Felker
0 siblings, 1 reply; 10+ messages in thread
From: Rich Felker @ 2013-05-01 20:00 UTC (permalink / raw)
To: musl
On Wed, May 01, 2013 at 08:00:15PM +0200, Szabolcs Nagy wrote:
> * Z. Gilboa <zg7s@eservices.virginia.edu> [2013-05-01 13:05:03 -0400]:
> > The current architecture-specific type definitions
> > (arch/*/bits/alltypes.h) seem to entail the following inconsistent
> > signed/unsigned types:
> >
> > type x86_64 i386
> > -------------------------------
> > uid_t unsigned signed
> > gid_t unsigned signed
> > dev_t unsigned signed
> > clock_t signed unsigned
>
>
> i can verify that glibc uses unsigned
> uid_t,gid_t,dev_t and signed clock_t
>
> of course applications should not depend on
> the signedness, but if they appear in a c++
> api then the difference can cause problems
>
> and cock_t may be used in arithmetics where
> signedness matters
uid_t, gid_t, and dev_t we can consider changing; I don't think it
matters a whole lot and like you said they affect C++ ABI. clock_t
cannot be changed without making the clock() function unusable. See
glibc bug #13080 (WONTFIX):
http://sourceware.org/bugzilla/show_bug.cgi?id=13080
Rich
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sign (in)consistency between architectures
2013-05-01 20:00 ` Rich Felker
@ 2013-05-01 22:41 ` Rich Felker
2013-05-02 1:39 ` Z. Gilboa
0 siblings, 1 reply; 10+ messages in thread
From: Rich Felker @ 2013-05-01 22:41 UTC (permalink / raw)
To: musl
On Wed, May 01, 2013 at 04:00:07PM -0400, Rich Felker wrote:
> On Wed, May 01, 2013 at 08:00:15PM +0200, Szabolcs Nagy wrote:
> > * Z. Gilboa <zg7s@eservices.virginia.edu> [2013-05-01 13:05:03 -0400]:
> > > The current architecture-specific type definitions
> > > (arch/*/bits/alltypes.h) seem to entail the following inconsistent
> > > signed/unsigned types:
> > >
> > > type x86_64 i386
> > > -------------------------------
> > > uid_t unsigned signed
> > > gid_t unsigned signed
> > > dev_t unsigned signed
> > > clock_t signed unsigned
> >
> >
> > i can verify that glibc uses unsigned
> > uid_t,gid_t,dev_t and signed clock_t
> >
> > of course applications should not depend on
> > the signedness, but if they appear in a c++
> > api then the difference can cause problems
> >
> > and cock_t may be used in arithmetics where
> > signedness matters
>
> uid_t, gid_t, and dev_t we can consider changing; I don't think it
> matters a whole lot and like you said they affect C++ ABI. clock_t
> cannot be changed without making the clock() function unusable. See
> glibc bug #13080 (WONTFIX):
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=13080
I just posted a followup on this bug: from what I can tell, it's
questionable whether having the return value of clock() wrap is
conforming even if clock_t is an unsigned type, and definitely
non-conforming if it's a signed type. As such, I see three possible
solutions:
1. Leave things along and do it the way musl does it now, where
subtracting (unsigned) results works. We should probably add a check
to see if the return value would be equal to (clock_t)-1, and if so,
either add or subtract 1, so that the caller does not interpret the
return value as an error.
2. Change clock_t to a signed type, and have clock() check for
overflow and permanently return -1 once the process has used more than
2147 seconds of cpu time. This seems undesirable to applications.
3. Change clock_t to long long on 32-bit targets. This would be
formally incompatible with the the glibc/LSB ABI, but in practice the
worst that would happen is that the register containing the upper bits
would get ignored.
Any opinions on the issue?
Rich
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sign (in)consistency between architectures
2013-05-01 22:41 ` Rich Felker
@ 2013-05-02 1:39 ` Z. Gilboa
2013-05-02 2:47 ` Rich Felker
0 siblings, 1 reply; 10+ messages in thread
From: Z. Gilboa @ 2013-05-02 1:39 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]
Am 01.05.2013 18:41, schrieb Rich Felker:
> On Wed, May 01, 2013 at 04:00:07PM -0400, Rich Felker wrote:
>> On Wed, May 01, 2013 at 08:00:15PM +0200, Szabolcs Nagy wrote:
>>> * Z. Gilboa <zg7s@eservices.virginia.edu> [2013-05-01 13:05:03 -0400]:
>>>> The current architecture-specific type definitions
>>>> (arch/*/bits/alltypes.h) seem to entail the following inconsistent
>>>> signed/unsigned types:
>>>>
>>>> type x86_64 i386
>>>> -------------------------------
>>>> uid_t unsigned signed
>>>> gid_t unsigned signed
>>>> dev_t unsigned signed
>>>> clock_t signed unsigned
>>>
>>> i can verify that glibc uses unsigned
>>> uid_t,gid_t,dev_t and signed clock_t
>>>
>>> of course applications should not depend on
>>> the signedness, but if they appear in a c++
>>> api then the difference can cause problems
>>>
>>> and cock_t may be used in arithmetics where
>>> signedness matters
>> uid_t, gid_t, and dev_t we can consider changing; I don't think it
>> matters a whole lot and like you said they affect C++ ABI. clock_t
>> cannot be changed without making the clock() function unusable. See
>> glibc bug #13080 (WONTFIX):
>>
>> http://sourceware.org/bugzilla/show_bug.cgi?id=13080
> I just posted a followup on this bug: from what I can tell, it's
> questionable whether having the return value of clock() wrap is
> conforming even if clock_t is an unsigned type, and definitely
> non-conforming if it's a signed type. As such, I see three possible
> solutions:
>
> 1. Leave things along and do it the way musl does it now, where
> subtracting (unsigned) results works. We should probably add a check
> to see if the return value would be equal to (clock_t)-1, and if so,
> either add or subtract 1, so that the caller does not interpret the
> return value as an error.
>
> 2. Change clock_t to a signed type, and have clock() check for
> overflow and permanently return -1 once the process has used more than
> 2147 seconds of cpu time. This seems undesirable to applications.
>
> 3. Change clock_t to long long on 32-bit targets. This would be
> formally incompatible with the the glibc/LSB ABI, but in practice the
> worst that would happen is that the register containing the upper bits
> would get ignored.
>
> Any opinions on the issue?
>
> Rich
I consider the difference in sign to be of much greater significance,
and therefore would prefer option #3. Besides, with enough patience and
perseverance (/der lange Marsch durch die Institutionen.../), this might
actually become the glibc solution as well:)
[-- Attachment #2: Type: text/html, Size: 3338 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sign (in)consistency between architectures
2013-05-02 1:39 ` Z. Gilboa
@ 2013-05-02 2:47 ` Rich Felker
2013-05-02 8:12 ` Jens Gustedt
0 siblings, 1 reply; 10+ messages in thread
From: Rich Felker @ 2013-05-02 2:47 UTC (permalink / raw)
To: musl
On Wed, May 01, 2013 at 09:39:00PM -0400, Z. Gilboa wrote:
> I consider the difference in sign to be of much greater
> significance, and therefore would prefer option #3. Besides, with
> enough patience and perseverance (/der lange Marsch durch die
> Institutionen.../), this might actually become the glibc solution as
> well:)
Well, the current text of POSIX acknowledges in the Application Usage
text that, on some implementations, the return value of clock() wraps.
Moreover, it mentions wrapping after 2147 seconds, which would be the
signed wrapping point, but not whether the wrapping is to INT_MIN or
to 0. It's hard to say which is worse; wrapping to INT_MIN gives you
UB (integer overflow) when you subtract INT_MIN-INT_MAX, but in the
real world you probably get the value you wanted, 1. Wrapping to 0 on
the other hand would give you a gigantic difference when the clock
wraps.
Still, I see no acknowledgement that it might wrap in the ISO C
definition for clock(), so it's possible that an interpretation would
declare the wrapping non-conforming.
In any case, I think all of these issues are good arguments that
nobodu should ever use clock_t or the clock() function...
Rich
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sign (in)consistency between architectures
2013-05-02 2:47 ` Rich Felker
@ 2013-05-02 8:12 ` Jens Gustedt
2013-05-02 10:13 ` Szabolcs Nagy
0 siblings, 1 reply; 10+ messages in thread
From: Jens Gustedt @ 2013-05-02 8:12 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]
Am Mittwoch, den 01.05.2013, 22:47 -0400 schrieb Rich Felker:
> In any case, I think all of these issues are good arguments that
> nobodu should ever use clock_t or the clock() function...
Hm, AFAIR clock() is the only available function in C alone (including
C11) that gives access to something like the "processor time". C11 a
bit more of time handling to have access to something like a real time
clock, but for processor time clock() is the only one. (MS got that
wrong, but this is their problem.)
So I think it still makes sense to use it for "short" measures, not
for the whole run of a program. The standard suggests, I think, that
you'd take a point of measure before and after the interval that
interests you. For such a strategy to work you'd either have to know
that no overflow can reasonably occur (by having a wide type) or that
it may do no harm (by using an unsigned type).
I would prefer to have both worlds by using uint64_t (or directly the
underlying base type) uniformly. There is no reason to have it signed:
- this is "processor time" and not wallclock time, so it should be
monotonic, and not be affected by setting the system time
- an application should always subtract the first value of a measure
from the second
- an application should never expect to be able to measure intervals
that are longer than a few hours, and it can deduce the maximum
time it has for a measure with CLOCKS_PER_SEC
Jens
--
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090 ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536 ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183 ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sign (in)consistency between architectures
2013-05-02 8:12 ` Jens Gustedt
@ 2013-05-02 10:13 ` Szabolcs Nagy
2013-05-02 12:12 ` Jens Gustedt
0 siblings, 1 reply; 10+ messages in thread
From: Szabolcs Nagy @ 2013-05-02 10:13 UTC (permalink / raw)
To: musl
* Jens Gustedt <jens.gustedt@inria.fr> [2013-05-02 10:12:39 +0200]:
> I would prefer to have both worlds by using uint64_t (or directly the
> underlying base type) uniformly. There is no reason to have it signed:
>
yes probably that's the best solution
but note that even that can hurt: i've seen code like
t = (double)clock();
(eg the time module in python does this) where interesting
low bits may get lost if clock_t is uint64_t
this might be common because clock_t is permitted to be
a floating-point type
of course this should not be a problem if the cast is
applied to the difference only
(other than uint64->double conversion is usually much
slower than int32->double conversion)
..but this issue is present on 64bit platforms anyway
siginfo is affected as well: clock_t is used in the union
in it which i think is aligned with glibc now
but i'm not against the uint64_t solution if we decide
breaking glibc abi here is ok
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sign (in)consistency between architectures
2013-05-02 10:13 ` Szabolcs Nagy
@ 2013-05-02 12:12 ` Jens Gustedt
2013-05-02 13:08 ` Szabolcs Nagy
0 siblings, 1 reply; 10+ messages in thread
From: Jens Gustedt @ 2013-05-02 12:12 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]
Am Donnerstag, den 02.05.2013, 12:13 +0200 schrieb Szabolcs Nagy:
> * Jens Gustedt <jens.gustedt@inria.fr> [2013-05-02 10:12:39 +0200]:
> > I would prefer to have both worlds by using uint64_t (or directly the
> > underlying base type) uniformly. There is no reason to have it signed:
> >
>
> yes probably that's the best solution
>
> but note that even that can hurt: i've seen code like
>
> t = (double)clock();
>
> (eg the time module in python does this) where interesting
> low bits may get lost if clock_t is uint64_t
*and* if the actual value is larger than (1ull << 50) or something
like that.
An application that is interested in the low bits (probably most of
them are) should probably compute the integer and fractional parts of
the time in seconds by using CLOCKS_PER_SECOND, anyhow.
> this might be common because clock_t is permitted to be
> a floating-point type
yes, any real type is permitted in C, I think.
Jens
--
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090 ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536 ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183 ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sign (in)consistency between architectures
2013-05-02 12:12 ` Jens Gustedt
@ 2013-05-02 13:08 ` Szabolcs Nagy
0 siblings, 0 replies; 10+ messages in thread
From: Szabolcs Nagy @ 2013-05-02 13:08 UTC (permalink / raw)
To: musl
* Jens Gustedt <jens.gustedt@inria.fr> [2013-05-02 14:12:37 +0200]:
> Am Donnerstag, den 02.05.2013, 12:13 +0200 schrieb Szabolcs Nagy:
> >
> > t = (double)clock();
> >
> > (eg the time module in python does this) where interesting
> > low bits may get lost if clock_t is uint64_t
>
>
> *and* if the actual value is larger than (1ull << 50) or something
> like that.
larger than (1ull << 53)
so it does not matter if the counter always start from 0
at process startup
btw the times() fallback in the current clock code seems
to be wrong: it multiplies the result by 100 which would
mean 10000 Hz kernel clock tick
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-05-02 13:08 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-01 17:05 sign (in)consistency between architectures Z. Gilboa
2013-05-01 18:00 ` Szabolcs Nagy
2013-05-01 20:00 ` Rich Felker
2013-05-01 22:41 ` Rich Felker
2013-05-02 1:39 ` Z. Gilboa
2013-05-02 2:47 ` Rich Felker
2013-05-02 8:12 ` Jens Gustedt
2013-05-02 10:13 ` Szabolcs Nagy
2013-05-02 12:12 ` Jens Gustedt
2013-05-02 13:08 ` Szabolcs Nagy
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).