"Garrett D'Amore" <gdamore at Sun.COM> wrote:
> Differences in libucb implementation
> ------------------------------------
>
> nlist() - UCB has local implementation supporting COFF (a.out). This
> one we would have to continue to provide for legacy apps.
Note: COFF is not a.out.
> readdir() - Different implementations, but apparently identical
> semantics and structures. Could probably be eliminated.
You can elimitate the UCB version only if you do the same as has been done
on *BSD: include d_namelen in the syscall and fill it from kernel VFS level.
USB struct dirent has d_namelen that is missing in the POSIX version.
Otherwise, you need to at least call strlen(d_name) to set up d_namelen.
> scandir()
> alphasort() - Nearly identical implementations, and identical semantics.
> Could be eliminated.
See above: struct dirent differs
> setbuffer()
> setlinebuf() - UCB mucks in internals of libc stdio (urk!) libc just
> uses
> setvbuf(). This should almost certainly be eliminated, as
> nothing should be mucking around inside the internals of
> libc stdio structures. Semantically identical. (Note
> UCB version seems to have inlined copy of setvbuf code.)
This may be a result from a different sprintf() implementation to allow to
get the buffer string.
> wait3() - Both are just simple wrappers around wait3. Can
> be eliminated.
They did differ for SunOS-5.0
> setpgrp() - Different calling conventions, we have to retain it. The
> UCB version is a trivial wrapper around setpgid.
Don't forget getpgrp()
>From bsh/bshconf.h:
* BSD:
*
* getpgrp(pid) -> pgid for pid
* setpgrp(pid, pgid) -> set pgid of pid
*
* POSIX:
*
* getpgid(pid) -> pgid for pid
* setpgid(pid, pgid) -> set pgid of pid
* getpgrp(void) -> pgid for $$
* setpgrp(void) -> setpgid(0,0)
*
* 4.4-BSD:
*
* getpgid(pid) -> is missing!
* setpgid(pid, pgid) -> set pgid of pid
* getpgrp(void) -> ????
* setpgrp(pid, pgid) -> set pgid of pid
> fopen() - UCB is functionally and semantically equivalent to libc.
> Could be removed.
Except for probably different FILE *, did you check this?
> freopen() - Identical, except for libc XPG6 semantics that *might* be
> applied, optionally (and not relevant to legacy apps.)
> Also, libc is thread safe. UCB version could be removed.
>
> fopen64() - Huh? Another weird 64-bitified API that should never
> have happened and was never publicised. It should be safe
> to remove this.
Maybe a Sun UCB utility has been made large file aware?
> fprintf()
> printf()
> vfprintf()
> vprintf() - These are standards-conformat APIs. They should just work.
> The libc versions benefit from being MT async safe. The
> main other difference bewing that the libc version has some
> support for additional format specifiers. ("ll", "Q",
> "hh"). libc can also support wide characters.
> We can probably safely remove the UCB versions.
>
> vsprintf()
> sprintf() - Semantically identical, the UCB version can be removed.
Be careful, David Korn ans I do not have own printf() iplementations to grant
100% portability. There may be problems if you let a UCB program use the POSIX
implementation.
Note: UCB sprintf() returns char * instead of int.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
