- 11 11月, 2011 1 次提交
-
-
由 Rich Felker 提交于
patch by Pascal Cuoq (with minor tweaks to comments)
-
- 20 9月, 2011 1 次提交
-
-
由 Rich Felker 提交于
this was the cause of crashes in printf when attempting to print floating point values.
-
- 06 9月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-
- 15 7月, 2011 1 次提交
-
-
由 Rich Felker 提交于
1. my interpretation of subject sequence definition was wrong. adjust parser to conform to the standard. 2. some code for handling tail overflow case was missing (forgot to finish writing it). 3. typo (= instead of ==) caused ERANGE to wrongly behave like EINVAL
-
- 14 7月, 2011 2 次提交
-
-
由 Rich Felker 提交于
stopping without letting the parser see a stop character prevented getting a result. so treat all high chars as the null character and pass them into the parser. also eliminated ugly tmp var using compound literals.
-
由 Rich Felker 提交于
this fixes a number of bugs in integer parsing due to lazy haphazard wrapping, as well as some misinterpretations of the standard. the new parser is able to work character-at-a-time or on whole strings, making it easy to support the wide functions without unbounded space for conversion. it will also be possible to update scanf to use the new parser.
-
- 29 4月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-
- 28 4月, 2011 1 次提交
-
-
由 Rich Felker 提交于
Smoothsort is an adaptive variant of heapsort. This version was written by Valentin Ochs (apo) specifically for inclusion in musl. I worked with him to get it working in O(1) memory usage even with giant array element widths, and to optimize it heavily for size and speed. It's still roughly 4 times as large as the old heap sort implementation, but roughly 20 times faster given an almost-sorted array of 1M elements (20 being the base-2 log of 1M), i.e. it really does reduce O(n log n) to O(n) in the mostly-sorted case. It's still somewhat slower than glibc's Introsort for random input, but now considerably faster than glibc when the input is already sorted, or mostly sorted.
-
- 08 4月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-
- 04 4月, 2011 1 次提交
-
-
由 Rich Felker 提交于
0e10000000000000000000000000000000 was setting ERANGE exponent char e/p was considered part of the match even if not followed by a valid decimal value "1e +10" was parsed as "1e+10" hex digits were misinterpreted as 0..5 instead of 10..15
-
- 26 3月, 2011 1 次提交
-
-
由 Rich Felker 提交于
sadly the C language does not specify any such implicit conversion, so this is not a matter of just fixing warnings (as gcc treats it) but actual errors. i would like to revisit a number of these changes and possibly revise the types used to reduce the number of casts required.
-
- 17 2月, 2011 1 次提交
-
-
由 Rich Felker 提交于
this is actually a workaround for a bug in gcc, whereby it asserts inequality of the keys being compared...
-
- 15 2月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-
- 12 2月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-