bt455s10@uhccux.uhcc.hawaii.edu (Carl "Art" McIntosh) (12/29/89)
I recently installed Larry Wall's fine program 'perl' on our NCR Tower 32/650
here at work, we are running NCR OS 2.01.00. The perl is version 3.0, patch-
level 8. The thing compiles fine, except for eval.c and teval.c which the
compiler can't optimize due to 'too many labels'. Anyhow, no sweat, the
executable runs fine, and who cares if 1 module wasn't optimized. When
I ran 'make test', all the tests were successful except for op.mkdir.
op.mkdir test 3 failed. Hmmmm.... I say, lets 'man 2 mkdir'. Not found.
The NCR programmers reference doesn't show hide nor hair of a mkdir().
Configure defined it in config.sh .... must have found it somewhere ....
now try ar -tv /lib/libc.a | fgrep mkdir. Lo and behold! mkdir.o is in
libc.a! How come this hummer isn't documented in the refs and no man page
exists for it ? Does it work ? main() { mkdir("foo") } sure does work,
guess we got a good mkdir. Anyone know why this one isn't documented,
and if it works like most mkdirs ? Any "special" args or returns I need
to worry about ? Why does op.mkdir test 3 fail ???mechjgh@texbell.swbt.com (12/31/89)
>>>>> On 29 Dec 89 00:16:57 GMT, Carl "Art" McIntosh <bt455s10@uhccux.uhcc.hawaii.edu> said:
Art> I recently installed Larry Wall's fine program 'perl' on our
Art> NCR Tower 32/650 here at work, we are running NCR OS 2.01.00.
Art> The perl is version 3.0, patch- level 8. The thing compiles
Art> fine, except for eval.c and teval.c which the compiler can't
Art> optimize due to 'too many labels'.
Add -W2,-Sl,2000 to the 'additional cc flags' perl 3.0 Configure
script question.
Art> now try ar -tv /lib/libc.a | fgrep mkdir.
Art> Lo and behold! mkdir.o is in libc.a!
Art> How come this hummer isn't documented in the refs and no man page
Art> exists for it ? Does it work ? main() { mkdir("foo") } sure
Art> does work, guess we got a good mkdir. Anyone know why this one
Art> isn't documented, and if it works like most mkdirs ? Any
Art> "special" args or returns I need to worry about ? Why does
Art> op.mkdir test 3 fail ???
The reason it's not documented is because it's broken. IMHO it
shouldn't have been there in the first place. Simply delete it, and
all the perl tests run just fine.
cd /lib;ar d libc.a mkdir.o;ar d libcieee.a mkdir.o;ar d libc881.a mkdir.o
It's broken because it never sets errno when it fails. perl expects
it to do. It simply does a popen("/bin/mkdir") anyway, so there's no
fancy undocumented system calls hiding there either.
---
Robert Andersson, International Systems A/S, Oslo, Norway.
Internet: ra@is.uu.no
UUCP: ...!{uunet,mcvax,ifi}!is.uu.no!radecot@hpisod2.HP.COM (Dave Decot) (01/05/90)
Perhaps mkdir() is a library function, in section 3.
bt455s10@uhccux.uhcc.hawaii.edu (Carl "Art" McIntosh) (01/06/90)
NO, the mkdir() function is *completely* undocumented in OS 2.01.00,
furthermore, it is broken. I ran across the following problem when
installing perl 3.0 patchlevel 8 on our NCR Tower 32/650.
perl compiled ok except for a minor problem with optimizer labels,
which was fixed via -W2,-Sl,2000 ... when I ran "make test", op.mkdir
failed on test 3. I posted an article to the net, and a knowledgable
fellow in Oslo, Norway sent me mail pointing me to the problem. I
verifyed the problem with a small C test program. It seems mkdir.o
exists in /lib/libc.a, /lib/libcieee and /lib/libc88.a, is NOT documented
in the programmers ref, and has NO manpage on the system. It does NOT
set errno when an error is encountered. The program below demonstrates
the problem.
main()
{
if (mkdir("art") == -1)
printf("%d\n", errno);
}
use mkdir(1) to create an "art" directory before running the program.
The output from the above program is "25", which corresponds to
ENOTTY (Not a typerwriter) in /usr/include/sys/errno.h.
You can use ar(1) easily enough to remove the offending routine,
in which case the perl 3.0 Configure will NOT define it and
/bin/mkdir will be forked instead.
Art Neilson
Bank of Hawaii Tech Support
ARPA: manapua!pilikia!root@trout.nosc.mil
UUCP: {uunet,ucbvax,dcdwest}!ucsd!nosc!manapua!pilikia!rootwescott@Columbia.NCR.COM (Mike Wescott) (01/09/90)
In article <6045@uhccux.uhcc.hawaii.edu> bt455s10@uhccux.UUCP (Carl "Art" McIntosh) writes: > NO, the mkdir() function is *completely* undocumented in OS 2.01.00, > furthermore, it is broken [...] > main() > { > if (mkdir("art") == -1) > printf("%d\n", errno); > } > use mkdir(1) to create an "art" directory before running the program. > The output from the above program is "25", which corresponds to > ENOTTY (Not a typerwriter) in /usr/include/sys/errno.h. mkdir.o is indeed broken in that it does not completely emulate the system call of the same name in 4.3BSD and later vintages of SysV. The Rel2.xx version of mkdir is an emulation using a popen() to the shell and feeding it a mkdir and chmod. The ENOTTY errno is often found in errno when stdio is used (as it is here with the popen()). The supplied mkdir() takes two arguments: the name of the directory to make and the mode. Taking all this into account: main() { if (mkdir("art",0755) != 0) printf("could not mkdir %s\n","art"); } If you expect full mkdir capability or none (like perl) you can't use it. Why it's not documented, I don't know. Probably because it wasn't supposed to be released. -- -Mike Wescott mike.wescott@ncrcae.Columbia.NCR.COM