summaryrefslogtreecommitdiffstats
path: root/lib/libc
Commit message (Collapse)AuthorAgeFilesLines
* 1) Oops! Insert again if (n == 0) return 0.ache1997-12-242-10/+10
| | | | | | | | | | | | | | | | | | | Final word is Bruce's quote: C9x specifies the BSD4.4-Lite behaviour: [#3] ... Thus, the null-terminated output has been completely written if and only if the returned value is less than n. It means that if we not have any null-terminated output as for n == 0 we can't return value less than n, so we forced to return value equal to n i.e. 0 The next good thing is glibc compatibility, of course. 2) Do check for too big n in machine-independent way. 3) Minor optimization assuming EOF is < 0
* Back out part related to "return 0 if n == 0" and return EOF as before.ache1997-12-242-6/+2
| | | | | | | | | | | The main argument is that it is impossible to determine if %n evaluated or not when snprintf return 0, because it can happens for both n == 0 and n == 1. Although EOF here is good indication of the end of process, if n is decreased in the loop... Since it is already supposed in many places that EOF *is* negative, f.e. from Single Unix specs for snprintf "return ... a negative value if an output error was encountered" this not makes situation worse.
* Fix snprintf(...%n...)ache1997-12-241-5/+9
| | | | | | to pass not more than buffer size to %n agrument, old variant always assume infinite buffer. %n is for actually transmitted characters, not for planned ones.
* Remove wrong comment about snprintf:ache1997-12-241-5/+4
| | | | | | | | | "return the number of bytes needed, rather the number used" According to Single Unix specs: Upon successful completion, these functions return the number of bytes transmitted excluding the terminating null
* snprintf return value fixes to conform Single Unix specs:ache1997-12-242-6/+16
| | | | | | | | | | | | | | | | | | | | 1) if buffer size is smaller than arguments size, return buffer size, not arguments size as before. 2) if buffer size is 0, return 0, not EOF as before. (now it is compatible with Linux and Apache implementations too). NOTE: Single Unix specs says: If the value of n {buffer size} is zero on a call to snprintf(), an unspecified value less than 1 is returned. It means we can't return EOF since EOF can take *any* value in general not especially < 1. Better variant will be return -1 (it is less then 1 and different with n == 1 case) but -1 value is already occuped by EOF in our implementation, so we can't distinguish true IO error in that case. So 0 here is only possible case still conforming to Single Unix specs.
* Comment that long double is poorly implemented, not that it is unimplemented.bde1997-12-191-2/+3
|
* Put the .PATH statement first as in all other libc Makefile.inc's.bde1997-12-191-3/+2
|
* Format the MLINKS statement the same as in most other libc Makefile.inc's.bde1997-12-191-2/+3
|
* Fix recursion problem which occurs when a signal is received duringjb1997-12-151-3/+12
| | | | | | | a malloc. The signal handler creates a thread which requires a malloc... For now, the only thing to do is to block signals. When we move user pthreads to use the kernel threads, mutexes will be implemented in kernel space and then malloc can revert.
* Fixed spelling of EACCES.bde1997-11-235-12/+19
|
* Fixed long double formats. They were mostly not implemented exceptbde1997-11-231-4/+7
| | | | | | | | | | | on systems where long doubles are just doubles. FreeBSD hasn't been such a system since it started using gcc-2.5 many years ago. The fix is of low quality. It loses precision. scanf() of long doubles doesn't seem to be used much, but gdb-4.16 uses %Lg format in its expression parser if it thinks that the system supports printf'ing of long doubles. The symptom was that floating point literals were usually interpreted to be 0.0.
* Fix bit-twiddling in sigismember(3).jraynard1997-11-211-1/+1
| | | | | | | | Note this ONLY affects the function version - the macro version is always used unless for some reason you put #undef sigismember in your code before calling it. PR: 3615 Submitted by: Nanbor Wang <nw1@cs.wustl.edu> (slightly amended patch)
* Don't check for the unlikely case of useconds == 0 here. The kernelbde1997-11-201-7/+4
| | | | | | checks it. Fixed a style bug.
* stat() the correct file in execvp() so that the fine tuned errno handlingbde1997-11-201-2/+2
| | | | actually works.
* Add cross-references to rfork(2).jdp1997-11-182-1/+3
|
* Close PR #4867: improve _listmatch() to avoid returning false positives.wpaul1997-11-161-9/+16
| | | | PR: 4867
* Reviewed by: hackers@freebsd.org in generaljulian1997-11-132-1/+32
| | | | | | | | | | | | | Obtained from: Whistle Communications tree Add an option to the way UFS works dependent on the SUID bit of directories This changes makes things a whole lot simpler on systems running as fileservers for PCs and MACS. to enable the new code you must 1/ enable option SUIDDIR on the kernel. 2/ mount the filesystem with option suiddir. hopefully this makes it difficult enough for people to do this accidentally. see the new chmod(2) man page for detailed info.
* Reviewed by: various.julian1997-11-121-3/+2
| | | | | | | | | | | | | | | | Ever since I first say the way the mount flags were used I've hated the fact that modes, and events, internal and exported, and short-term and long term flags are all thrown together. Finally it's annoyed me enough.. This patch to the entire FreeBSD tree adds a second mount flag word to the mount struct. it is not exported to userspace. I have moved some of the non exported flags over to this word. this means that we now have 8 free bits in the mount flags. There are another two that might well move over, but which I'm not sure about. The only user visible change would have been in pstat -v, except that davidg has disabled it anyhow. I'd still like to move the state flags and the 'command' flags apart from each other.. e.g. MNT_FORCE really doesn't have the same semantics as MNT_RDONLY, but that's left for another day.
* Describe MNT_NOCLUSTER{R,W} flags.kato1997-11-091-0/+4
| | | | Pointed out by: bde
* changed prototype to match textjmg1997-11-051-8/+4
| | | | | changed sysctl to lsvfs as "sysctl vfs" doesn't return a listing of possible filesystem names
* Correct description of which runes are encoded as two bytes.steve1997-11-052-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PR: 4555 Submitted by: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> [0x0400 - 0xffff] [bbbbbbbb.bbbbbbbb] -> 1110bbbb, 10bbbbbb, 10bbbbbb .Ed .Pp If more than a single representation of a value exists (for example, 0x00; 0xC0 0x80; 0xE0 0x80 0x80) the shortest representation is always used (but the longer ones will be correctly decoded). .Pp The final three encodings provided by X-Open: .Bd -literal [00000000.000bbbbb.bbbbbbbb.bbbbbbbb] -> 11110bbb, 10bbbbbb, 10bbbbbb, 10bbbbbb [000000bb.bbbbbbbb.bbbbbbbb.bbbbbbbb] -> 111110bb, 10bbbbbb, 10bbbbbb, 10bbbbbb, 10bbbbbb [0bbbbbbb.bbbbbbbb.bbbbbbbb.bbbbbbbb] -> 1111110b, 10bbbbbb, 10bbbbbb, 10bbbbbb, 10bbbbbb, 10bbbbbb .Ed .Pp which provides for the entire proposed ISO-10646 31 bit standard are currently not implemented. .Sh "SEE ALSO" .Xr mklocale 1 , .Xr setlocale 3 @ 1.4 log @Don't use hardcoded *roff font change requests. Do it via mdoc macros instead. @ text @d37 1 a37 1 .Dd "June 4, 1993" @ 1.3 log @Very minor mdoc cleanup. @ text @d44 2 a45 1 \fBENCODING "UTF2"\fP @ 1.2 log @Another round of various man page cleanups. @ text @d65 1 a65 1 .sp d81 1 a81 1 .sp @ 1.2.2.1 log @YAMFC: Commit all of the -current changes that apply to 2.2. These fall into several categories: - Cosmetic/mdoc changes. They don't really afect the output at all, but having them in 2.2 will make it easier to diff the man pages later when looking for real changes. - Update some man pages to reflect the current 2.2 header files. - Sort xrefs. - A few typo fixes. - And a few changes that actualy added text to the man page that should be reflected in 2.2. - Add some missing MLINKS. Requested by: bde @ text @d44 1 a44 2 .Nm ENCODING .Qq UTF2 d65 1 a65 1 .Pp d81 1 a81 1 .Pp @ 1.2.2.2 log @MFC: Just the locale fixes (small doc tweaks for the most part) and the new strptime(3) call. Having added something, does this require a version bump? Haven't we bumped once already? There are a *LOT* of additional 3.0 changes to be merged but I'm not entirely comfortable with some of them so I'll take the conservative (read: cowardly :) way out and just merge this much. @ text @d37 1 a37 1 .Dd June 4, 1993 @ 1.1 log @Initial revision @ text @d41 1 a41 1 .Nm UTF2 @ 1.1.1.1 log @BSD 4.4 Lite Lib Sources @ text @@ 1.1.1.1.6.1 log @Phase 2 of merge - also fix things broken in phase 1. Watch out for falling rock until phase 3 is over! libc completely merged except for phkmalloc & rfork (don't know if David wants that). Some include files in sys/ had to be updated in order to bring in libc. @ text @d41 1 a41 1 .Nm utf2 @ 1.1.1.1.6.2 log @This 3rd mega-commit should hopefully bring us back to where we were. I can get it to `make world' succesfully, anyway! @ text @d41 1 a41 1 .Nm UTF2 @
* In clntudp_call(), it is possible that xdr_replymsg() might failwpaul1997-10-261-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | partway through its attempt to decode the result structure sent by the server. If this happens, it can leave the result partially populated with dynamically allocated memory. In this event, the xdr_replymsg() failure is detected and RPC_CANTDECODERES is returned, but the memory in the partially populated result struct is not free()d. The end result is that memory is leaked when an RPC_CANTDECODERES error occurs. (This condition can occur if a CLIENT * handle is created using clntudp_bufcreate() with a receive buffer size that is too small to handle the result sent by the server.) Fixed by setting reply_xdrs.x_op to XDR_FREE and calling xdr_replymsg() again to free the memory if an RPC_CANTDECODERES error is detected. I suspect that the clnt_tcp.c, clnt_unix.c and clnt_raw.c modules may ha a similar problem, but I haven't duplicated the condition with those yet. Found by: dbmalloc
* Typo.helbig1997-10-261-1/+1
|
* Change L_SET to SEEK_SET for POSIX compliance.jdp1997-10-261-1/+1
| | | | Submitted by: Dean Gaudet <dgaudet@arctic.org>
* Back out part of OpenGroup specs about limiting max arg since it may breakache1997-10-222-17/+4
| | | | compatibility.
* Reflect usleep code changes:ache1997-10-221-1/+24
| | | | | Limit max arg Change return type to int
* Changes in spirit of OpenGroup Singe Unix specs:ache1997-10-221-5/+11
| | | | | | 1) Limit max allowed argument to 1000000 2) Change return type from void to int to indicate premature termination (by signal)
* Document EINVAL as a possible return value from open(2).joerg1997-10-221-0/+7
|
* Sorted lists.bde1997-10-2111-144/+146
|
* Removed unused file. It just forces a return value of 0 on successbde1997-10-181-48/+0
| | | | | (no carry), but mount() in the kernel has returned 0 on success since prehistoric times.
* Add $Idache1997-10-171-0/+4
|
* Fix LONG_MAX overflowingache1997-10-171-10/+21
| | | | | | Return seconds if errno other than EINTR Add $Id Submitted by: bde with minor optimization by me
* Fix two bugs which caused various RPC programs (mountd, nfsd, ...)jdp1997-10-171-3/+3
| | | | | | | | | | | | | | | to fail under certain circumstances. 1. In one spot, the ifr_flags member was being examined in the wrong structure, thus it contained garbage. On a machine in which only the loopback interface was up, this caused everything that wanted to talk to the portmapper to fail -- a particular problem with laptops, where the pccard ethernet interface is likely to come up long after the attempt to start mountd, nfsd, amd, etc. 2. Compounding the above problem, get_myaddress() returned a successful status even though it failed to find an address that it considered good enough.
* Copy time_to_sleep to time_remaining since it can be leftache1997-10-161-0/+1
| | | | uninitialized if nanosleep returns early with agr error
* Handle machine-dependent (stdlib) sources more automatically.bde1997-10-162-4/+4
| | | | | | | This fixes bugs in the manual handling. abs.[cS] was handled too specially and the wrong (.c) variant for each of div.[cS], labs.[cS] and ldiv.[cS] was added to SRCS. This caused the .c variant to be used if `depend' was made and the .S version to be used otherwise.
* Removed bogus .PATH statement.bde1997-10-162-6/+2
|
* Removed the subdirectory paths from the definitions of MAN[1-9]. Theybde1997-10-163-10/+7
| | | | | were a workaround for limitations in bsd.man.mk that were fixed about 2 years ago.
* Handle machine-dependent (m-d) (string) sources more automatically.bde1997-10-163-80/+23
| | | | | | | | | | | | | | | | | | | | | The names of m-d variants are now added (manually) to MDSRCS instead of to SRCS, and the names of all machine-independent (m-i) variants that can reasonably be replaced by an m-d variant are now added (manually) to MISRCS instead of to SRCS, so that a simple substitution can be used to discard the unused m-i variants. MISRCS is potentially all m-i sources, but the substitution is too simple to be fast, so MISRCS should be kept reasonably small. libc/Makefile.inc: Do the substitution. libc/i386/string/Makefile.inc: Add to MDSRCS instead of to SRCS. Add the names of all sources in this directory, but no others. libc/string/Makefile.inc Add to MISRCS instead of to SRCS. Add the names of all sources in this directory. Don't use (broken) explicit rules for special cases.
* Reflect current sleep/usleep implementations stateache1997-10-162-9/+5
|
* Cleanup #includesache1997-10-162-5/+2
|
* Proper spacing in the Synopsis.max1997-10-161-2/+2
|
* Include the machine-dependent Makefile.inc for sys in the correct place.bde1997-10-152-3/+4
|
* Removed the subdirectory paths from the definitions of MAN[1-9]. Theybde1997-10-1514-132/+87
| | | | | were a workaround for limitations in bsd.man.mk that were fixed about 2 years ago.
* Added some 2-line source files to get a direct correspondencebde1997-10-155-0/+10
| | | | | between sources and objects. This will be used to avoid messy special cases in Makefile.inc.
* Remove old SIGALRM absorbing back-compat code. It wasn't working at allpeter1997-10-151-83/+1
| | | | | | | | | | | | | for the entire time that it was there, so obviously nothing needs it anymore. Note, unix98/single-unix spec v2 says that usleep() returns an int rather than a void, to indicate whether the entire time period elapsed (0) or an error (eg: signal handler) interrupted it (returns -1, errno = EINTR) It is probably useful to make this change but I'll test it locally first to see if this will break userland programs [much]... Reviewed by: ache, bde
* Give up on the "try and compensate for broken programs" cruft and revertpeter1997-10-151-70/+0
| | | | | | | | | | | | | back to the original single nanosleep() implementation. This is POSIX and Unix98 (aka single-unix spec v2) compliant behavior. If a program sets alarm(2) or an interval timer (setitimer(2)) without a SIGALRM handler being active, sleep(3) will no longer absorb it, and the program will get what it asked for..... :-] The original reason for this in the first place (apache) doesn't seem to need it anymore, according to Andrey. Reviewed by: ache, bde
* Correct a bug in the 'allow arbitrary number of socket descriptors' changeswpaul1997-10-141-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | made to the RPC code some months ago. The value of __svc_fdsetsize is being calculated incorrectly. Logically, one would assume that __svc_fdsetsize is being used as a substitute for FD_SETSIZE, with the difference being that __svc_fdsetsize can be expanded on the fly to accomodate more descriptors if need be. There are two problems: first, __svc_fdsetsize is not initialized to 0. Second, __svc_fdsetsize is being calculated in svc.c:xprt_registere() as: __svc_fdsetsize = howmany(sock+1, NFDBITS); This is wrong. If we are adding a socket with index value 4 to the descriptor set, then __svc_fdsetsize will be 1 (since fds_bits is an unsigned long, it can support any descriptor from 0 to 31, so we only need one of them). In order for this to make sense with the rest of the code though, it should be: __svc_fdsetsize = howmany(sock+1, NFDBITS) * NFDBITS; Now if sock == 4, __svc_fdsetsize will be 32. This bug causes 2 errors to occur. First, in xprt_register(), it causes the __svc_fdset descriptor array to be freed and reallocated unnecessarily. The code checks if it needs to expand the array using the test: if (sock + 1 > __svc_fdsetsize). The very first time through, __svc_fdsetsize is 0, which is fine: an array has to be allocated the first time out. However __svc_fdsetsize is incorrectly set to 1, so on the second time through, the test (sock + 1 > __svc_fdsetsize) will still succeed, and the __svc_fdset array will be destroyed and reallocated for no reason. Second, the code in svc_run.c:svc_run() can become hopelessly confused. The svc_run() routine malloc()s its own fd_set array using the value of __svc_fdsetsize to decide how much memory to allocate. Once the xprt_register() function expands the __svc_fdset array the first time, the value for __svc_fdsetsize becomes 2, which is too small: the resulting calculation causes the code to allocate an array that's only 32 bits wide when it actually needs 64 bits. It also uses the valuse of __svc_fdsetsize when copying the contents of the __svc_fdset array into the new array. The end result is that all but the first 32 file descriptors get lost. Note: from what I can tell, this bug originated in OpenBSD and was brought over to us when the code was merged. The bug is still there in the OpenBSD source. Total nervous breakdown averted by: Electric Fence 2.0.5
* Moved `SRCS+= frexp.c' to the correct Makefile.inc.bde1997-10-142-6/+6
| | | | Sorted SRCS.
* Moved `SRCS+= frexp.c' to the correct Makefile.inc.bde1997-10-141-2/+2
|
* Fixed searching of $PATH in execvp(). Do what sh(1) should do accordingbde1997-10-142-26/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | to POSIX.2. In particular: - don't retry for ETXTBSY. This matches what sh(1) does. The retry code was broken anyway. It only slept for several seconds for the first few retries. Then it retried without sleeping. - don't abort the search for errors related to the path prefix, in particular for ENAMETOOLONG, ENOTDIR, ELOOP. This fixes PR1487. sh(1) gets this wrong in the opposite direction by never aborting the search. - don't confuse EACCES for errors related to the path prefix with EACCES for errors related to the file. sh(1) gets this wrong. - don't return a stale errno when the search terminates normally without finding anything. The errno for the last unsuccessful execve() was usually returned. This gave too much precedence to pathologies in the last component of $PATH. This bug is irrelevant for sh(1). The implementation still uses the optimization/race-inhibitor of trying to execve() things first. POSIX.2 seems to require looking at file permissions using stat(). We now use stat() after execve() if execve() fails with an ambiguous error. Trying execve() first may actually be a pessimization, since failing execve()s are fundamentally a little slower than stat(), and are significantly slower when a file is found but has unsuitable permissions or points to an unsuitable interpreter. PR: 1487
OpenPOWER on IntegriCloud