1. use uintptr_t instead of u_long
2. check for overflow in map_pages and malloc_pages
3. bring in fixes from FreeBSD [int -> size_t, and a missing THREAD_UNLOCK]
4. rewrite map_pages to use sbrk() only to grow memory (avoids extra syscall
and elides bug in brk(2) that ross is fixing)
5. restore the break point to its original value if the mmap(2) for the page
directory or the alignment sbrk breaks.
reviewed by: chuq and ross
tested by: make build and reboot
Now memtest nearly works; unfortunately there is no way currently to lower
the break point as we free, so memtest keeps trying to reduce memory when
mlock() fails and that does not work.
to <sys/types.h> and <sys/stdint.h>.
* Add a new C99 <stdint.h> header, which provides integer types of
explicit width, related limits and integer constant macros.
* Extend <inttypes.h> to provide <stdint.h> definitions and format
macros for printf() and scanf().
* Add C99 strtoimax() and strtoumax() functions.
* Use the latter within scanf().
* Add C99 %j, %t and %z printf()/scanf() conversions for
intmax_t, pointer-type and size_t arguments.
shot-term TODO:
- enable multibyte locales. this includes loadable locale modules
(#ifdef DLRUNE).
- populate LC_CTYPE definition files.
- other functions such as iconv()
- make libc functions more friendly with multibyte.
- multilingualize other LC_xx
- torture tests
XXX don't forget to "make depend" when you rebuild libc, multibyte.c is
moved from lib/libc/stdlib to lib/libc/locale.
to 0 and have getopt(3)/getopt_long(3) continue to function properly.
This happens to work with GNU getopt_long(3), so mimmick the behavior.
Fixes pkg/10980 (Manuel Bouyer): rsyncd was relying on this behavior.
When complaining about a long option which requires an argument,
print the actual option, not some pointer-garbage.
(Hint: "%c" and "%s" are different.)
actually does something, this can be expensive. From discussion on
current-users.
Note that the man page is already correct - we imported malloc.c from
FreeBSD before they made the same change but malloc.3 after...