summaryrefslogtreecommitdiffstats
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* Adjust the exponent before converting the result from double todas2008-01-281-16/+10
| | | | | float precision. This fixes some double rounding problems for subnormals and simplifies things a bit.
* Our fts(3) API, as inherited from 4.4BSD, suffers from integeryar2008-01-266-93/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fields in FTS and FTSENT structs being too narrow. In addition, the narrow types creep from there into fts.c. As a result, fts(3) consumers, e.g., find(1) or rm(1), can't handle file trees an ordinary user can create, which can have security implications. To fix the historic implementation of fts(3), OpenBSD and NetBSD have already changed <fts.h> in somewhat incompatible ways, so we are free to do so, too. This change is a superset of changes from the other BSDs with a few more improvements. It doesn't touch fts(3) functionality; it just extends integer types used by it to match modern reality and the C standard. Here are its points: o For C object sizes, use size_t unless it's 100% certain that the object will be really small. (Note that fts(3) can construct pathnames _much_ longer than PATH_MAX for its consumers.) o Avoid the short types because on modern platforms using them results in larger and slower code. Change shorts to ints as follows: - For variables than count simple, limited things like states, use plain vanilla `int' as it's the type of choice in C. - For a limited number of bit flags use `unsigned' because signed bit-wise operations are implementation-defined, i.e., unportable, in C. o For things that should be at least 64 bits wide, use long long and not int64_t, as the latter is an optional type. See FTSENT.fts_number aka FTS.fts_bignum. Extending fts_number `to satisfy future needs' is pointless because there is fts_pointer, which can be used to link to arbitrary data from an FTSENT. However, there already are fts(3) consumers that require fts_number, or fts_bignum, have at least 64 bits in it, so we must allow for them. o For the tree depth, use `long'. This is a trade-off between making this field too wide and allowing for 64-bit inode numbers and/or chain-mounted filesystems. On the one hand, `long' is almost enough for 32-bit filesystems on a 32-bit platform (our ino_t is uint32_t now). On the other hand, platforms with a 64-bit (or wider) `long' will be ready for 64-bit inode numbers, as well as for several 32-bit filesystems mounted one under another. Note that fts_level has to be signed because -1 is a magic value for it, FTS_ROOTPARENTLEVEL. o For the `nlinks' local var in fts_build(), use `long'. The logic in fts_build() requires that `nlinks' be signed, but our nlink_t currently is uint16_t. Therefore let's make the signed var wide enough to be able to represent 2^16-1 in pure C99, and even 2^32-1 on a 64-bit platform. Perhaps the logic should be changed just to use nlink_t, but it can be done later w/o breaking fts(3) ABI any more because `nlinks' is just a local var. This commit also inludes supporting stuff for the fts change: o Preserve the old versions of fts(3) functions through libc symbol versioning because the old versions appeared in all our former releases. o Bump __FreeBSD_version just in case. There is a small chance that some ill-written 3-rd party apps may fail to build or work correctly if compiled after this change. o Update the fts(3) manpage accordingly. In particular, remove references to fts_bignum, which was a FreeBSD-specific hack to work around the too narrow types of FTSENT members. Now fts_number is at least 64 bits wide (long long) and fts_bignum is an undocumented alias for fts_number kept around for compatibility reasons. According to Google Code Search, the only big consumers of fts_bignum are in our own source tree, so they can be fixed easily to use fts_number. o Mention the change in src/UPDATING. PR: bin/104458 Approved by: re (quite a while ago) Discussed with: deischen (the symbol versioning part) Reviewed by: -arch (mostly silence); das (generally OK, but we didn't agree on some types used; assuming that no objections on -arch let me to stick to my opinion)
* Fix a harmless type error in 1.9.bde2008-01-251-1/+1
|
* Fix a regression introduced in rev 1.99: replace fclose(f) with a commentdes2008-01-231-1/+5
| | | | | | explaining why f cannot possibly be a valid FILE * at this point. MFC after: 1 day
* Track version # from the portable release.kientzle2008-01-231-1/+1
|
* Explain a subtle API change that was made recently.kientzle2008-01-231-0/+21
| | | | | | Even though I believe this is a good change, it does have the potential to break certain clients, so it's good to document the reasoning behind the change.
* Properly pad symlinks when writing cpio "newc" format.kientzle2008-01-232-4/+49
| | | | | Thanks to: Jesse Barker for reporting this. MFC after: 7 days
* Fix longstanding mb/wc functions segfault if error occurseache2008-01-231-29/+39
| | | | | inside _<encoding>_init(). Currently _EUC_init() only was affected.
* Better fix for longstanding segfault. Don't touch current locale at allache2008-01-231-17/+29
| | | | on unknown encoding. Previous fix resets it to POSIX.
* 1) Add (void) cast to _none_init() (while I am here)ache2008-01-231-2/+4
| | | | | 2) Fix longstanding segfault in mb/wc code when unknown encoding is specified in the locale file (mb/wc functions becomes NULL in that case).
* Xref flopen.3 which references this manual page.trhodes2008-01-221-1/+2
| | | | PR: 112650
* Introduce new encoding: "ASCII"ache2008-01-214-1/+191
| | | | | It differs from default C/POSIX "NONE" mainly by stricter 8bit check for mb*towc*/wc*tomb* family, returning EILSEQ
* Fix cutoffs. This is just a cleanup and an optimization for unusualbde2008-01-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cases which are used mainly by regression tests. As usual, the cutoff for tiny args was not correctly translated to float precision. It was 2**-54 but 2**-24 works. It must be about 2**-precision, since the error from approximating log(1+x) by x is about the same as |x|. Exhaustive testing shows that 2**-24 gives perfect rounding in round-to-nearest mode. Similarly for the cutoff for being small, except this is not used by so many other functions. It was 2**-29 but 2**-15 works. It must be a bit smaller than sqrt(2**-precision), since the error from approximating log(1+x) by x-x*x/2 is about the same as x*x. Exhaustive testing shows that 2**-15 gives a maximum error of 0.5052 ulps in round-to-nearest-mode. The algorithm for the general case is only good for 0.8388 ulps, so this is sufficient (but it loses slightly on i386 -- then extra precision gives 0.5032 ulps for the general case). While investigating this, I noticed that optimizing the usual case by falling into a middle case involving a simple polynomial evaluation (return x-x*x/2 instead of x here) is not such a good idea since it gives an enormous pessimization of tinier args on machines for which denormals are slow. Float x*x/2 is denormal when |x| ~< 2**-64 and x*x/2 is evaluated in float precision, so it can easily be denormal for normal x. This is even more interesting for general polynomial evaluations. Multiplying out large powers of x is normally a good optimization since it reduces dependencies, but it creates denormals starting with quite large x.
* Oops, when merging from the float version to the double versions, don'tbde2008-01-201-1/+1
| | | | | | | | | forget to translate "float" to "double". ucbtest didn't detect the bug, but exhaustive testing of the float case relative to the double case eventually did. The bug only affects args x with |x| ~> 2**19*(pi/2) on non-i386 (i386 is broken in a different way for large args).
* Remove the float version of the kernel of arg reduction for pi/2, sincebde2008-01-191-198/+0
| | | | | | | it should never have existed and it has not been used for many years (floats are reduced faster using doubles). All relevant changes (just the workaround for broken assignment) have been merged to the double version.
* Do an ordinary assignment in STRICT_ASSIGN() except for floats untilbde2008-01-191-2/+6
| | | | | | | | | there is a problem with non-floats (when i386 defaults to extra precision). This essentially restores yesterday's behaviour for doubles on i386 (since generic rint() isn't used and everywhere else assumed working assignment), but for arches that use the generic rint() it finishes restoring some of 1995's behaviour (don't waste time doing unnecessary store/load).
* Use STRICT_ASSIGN() for exp2f() and exp2() instead of a volatilebde2008-01-192-4/+5
| | | | | | | | | | | | | | | | | | | variable hack for exp2f() only. The volatile variable had a surprisingly large cost for exp2f() -- 19 cycles or 15% on i386 in the worst case observed. This is only partly explained by there being several references to the variable, only one of which benefited from it being volatile. Arches that have working assignment are likely to benefit even more from not having any volatile variable. exp2() now has a chance of working with extra precision on i386. exp2() has even more references to the variable, so it would have been pessimized more by simply declaring the variable as volatile. Even the temporary volatile variable for STRICT_ASSIGN costs 5-10% on i386, (A64) so I will change STRICT_ASSIGN() to do an ordinary assignment until i386 defaults to extra precision.
* Use STRICT_ASSIGN() for _kernel_rem_pio2f() and _kernel_rem_pio2f()bde2008-01-192-7/+10
| | | | | | | | | | | | instead of a volatile cast hack for the float version only. The cast hack broke with gcc-4, but this was harmless since the float version hasn't been used for a few years. Merge from the float version so that the double version has a chance of working on i386 with extra precision. See k_rem_pio2f.c rev.1.8 for the original hack. Convert to _FBSDID().
* Use STRICT_ASSIGN() for log1pf() and log1p() instead of a volatile castbde2008-01-192-8/+10
| | | | | | | | | | | | | | hack for log1pf() only. The cast hack broke with gcc-4, resulting in ~1 million errors of more than 1 ulp, with a maximum error of ~1.5 ulps. Now the maximum error for log1pf() on i386 is 0.5034 ulps again (this depends on extra precision), and log1p() has a chance of working with extra precision. See s_log1pf.c 1.8 for the original hack. (It claims only 62343 large errors). Convert to _FBSDID(). Another thing broken with gcc-4 is the static const hack used for rcsids.
* Use STRICT_ASSIGN() instead of assorted direct volatile hacks to workbde2008-01-192-6/+8
| | | | | | | | | | | | | | | | | | around assignments not working for gcc on i386. Now volatile hacks for rint() and rintf() don't needlessly pessimize so many arches and the remaining pessimizations (for arm and powerpc) can be avoided centrally. This cleans up after s_rint.c 1.3 and 1.13 and s_rintf.c 1.3 and 1.9: - s_rint.c 1.13 broke 1.3 by only using a volatile cast hack in 1 place when it was needed in 2 places, and the volatile cast hack stopped working with gcc-4. These bugs only affected correctness tests on i386 since i386 normally uses asm rint() and doesn't support the extra precision mode that would break assignments of doubles. - s_rintf.c 1.9 improved(?) on 1.3 by using a volatile variable hack instead of an extra-precision variable hack, but it declared 2 variables as volatile when only 1 variable needed to be volatile. This only affected speed tests on i386 since i386 uses asm rintf().
* Use volatile hacks to make sure these functions generate an underflowdas2008-01-183-3/+6
| | | | | exception when they're supposed to. Previously, gcc -O2 was optimizing away the statement that generated it.
* Hook up exp2l() and related docs to the build.das2008-01-182-6/+7
|
* Introduce a new log(3) manpage and move the relevant functions there.das2008-01-182-69/+118
| | | | | | Document exp2l() in exp(3), and remove the quaint discussion of topics such as what these functions were called on the HP-71B's variant of BASIC.
* Implement exp2l(). There is one version for machines with 80-bitdas2008-01-184-0/+725
| | | | | | | | long doubles (i386, amd64, ia64) and one for machines with 128-bit long doubles (sparc64). Other platforms use the double version. I've only done runtime testing on i386. Thanks to bde@ for helpful discussions and bugfixes.
* Add a new union member to access the exponent and sign of a long doubledas2008-01-181-0/+5
| | | | in a single op. Idea from bde.
* I misread the Tinderbox error; this should really unbreak 64-bit builds.kientzle2008-01-181-1/+1
| | | | Pointy hats, yep, keep 'em coming. ;-/
* Fix 64-bit build after my last commit. <sigh>kientzle2008-01-181-1/+1
|
* The previous commit caused the archive_write_disk interface tokientzle2008-01-181-0/+2
| | | | | start obeying filesize limits; this test wasn't properly setting file sizes before trying to write file data.
* Issues with hardlinks in newc-format files prompted me tokientzle2008-01-183-6/+198
| | | | | | | | | | | | | | | | | | | | | | | | | | | write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
* Reconnect the progress callback. It may not get calledkientzle2008-01-181-2/+8
| | | | | | | as often as you might expect, but at least it will get called now. Thanks to: David Topham for asking how this got disconnected.
* SYSTEM_SCOPE_ONLY flag is no longer needed, it is the only mode libthrdavidxu2008-01-181-2/+0
| | | | supports.
* Add a macro STRICT_ASSIGN() to help avoid the compiler bug thatbde2008-01-171-0/+16
| | | | | | | | | | | | | assignments and casts don't clip extra precision, if any. The implementation is to assign to a temporary volatile variable and read the result back to assign to the original lvalue. lib/msun currently 2 different hard-coded hacks to avoid the problem in just a few places and needs it in a few more places. One variant uses volatile for the original lvalue. This works but is slower than necessary. Another temporarily casts the lvalue to volatile. This broke with gcc-4.2.1 or earlier (gcc now stores to the lvalue but doesn't load from it).
* Add an alternative view of the bits in an 80-bit long double (64+16bde2008-01-173-3/+24
| | | | | | | | | | | | | | | | | | | | instead of 32+32+15+1) on all arches that have such long doubles (amd64, ia64 and i386). Large objects should be be accessed in large units, and the 32+32+15+1[+padding] decomposition asks for almost the opposite of that, sometimes resulting in very slow accesses depending on how well the compiler ignores what we ask for and converts to the best units for the given machine. E.g., on Athlons, there is a 10-20 cycle penalty for accessing the middle 32-bit word immediately after an 80-bit store. Whether actually using the alternative view is better is very machine- dependent. A 32+32+16 view is probably best with old 32-bit systems and gcc through 4.2.1. The compiler should mostly avoid the view and generate best accesses, but gcc-4.2.1 is far from doing that. I think 64+16 is best for now. Similarly for doubles -- they should be using 64+0 especially on 64-bit machines, but fdlibm uses 32+32 extensively for them. Fortunately, in 64-bit mode for doubles, gcc already ignores the 32+32-bit view and generates best accesses in many cases.
* Fix some style nits.remko2008-01-161-4/+4
| | | | | Prodded by: brueffer MFC After: 3 days
* Optimize this a bit better.das2008-01-151-13/+18
| | | | Submitted by: bde (although these aren't all of his changes)
* Remove some now-unused macros.jhb2008-01-151-3/+1
| | | | MFC after: 1 week
* Handle Zip archives that are "multi-part archives with onlykientzle2008-01-151-1/+19
| | | | | | | | | | | | one part" by simply ignoring the marker at the beginning of the file. (Zip archivers reserve four bytes at the beginning of each part of a multi-part archive, if it happens to only require one part, those four bytes get filled with a placeholder that can be ignored.) Thanks to: Marius Nuennerich, for pointing me to a Zip archive that libarchive couldn't handle MFC after: 7 days
* Put back the openpty(3) and ptsname(3) fixes but don't disable ptsname(3)jhb2008-01-152-101/+34
| | | | | on pts(4) devices this time. This fixes the issues while leaving pts(4) enabled on HEAD.
* Back out last commit, since it accidentally broke pts.cperciva2008-01-152-40/+103
| | | | | The security fix will be re-committed soon, hopefully without breaking anything.
* In getttyent(3), if /etc/ttys doesn't end in a newline, don'tdas2008-01-151-1/+1
| | | | | | | freak out and keep trying to expand the buffer until realloc() fails. PR: 114398
* Support uppercase hex digits in cpio archives.kientzle2008-01-151-3/+5
| | | | | Thanks to: Joshua Kwan MFC after: 7 days
* Update the manpage for openpty(3) to account for the recent fixes.jhb2008-01-141-18/+14
| | | | | | | | | | Specifically, remove the BUGS section and note that openpty(3) now always does the various security-related steps. Also, update the error return value section. The PR below is for the original bug rather than the doc updates. MFC after: 1 week PR: bin/9770
* Fix issues which allow snooping on ptys. [08:01]cperciva2008-01-143-105/+42
| | | | | | | Fix an off-by-one error in inet_network(3). [08:02] Security: FreeBSD-SA-08:01.pty Security: FreeBSD-SA-08:02.libc
* Changing 'r' to a size_t in the previous commit turned quicksortdas2008-01-141-4/+5
| | | | | | | into slowsort for some sequences because different parts of the code used 'r' to store two different things, one of which was signed. Clean things up by splitting 'r' into two variables, and use a more meaningful name.
* Implement rintl(), nearbyintl(), lrintl(), and llrintl().das2008-01-1418-35/+383
| | | | Thanks to bde@ for feedback and testing of rintl().
* Since the tar bidder can never get called more than once, itkientzle2008-01-132-23/+59
| | | | | | | | | | | | doesn't need to compensate for this situation. While here, fix a minor longstanding bug that empty tar archives (which begin with at least 512 zero bytes) never properly reported their format. In particular, this fixes the output of: bsdtar tvvf /dev/zero And, of course, a new test to verify that libarchive correctly recognizes the format of such files.
* Update for the 'file' 4.23 import.obrien2008-01-131-4/+23
|
* Use size_t to avoid overflow when sorting arrays larger than 2 GB.das2008-01-132-2/+3
| | | | | PR: 111085 MFC after: 2 weeks
* Plug memory leaks that is observed when argbuf or argspc is used in thedelphij2008-01-121-0/+4
| | | | | | | | context. Submitted by: Michal Vranek <michal.vranek seznam cz> PR: bin/118380 MFC after: 1 month
* - Correct the range check in the double version to catch negative valuesdas2008-01-112-19/+22
| | | | | that would overflow. - Style fixes and improved handling of NaNs suggested by bde.
OpenPOWER on IntegriCloud