of the C++ stdlib. Our ctype.h uses symbols of the form _<X> to denote the
various character classes. Our ctype.h also extends the usual ctype.h
offering by adding the "_T" (special) class. Problem is parts of the STL
also use the symbol "_T" as its parameterized type. These two uses are
incompatible.
Thus change the form of the symbols used in ctype to something that fixes
the current problem and is less likely to cause conflicts in the future.
Requested by: Tomoaki NISHIYAMA <tomoaki@biol.s.u-tokyo.ac.jp>
Ok'ed by: JKH
just use _foo() <-- foo(). In the case of a libpthread that doesn't do
call conversion (such as linuxthreads and our upcoming libpthread), this
is adequate. In the case of libc_r, we still need three names, which are
now _thread_sys_foo() <-- _foo() <-- foo().
Convert all internal libc usage of: aio_suspend(), close(), fsync(), msync(),
nanosleep(), open(), fcntl(), read(), and write() to _foo() instead of foo().
Remove all internal libc usage of: creat(), pause(), sleep(), system(),
tcdrain(), wait(), and waitpid().
Make thread cancellation fully POSIX-compliant.
Suggested by: deischen
points. For library functions, the pattern is __sleep() <--
_libc_sleep() <-- sleep(). The arrows represent weak aliases. For
system calls, the pattern is _read() <-- _libc_read() <-- read().
else, it is equivalent to strdup(). So, we will check if the substitution
tables are trivial at the load time, and possibly save 2 calls to
__collate_substitute() in strcoll().
Still, __collate_substitute() should not exist.
Other minor optimizations. I got ~30% speedup in strcoll() for 50 char strings,
~40% speedup for 100 char strings, and unmeasurable speedup for 1M strings.
Collates are still terribly slow. To make them reasonable fast,
__collate_substitute() should be killed.
track.
The $Id$ line is normally at the bottom of the main comment block in the
man page, separated from the rest of the manpage by an empty comment,
like so;
.\" $Id$
.\"
If the immediately preceding comment is a @(#) format ID marker than the
the $Id$ will line up underneath it with no intervening blank lines.
Otherwise, an additional blank line is inserted.
Approved by: bde
Submitted by: Yung-Jen Hung <winard@u3717a.dorm.ccu.edu.tw>
Reviewed by: bearscorp.bbs@bbs.life.nthu.edu.tw
_BIG5_sgetrune() in libc doesn't work well, this commit will fix it.
o use braces to avoid potentially ambiguous else
o don't default to type int (and also remove a useless register
modifier).
o Use parens around assignment values used as truth values.
o Remove unused function.
Reviewed by: obrien and chuckr
In some cases replace if (a == null) a = malloc(x); else a =
realloc(a, x); with simple reallocf(a, x). Per ANSI-C, this is
guaranteed to be the same thing.
I've been running these on my system here w/o ill effects for some
time. However, the CTM-express is at part 6 of 34 for the CAM
changes, so I've not been able to do a build world with the CAM in the
tree with these changes. Shouldn't impact anything, but...
the diff is attached below. This is done on the 3.0 source-tree.
I have test this on 2.2-stable before, but I don't have a 3.0 machine
right now.
This patch is mainly to make libc support BIG5 encoding, thus add
zh_TW.BIG5 locale to 3.0.
Submitted by: Chen Hsiung Chan <frankch@waru.life.nthu.edu.tw>
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
@
