mishkin@apollo.COM (Nathaniel Mishkin) (08/15/88)
I have been trying to write a program to walk through a directory,
and get the full path name of every object recorded there. Much
of it works, but I have been unable to open objects based on
an open directory stream. The code at fault resembles the
following, which also displays the problem: ...
So, why is it an illegal operation to perform an "ios_dir_$open"
on an Apollo directory object that purports to implement the
IOS_DIR trait?
That's easy -- the dir_open operation is not implemented for the
apollo_dir type.
I hasten to point out that the program can be written (probably more
simply) using chdir and opendir/readdir:
---------------------------------------------------
#include "/sys/ins/base.ins.c"
#include "/sys/ins/ios.ins.c"
#include <sys/types.h>
#include <sys/dir.h>
#include <sys/file.h>
main(argc, argv)
int argc;
char *argv[];
{
DIR *dir;
struct direct *ent;
int fd;
char pname[1024];
short pnamelen;
status_$t st;
chdir(argv[1]);
dir = opendir(".");
while ((ent = readdir(dir)) != NULL) {
fd = open(ent->d_name, O_RDONLY, 0);
ios_$inq_path_name((short) fd, ios_$root_name, pname, pnamelen, st);
close(fd);
printf("%.*s\n", pnamelen, pname);
}
}
---------------------------------------------------
--
-- Nat Mishkin
Apollo Computer Inc., Chelmsford, MA
mishkin@apollo.comJinfu@cup.portal.com (08/16/88)
I don't understand why following codes don't work:
#include <stdio.h>
#include <strings.h>
main(argc, argv)
int argc;
char *argv;
{
char *str1;
strcpy(str1, argv[1]);
}
The runtime error is 'access violation'. If I change definition of str1
to array, the code will work:
char str1[256];
Our system is running 9.7 with BSD4.2. Is this my misunderstanding of
strcpy or just another 'It is fixed in SR10' bug?
(after all, isn't it nice to hear this than, say, involling 50 nodes
in your network? :-)
Jinfu Chenkrowitz@RICHTER.MIT.EDU (David Krowitz) (08/16/88)
Yet, you must admit that it seems a little strange that there is this call to simplify access to objects across a transparent file access mechanism and it does not work with local objects. After all, isn't the whole idea of transparent file access supposed to be that the application program can't tell whether or not the file is local? In the case of the IOS_DIR$OPEN call, the application must know beforehand that the object is NOT local! -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
rees@MAILGW.CC.UMICH.EDU (Jim Rees) (08/17/88)
Yet, you must admit that it seems a little strange that there is this
call to simplify access to objects across a transparent file access
mechanism and it does not work with local objects. After all, isn't the
whole idea of transparent file access supposed to be that the application
program can't tell whether or not the file is local? In the case of
the IOS_DIR$OPEN call, the application must know beforehand that the
object is NOT local!
Transparent interfaces are always built on top of specific
implementations. Ios_dir is intended to be the interface exported by the
manager, not the interface used by applications to achieve transparency.
When I'm writing an application, I don't use ios_dir. I use opendir(),
chdir(), readdir(), closedir(), etc. These are the real
manager-independent calls. Besides which, they give you portability to
other Unix systems that don't have extensible streams.
-------dave@jplopto.uucp (Dave Hayes) (08/18/88)
> I don't understand why following codes don't work: > #include <stdio.h> > #include <strings.h> > main(argc, argv) > int argc; > char *argv; > { > char *str1; > strcpy(str1, argv[1]); > } This is not a problem with the apollo, but a problem with your understanding of pointer syntax. Relax, it's a common mistake! The definition char *str1: means "str1" is a POINTER to an array of characters. In other words, str1 is supposed to contain the address of a character array. But in this code fragment, you have not assigned an address to "str1", so the variable contains a "garbage" address. Therefore, when the program tries to run, it tries to copy the string pointed to by argv[1] to a non-existant character array. This is why you get an "access violation". The way to fix this would be to define str1 like this: char str1[255]; (or replace the 255 with some number more appropriate to your application) so that there is an array defined for strcpy to copy into. I would suggest that you get a good book on basic C programming before you go any further. I don't know of any offhand, but there *are* some good books out there that would help you avoid the more common C mistakes. ------===<<<Dave Hayes>>>===------ dave%jplopto@jpl-mil.jpl.nasa.gov {cit-vax,ames}!elroy!jplopto!dave
gaz@apollo.COM (Gary Zaidenweber) (08/18/88)
From article <8180@cup.portal.com>, by Jinfu@cup.portal.com: > > > I don't understand why following codes don't work: > > > #include <stdio.h> > #include <strings.h> > > main(argc, argv) > int argc; > char *argv; > { > char *str1; > strcpy(str1, argv[1]); > } > > The runtime error is 'access violation'. If I change definition of str1 > to array, the code will work: > > char str1[256]; > > > Our system is running 9.7 with BSD4.2. Is this my misunderstanding of > strcpy or just another 'It is fixed in SR10' bug? > > (after all, isn't it nice to hear this than, say, involling 50 nodes > in your network? :-) > > Jinfu Chen Its neither a misunderstanding of strcpy or a "bug fixed in SR10", its a C programming error. If you declare str1 to be a pointer to char without a backing storage of characters declared somewhere else, str1 is an uninitialized pointer. Depending on the C implementation, it may be NULL or point into hyperspace. When you declare it as an array, it then can be used as either a pointer to the backing storage of the array or as the array itself. Note also, please that your typed-in example needs to declare argv as "char *argv[]" in order to work. -- UUCP: ...{umix,mit-eddie,uw-beaver}!apollo!gaz ARPA: gaz@apollo.COM AT&T: (508)256-6600 x6081 Its never too late to have a happy childhood!