RE: > Subject: Re: [Dev-C++] directory I/O handling problem

[Per W. <pw...@ia...>]

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
>