summaryrefslogtreecommitdiffstats
path: root/lib/libc
Commit message (Collapse)AuthorAgeFilesLines
* Make a couple of the stat flags dependent on the sys/stat.h header filejb1998-01-093-3/+27
| | | | | | | | | | | that this source is compiled against. This source is referenced by install which is needed as a build tool and must be able to compile against NetBSD headers and libraries if we have a hope of supporting another architecture. With this change, that's two working programs down and 3945 (?) to go. The other one was make, but that didn't need any changes to work under FreeBSD/Alpha. 8-)
* handle long usernames more carefullyimp1998-01-071-5/+8
| | | | | Reviewed by: guido Obtained from: OpenBSD (Theo de Raadt)
* Convert to mdoc format.charnier1998-01-051-248/+146
|
* size_t -> unsignedache1998-01-041-3/+3
| | | | | in arguments length INT_MAX overflow check Suggested-by: bde
* Expanded cross references.alex1998-01-029-8/+20
|
* 1. EOF was returned when the buffer size was larger than INT_MAX. Thisache1998-01-012-10/+10
| | | | | | | | | | case has very little to do with the output size being larger than INT_MAX. 2. The new #include of <limits.h> was disordered. 3. The new declaration of `on' was disordered (integer types go together). 4. Testing an unsigned value for > 0 was fishy. Submitted by: bde
* Drop the use of caddr_t in conjunction with mmap(2).alex1997-12-311-4/+4
|
* Convert caddr_t --> void * for sys/mman.h functions.alex1997-12-319-16/+16
| | | | | | | | | | | | | | | | mlock, mmap, mprotect, msync, munlock, and munmap are defined by POSIX as taking void *. The const modifier has been added to mlock, munlock, and mprotect as the standard dictates. minherit comes from OpenBSD and has been updated to conform with their recent change to void *. madvise and mincore are not defined by POSIX, but their arguments have been modified to be consistent with the POSIX-defined functions. mincore takes a const pointer, but madvise does not due to the MADV_FREE case. Discussed with: bde
* Fixed formatting of the MADV_FREE flag description.alex1997-12-301-3/+3
| | | | Pointed out by: bde
* Typo fix.alex1997-12-301-2/+2
|
* Document MS_SYNC.alex1997-12-301-0/+1
|
* The terminating character in strings is `NUL', not `NULL'.wosch1997-12-282-2/+2
|
* fork() checks RLIMIT_NPROC, not RLIMIT_NOFILE.hoek1997-12-261-1/+1
| | | | | pr: docs/5260 submitted-by: Niall Smart [3]njs3@doc.ic.ac.uk
* Removed unnecessary initialization of hp in gethostbyaddr_r.alex1997-12-251-3/+3
|
* Add overflow checks: if output size becomes bigger than INT_MAX,ache1997-12-251-2/+13
| | | | just return EOF
* Correct type of stored argument place (from previous fix)ache1997-12-242-4/+4
|
* 1) Restore back comment about snprintf()ache1997-12-241-7/+10
| | | | | 2) Optimize string buffer copy to call memcpy() and update pointers only for count > 0, it makes snprintf(NULL, 0, ...) more efficient
* Return back to BSD snprintf semantics which recent C9x standard adoptsache1997-12-243-21/+23
| | | | | | | | | | instead of Singe Unix, thanx Bruce for explaining, I am not realize standards war was there. But now, fix n == 0 case to not return error and fix check for too big n. Things left to do: check for overflow in arguments.
* 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
OpenPOWER on IntegriCloud