summaryrefslogtreecommitdiffstats
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* Avoid assignments to cast expressions.stefanf2004-06-081-3/+3
| | | | | Reviewed by: md5 Approved by: das (mentor)
* Signal handlers are supposed to take an int parameter.stefanf2004-06-081-2/+2
| | | | Approved by: das (mentor)
* Remove a couple of casts added for an ancient Sun compiler.stefanf2004-06-081-11/+2
| | | | Approved by: das (mentor)
* The third operand of the conditional operator should have type void too.stefanf2004-06-082-2/+2
| | | | Approved by: das (mentor)
* In fts_build(), if we try to chdir and fail (e.g. due to lack of searchdas2004-06-082-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | permission), try to continue in FTS_DONTCHDIR mode. Of course this won't work for long paths, but we can't descend more than one pathname component beyond the directory anyway if we lack search permission. Here is a transcript demonstrating the change, where oldls is ls(1) linked with the old fts(3): das@VARK:~> mkdir t && touch t/{a,b,c} && chmod u-x t das@VARK:~> oldls t a b c das@VARK:~> oldls -l t das@VARK:~> \ls t a b c das@VARK:~> \ls -l t ls: a: Permission denied ls: b: Permission denied ls: c: Permission denied I had forgotten about this patch until bde reminded me. He reports using it without problems for over a year. PR: 45723
* Rename cantwrite() to prepwrite(). The latter is less confusing,das2004-06-081-4/+1
| | | | | | since the macro isn't really a predicate, and it has side-effects. Also, don't set errno if prepwrite() fails, since this is done in prepwrite() now.
* Rename cantwrite() to prepwrite(). The latter is less confusing,das2004-06-084-5/+6
| | | | since the macro isn't really a predicate, and it has side-effects.
* Set errno to EBADF on attempts to write to a stream that is notdas2004-06-081-2/+5
| | | | | | | | | writable. Affected callers include fwrite(), put?(), and *printf(). The issue of whether this is the right errno for funopened streams is unresolved, but that's an obscure case, and some errno is better than no errno. Discussed with: bde, jkh
* Correct some spelling errors.kientzle2004-06-081-6/+6
|
* Use ".In" to mark up C include file names.yar2004-06-071-2/+4
|
* Each sentence should begin on a new line.yar2004-06-071-10/+16
|
* Extend and improve the mdoc(7) markup of this page.yar2004-06-071-32/+60
| | | | Reviewed by: ru
* Avoid clobbering the red zone when running on the new context's stack intjr2004-06-072-0/+10
| | | | _amd64_restore_context().
* Linux (at least Debian) requires sys/types.h to get off_t.kientzle2004-06-072-0/+2
|
* Finally document the option to avoid zombie creationyar2004-06-073-2/+41
| | | | through ignoring SIGCHLD.
* Add round(3) and roundf(3) and the associated documentation.das2004-06-075-2/+183
| | | | | | PR: 59797 Submitted by: "Steven G. Kargl" <kargl@troutmask.apl.washington.edu> Reviewed by: bde (earlier version, last year)
* History: A few very, very old tar programs used the filename tokientzle2004-06-071-12/+10
| | | | | | | | | | | | distinguish files from dirs (trailing '/' indicated a dir). Since POSIX.1-1987, this convention is no longer necessary. However, there are current tar programs that pretend to write POSIX-compliant archives, yet store directories as "regular files", relying on this old filename convention to save them. <sigh> So, move the check for this old convention so it applies to all tar archives, not just those identified as "old." Pointed out by: Broken distfile for audio/faad port
* Tar bidder should just return a zero bid ("not me!") ifkientzle2004-06-071-3/+9
| | | | | | | | | | it sees a truncated input the first time it gets called. (In particular, files shorter than 512 bytes cannot be tar archives.) This allows the top-level archive_read_next_header code to generate a proper error message for unrecognized file types. Pointed out by: numerous ports that expect tar to extract non-tar files ;-( Thanks to: Kris Kennaway
* Add fenv.h, fenv.c, and the associated documentation to the libmdas2004-06-061-5/+12
| | | | | | | build. To facilitate this, add ${.CURDIR}/${ARCH} to make's search path unconditionally. Reviewed by: standards@
* Add documentation for:das2004-06-064-0/+601
| | | | | | | | | | - fenv(3) - feclearexcept(3), fegetexceptflag(3), feraiseexcept(3), fesetexceptflag(3), fetestexcept(3) - fegetround(3), fesetround(3) - fegetenv(3), feholdexcept(3), fesetenv(3), feupdateenv(3) Reviewed by: standards@
* Add an fenv.h implementation for the sparc64 port.das2004-06-062-0/+280
| | | | Reviewed by: standards@
* Add an fenv.h implementation for the powerpc port.das2004-06-062-0/+282
| | | | Reviewed by: standards@
* Add an fenv.h implementation for the ia64 port.das2004-06-062-0/+280
| | | | Reviewed by: standards@
* Add an fenv.h implementation for the i386 port.das2004-06-062-0/+263
| | | | Reviewed by: standards@
* Add an fenv.h implementation for the arm port.das2004-06-062-0/+230
| | | | | | | | It does not appear to be possible to cross-build arm from i386 at the moment, and I have no ARM hardware anyway. Thus, I'm sure there are bugs. I will gladly fix these when the arm port is more mature. Reviewed by: standards@
* Add an fenv.h implementation for the amd64 port.das2004-06-062-0/+333
| | | | Reviewed by: standards@
* Add an fenv.h implementation for the alpha port. All of the standarddas2004-06-062-0/+315
| | | | | | | | | | | | | | features appear to work, subject to the caveat that you tell gcc you want standard rather than recklessly fast behavior (-mieee-with-inexact -mfp-rounding-mode=d). The non-standard feature of delivering a SIGFPE when an application raises an unmasked exception does not work, presumably due to a kernel bug. This isn't so bad given that floating-point exceptions on the Alpha architecture are not precise, so making them useful in userland requires a significant amount of wizardry. Reviewed by: standards@
* Pointy hat: We can't avoid a chown() call without checking both UIDkientzle2004-06-051-1/+5
| | | | and GID. Suppress a premature attempt at optimization.
* YAPHtM: Yet Another Pointy Hat to Me.kientzle2004-06-051-1/+1
| | | | | After calculating new dir permissions that allow creating files, don't be stupid and use the original permissions. <sigh>
* Recognize when we've accidentally created "foo/."kientzle2004-06-051-0/+12
| | | | and don't complain about it.
* Correctly reset archive_read_data state everytime a header is read.kientzle2004-06-041-0/+5
|
* Correct the layering violation in read_body_to_string. The previouskientzle2004-06-041-17/+24
| | | | | | | | | | | | | | | version called the higher-level archive_read_data and archive_read_data_skip functions, which screwed up state management of those functions. This bit of mis-design has existed for a long time, but became a serious issue with the recent changes to the archive_read_data APIs, which added more internal state to the high-level archive_read_data function. Most common symptom was a failure to correctly read 'L' entries (long filename) from GNU-style archives, causing the message ": Can't open: No such file or directory" with an empty filename. Pointed out by: Numerous port build failures Thanks to: Kris Kennaway
* Handle read_block() failures by ignoring the disk rather thanbrian2004-06-044-10/+34
| | | | dumping core.
* When we go to read the next tar header, if we get zero bytes, acceptkientzle2004-06-041-3/+22
| | | | | | | | | | | | | that as end-of-archive. Otherwise, a short read at this point generates an error. This accomodates broken tar writers (such as the one apparently in use at AT&T Labs) that don't even write a single end-of-archive block. Note that both star and pdtar behave this way as well. In contrast, gtar doesn't complain in either case, and as a result, will generate no warning for a lot of trashed archives. Pointed out by: shells/ksh93 port (Thanks to Kris Kennaway)
* Be more careful about the initial read (used for "tasting" the compression):kientzle2004-06-041-1/+12
| | | | | * Check for and return input errors * Treat empty file (zero-length read) as a fatal error
* Refactor the extraction code somewhat. In particular,kientzle2004-06-034-120/+105
| | | | | | | | | | push extract data down into archive_read_extract.c and out of the library-global archive_private.h; push dir-specific mode/time fixup down into dir restore function; now that the fixup list is file-local, I can use somewhat more natural naming. Oh, yeah, update a bunch of comments to match current reality.
* Add __BEGIN_DECLS / __END_DECLS so this can be used in C++ code.des2004-06-031-0/+4
| | | | MFC after: 1 week
* Fix the ordering in the description of the dlsym() lookup procedure toroam2004-06-031-4/+4
| | | | | | | | reflect src/libexec/rtld-elf/rtld.c rev. 1.68 - the globally-loaded objects (RTLD_GLOBAL) are searched before the local object's DAG's. PR: 62770 Submitted by: Kimura Fuyuki <fuyuki@nigredo.org>
* Fixed lots of 1 ULP errors caused by a broken approximation for pi/2.bde2004-06-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | We approximate pi with more than float precision using pi_hi+pi_lo in the usual way (pi_hi is actually spelled pi in the source code), and expect (float)0.5*pi_lo to give the low part of the corresponding approximation for pi/2. However, the high part for pi/2 (pi_o_2) is rounded to nearest, which happens to round up, while the high part for pi was rounded down. Thus pi_o_2+(float)0.5*pi (in infinite precision) was a very bad approximation for pi/2 -- the low term has the wrong sign and increases the error drom less than half an ULP to a full ULP. This fix rounds up instead of down for pi_hi. Consistently rounding down instead of up should work, and is the method used in e_acosf.c and e_asinf.c. The reason for the difference is that we sometimes want to return precisely pi/2 in e_atan2f.c, so it is convenient to have a correctly rounded (to nearest) value for pi/2 in a variable. a_acosf.c and e_asinf.c also differ in directly approximating pi/2 instead pi; they multiply by 2.0 instead of dividing by 0.5 to convert the approximation. These complications are not directly visible in the double precision versions because rounding to nearest happens to round down.
* Add MLINKS for new API functions.kientzle2004-06-022-4/+6
|
* Refactor read_data:kientzle2004-06-028-131/+300
| | | | | | | | | | | * New read_data_block is both sparse-file aware and uses zero-copy semantics * Push read_data_block down into specific formats (opens door to various encoded entry bodies, such as zip or gtar -S) * Reimplement read_data, read_data_skip, read_data_into_fd in terms of new read_data_block. * Update documentation It's unfortunate that I couldn't just call the new interface archive_read_data, but didn't want to upset the API that much.
* use source address as a hint to determine destination addressume2004-06-021-50/+361
| | | | by getipnodebyname().
* Port a bugfix from FDLIBM 5.3. The bug really only applies to tan()das2004-06-021-8/+24
| | | | | | | | | | | | and not tanf() because float type can't represent numbers large enough to trigger the problem. However, there seems to be a precedent that the float versions of the fdlibm routines should mirror their double counterparts. Also update to the FDLIBM 5.3 license. Obtained from: FDLIBM Reviewed by: exhaustive comparison
* Merge a bugfix from FDLIBM 5.3 to ensure that the error in tan()das2004-06-021-10/+24
| | | | | | is always less than 1 ulp. Also update to the 5.3 license. Obtained from: FDLIBM
* Distinguish cases when ncp module not loaded and when module have oldbp2004-06-021-1/+4
| | | | interface.
* Merged from double precision case (e_pow.c 1.10: sign fixes).bde2004-06-011-13/+14
|
* Add Aerospace Corporation copyrights to EUI64 support files.brooks2004-06-012-0/+52
| | | | Suggested by: marcel, imp
* Fixed the sign of the result in some overflow and underflow cases (onesbde2004-06-011-17/+18
| | | | | | | | | | | | | | | where the exponent is an odd integer and the base is negative). Obtained from: fdlibm-5.3 Sun finally released a new version of fdlibm just a coupe of weeks ago. It only fixes 3 bugs (this one, another one in pow() that we already have (rev.1.9), and one in tan(). I've learned too much about powf() lately, so this fix was easy to merge. The patch is not verbatim, because our base version has many differences for portability and I didn't like global renaming of an unrelated variable to keep it separate from the sign variable. This patch uses a new variable named sn for the sign.
* Fixed another precision bug in powf(). This one is in the computationbde2004-06-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | [t=p_l+p_h High]. We multiply t by lg2_h, and want the result to be exact. For the bogus float case of the high-low decomposition trick, we normally discard the lowest 12 bits of the fraction for the high part, keeping 12 bits of precision. That was used for t here, but it doesnt't work because for some reason we only discard the lowest 9 bits in the fraction for lg2_h. Discard another 3 bits of the fraction for t to compensate. This bug gave wrong results like: powf(0.9999999, -2.9999995) = 1.0000002 (should be 1.0000001) hex values: 3F7FFFFF C03FFFFE 3F800002 3F800001 As explained in the log for the previous commit, the bug is normally masked by doing float calculations in extra precision on i386's, but is easily detected by ucbtest on systems that don't have accidental extra precision. This completes fixing all the bugs in powf() that were routinely found by ucbtest.
* Fixed 2 bugs in the computation /* t_h=ax+bp[k] High */.bde2004-06-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (1) The bit for the 1.0 part of bp[k] was right shifted by 4. This seems to have been caused by a typo in converting e_pow.c to e_powf.c. (2) The lower 12 bits of ax+bp[k] were not discarded, so t_h was actually plain ax+bp[k]. This seems to have been caused by a logic error in the conversion. These bugs gave wrong results like: powf(-1.1, 101.0) = -15158.703 (should be -15158.707) hex values: BF8CCCCD 42CA0000 C66CDAD0 C66CDAD4 Fixing (1) gives a result wrong in the opposite direction (hex C66CDAD8), and fixing (2) gives the correct result. ucbtest has been reporting this particular wrong result on i386 systems with unpatched libraries for 9 years. I finally figured out the extent of the bugs. On i386's they are normally hidden by extra precision. We use the trick of representing floats as a sum of 2 floats (one much smaller) to get extra precision in intermediate calculations without explicitly using more than float precision. This trick is just a pessimization when extra precision is available naturally (as it always is when dealing with IEEE single precision, so the float precision part of the library is mostly misimplemented). (1) and (2) break the trick in different ways, except on i386's it turns out that the intermediate calculations are done in enough precision to mask both the bugs and the limited precision of the float variables (as far as ucbtest can check). ucbtest detects the bugs because it forces float precision, but this is not a normal mode of operation so the bug normally has little effect on i386's. On systems that do float arithmetic in float precision, e.g., amd64's, there is no accidental extra precision and the bugs just give wrong results.
OpenPOWER on IntegriCloud