Mail Archives: djgpp-workers/1999/02/19/19:53:57
Michel de Ruiter wrote:
>
> Hi, there. I have found some minor buglets in djlsr202. A description
> is given for all of them, starting with a `#'. I haven't followed the
> workers-list too closely for the last months, so some things might
> have already been fixed.
> # Next, I noticed many, many non-ANSI functions in the src/libc/ansi/
> # directory and many non-POSIX functions in src/libc/posix/. I think
> # most are on purpose, but it might be confusing. Here are all those
> # cases, thanks to the new portability info. Comments?
>
> src/libc/ansi/ctype/isascii.txh:22:!ansi, !posix isascii()
> src/libc/ansi/ctype/toascii.txh:22:!ansi, !posix toascii()
> src/libc/ansi/math/acosh.txh:17:!ansi, !posix acosh()
> src/libc/ansi/math/asinh.txh:17:!ansi, !posix asinh()
> src/libc/ansi/math/atanh.txh:17:!ansi, !posix atanh()
> src/libc/ansi/math/hypot.txh:19:!ansi, !posix hypot()
> src/libc/ansi/math/modfl.txh:23:!ansi, !posix modfl()
> src/libc/ansi/math/pow10.txh:17:!ansi, !posix pow10()
> src/libc/ansi/math/pow2.txh:17:!ansi, !posix pow2()
> src/libc/ansi/stdio/doprnt.txh:24:!ansi, !posix _doprnt()
> src/libc/ansi/stdio/doscan.txh:25:!ansi, !posix _doscan()
> src/libc/ansi/stdio/fwalk.txh:21:!ansi, !posix _fwalk()
> src/libc/ansi/stdio/getw.txh:24:!ansi, !posix getw()
> src/libc/ansi/stdio/putw.txh:22:!ansi, !posix putw()
> src/libc/ansi/stdio/rename.txh:89:!ansi, !posix _rename()
> src/libc/ansi/stdio/setbuffe.txh:31:!ansi, !posix setbuffer()
> src/libc/ansi/stdio/setlineb.txh:29:!ansi, !posix setlinebuf()
> src/libc/ansi/stdlib/atold.txh:23:!ansi, !posix atold()
> src/libc/ansi/stdlib/llabs.txh:21:!ansi, !posix llabs()
> src/libc/ansi/stdlib/lldiv.txh:28:!ansi, !posix lldiv()
> src/libc/ansi/stdlib/strtold.txh:22:!ansi, !posix strtold()
> src/libc/ansi/stdlib/strtoll.txh:28:!ansi, !posix strtoll()
> src/libc/ansi/stdlib/strtoull.txh:21:!ansi, !posix strtoull()
> src/libc/ansi/string/syserrls.txh:17:!ansi, !posix sys_errlist
> src/libc/ansi/string/syserrls.txh:42:!ansi, !posix sys_nerr
> src/libc/ansi/time/ctime.txh:183:!ansi, posix tzset()
>
> src/libc/posix/dirent/seekdir.txh:24:!ansi, !posix seekdir()
> src/libc/posix/dirent/telldir.txh:22:!ansi, !posix telldir()
> src/libc/posix/fcntl/open.txh:169:!ansi, !posix __djgpp_share_flags
> src/libc/posix/grp/getgrent.txh:36:!ansi, !posix getgrent()
> src/libc/posix/grp/getgrent.txh:68:!ansi, !posix fgetgrent()
> src/libc/posix/grp/getgrent.txh:92:!ansi, !posix setgrent()
> src/libc/posix/grp/getgrent.txh:115:!ansi, !posix endgrent()
> src/libc/posix/pwd/pwent.txh:31:!ansi, !posix getpwent()
> src/libc/posix/pwd/pwent.txh:66:!ansi, !posix setpwent()
> src/libc/posix/pwd/pwent.txh:89:!ansi, !posix endpwent()
> src/libc/posix/signal/itimer.txh:22:!ansi, !posix getitimer()
> src/libc/posix/signal/itimer.txh:69:!ansi, !posix setitimer()
> src/libc/posix/sys/stat/djbits.txh:67:!ansi, !posix _djstat_flags
> src/libc/posix/sys/stat/djbits.txh:177:!ansi, !posix _djstat_fail_bits
> src/libc/posix/sys/stat/filelen.txh:23:!ansi, !posix filelength()
> src/libc/posix/sys/stat/fixpath.txh:37:!ansi, !posix _fixpath()
> src/libc/posix/sys/stat/is_exec.txh:45:!ansi, !posix _is_executable()
> src/libc/posix/sys/stat/st_loss.txh:51:!ansi, !posix
> _djstat_describe_lossage()
> src/libc/posix/sys/stat/xstat.txh:37:!ansi, !posix _invent_inode()
> src/libc/posix/termios/tminit.txh:21:!ansi, !posix
> __libc_termios_init()
> src/libc/posix/unistd/symlink.txh:42:!ansi, !posix symlink()
I think all of these are functions which are not themselves ANSI or
POSIX, but are related and hence belong with the others. i.e.
getw isn't ANSI, but reads from stdio streams, and so deserves to be
with other (ANSI) stdio stuff.
_doprnt is internal to all the *printf functions.
I think most of these fall into those categories. But this is a
question for DJ to answer finally. AFAIK, the standard-ness is correct
on these.
>
> # I then scanned for the reverse case: ANSI/POSIX functions in a
> # general directory. Maybe we should move (some of) them to
> # src/libc/(ansi|posix) ? Are they really all ANSI/POSIX?
> src/libc/go32/dpmiexcp.txh:22:ansi, posix raise()
> src/libc/go32/dpmiexcp.txh:250:ansi, posix signal()
Yes (is ANSI/POSIX). Signal stuff goes with other exception handling,
which is low-level DPMI code.
> src/libc/pc_hw/timer/clock.txh:22:ansi, posix clock()
Yes. Timer code is more PC hardware than anything else, whatever the
interface looks like.
> src/libc/ansi/time/ctime.txh:183:!ansi, posix tzset()
Yes. A refinement of ANSI time stuff (I think)
> src/libc/crt0/crt0.txh:142:!ansi, posix _exit()
Yes. ISTR a good reason why _exit has to be in crt0.o. It's in
assembler, and is linked with every program...
> src/libc/crt0/crt0.txh:169:!ansi, posix __exit()
> src/libc/dos/io/fmode.txh:20:!ansi, posix _fmode
No. These aren't POSIX. Oops.
>
> # I think that the following functions are neither ANSI nor POSIX. So
> # says include/netinet/in.h, so documentation fix follows... Does
> # anyone know why the portability info conflicted with the header
> # files?
Because I generated the portability docs by a kludgy automated process,
and didn't check the results well enough :) You are right, they're not
POSIX nor ANSI (AFAICT).
> src/libc/pc_hw/endian/htonl.txh:22:ansi, posix htonl()
> src/libc/pc_hw/endian/htons.txh:22:ansi, posix htons()
> src/libc/pc_hw/endian/ntohl.txh:22:ansi, posix ntohl()
> src/libc/pc_hw/endian/ntohs.txh:22:ansi, posix ntohs()
[snip]
> # Last, while doing this, I encountered the following documentation,
> # which suggests that `getdtablesize' is a POSIX function, but then
> # says it isn't. Which one is wrong?
>
> j:/contrib/djlsr202/src/libc/compat/unistd/getstubs.txh
> @node getdtablesize, posix
> ...
> @portability !ansi, !posix
It's not POSIX, according to my Unix man page. My bad, again.
Thanks for finding these.
--
Nate Eldredge
nate AT cartsys DOT com
- Raw text -