Posix don't deal with invalid pointers - only strings pointing to or not
pointing to a directory entry.
They don't need to mention any segmentation faults - it's always up to the
developer to make sure that all pointers are ssane.
/Per W
On Tue, 5 Jul 2005 Mat...@Ve... wrote:
> Not according to Posix... Where are the segfaults in this?
> Also, if you can't check the status of the directory with opendir, try stat.
>
> NAME
>
> opendir - open a directory
>
> SYNOPSIS
>
> #include <dirent.h>
>
> DIR *opendir(const char *dirname);
>
> DESCRIPTION
>
> The opendir() function shall open a directory stream corresponding to
> the directory named by the dirname argument. The directory stream is
> positioned at the first entry. If the type DIR is implemented using a file
> descriptor, applications shall only be able to open up to a total of
> {OPEN_MAX} files and directories.
>
> RETURN VALUE
>
> Upon successful completion, opendir() shall return a pointer to an
> object of type DIR. Otherwise, a null pointer shall be returned and errno
> set to indicate the error.
>
> ERRORS
>
> The opendir() function shall fail if:
>
> [EACCES]
> Search permission is denied for the component of the path prefix of
> dirname or read permission is denied for dirname.
> [ELOOP]
> A loop exists in symbolic links encountered during resolution of the
> dirname argument.
> [ENAMETOOLONG]
> The length of the dirname argument exceeds {PATH_MAX} or a pathname
> component is longer than {NAME_MAX}.
> [ENOENT]
> A component of dirname does not name an existing directory or
> dirname is an empty string.
> [ENOTDIR]
> A component of dirname is not a directory.
>
> The opendir() function may fail if:
>
> [ELOOP]
> More than {SYMLOOP_MAX} symbolic links were encountered during
> resolution of the dirname argument.
> [EMFILE]
> {OPEN_MAX} file descriptors are currently open in the calling
> process.
> [ENAMETOOLONG]
> As a result of encountering a symbolic link in resolution of the
> dirname argument, the length of the substituted pathname string exceeded
> {PATH_MAX}.
> [ENFILE]
> Too many files are currently open in the system.
>
>
> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...]On Behalf Of Big
> Playah
> Sent: Monday, July 04, 2005 5:32 AM
> To: dev...@li...
> Subject: Re: > Subject: Re: [Dev-C++] directory I/O handling problem
>
>
> Hi,
>
> > Message: 5
> > Date: Sat, 2 Jul 2005 21:18:24 -0500
> > From: Josh McFarlane <da...@gm...>
> > Reply-To: Josh McFarlane <da...@gm...>
> > Subject: Re: [Dev-C++] directory I/O handling problem
> > Cc: dev...@li...
>
> > Why not just call opendir() and check for a null pointer after calling it?
>
> because it raises some segfaults with stupid arguments which might
> happen... that's what I want to avoid
>
> tom
> ___________________________________________________________________
> The information contained in this message and any attachment may be
> proprietary, confidential, and privileged or subject to the work
> product doctrine and thus protected from disclosure. If the reader
> of this message is not the intended recipient, or an employee or
> agent responsible for delivering this message to the intended
> recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited.
> If you have received this communication in error, please notify me
> immediately by replying to this message and deleting it and all
> copies and backups thereof. Thank you.
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>
|
