By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,679 Members | 1,063 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,679 IT Pros & Developers. It's quick & easy.

search for files

P: n/a
hi there
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.
thanks.
Jun 29 '08 #1
Share this Question
Share on Google+
30 Replies


P: n/a
Jrdman wrote:
hi there
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.
thanks.
No.
I use the MSDN library for that purpose.

--
pete
Jun 29 '08 #2

P: n/a
In article <f7**********************************@y21g2000hsf. googlegroups.com>,
Jrdman <ah*********@gmail.comwrote:
>hi there
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.
I would imagine that using the Windows APIs would be fairly useless
on non- MS Windows systems, so if we take it as understood that
people have indeed been able to write code to search for files in
a directory on at least one non- MS Windows system, then the answer
to your question would logically have to be "Yes".
You might find it instructive to read the recent thread "directories"
started by 'sid' on June 27th,
http://groups.google.ca/group/comp.l...23538a011bd637
--
Q: Why did the chicken cross the Mobius strip?

A: There were manifold reasons.
Jun 29 '08 #3

P: n/a
"Jrdman" <ah*********@gmail.comwrote in message news:
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.
No.
ANSI C has no directory functions, which at first sight may seem surprising
since there are fucntions to open files from paths.
However on many systems directories can be very large, and can be altered by
other users. This makes it quite difficult to devise a robust interface
which will hold for every system.
Thus you have to use OS-specific functions.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Jun 29 '08 #4

P: n/a
On Jun 29, 1:21*pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
"Jrdman" <ahmed.bo...@gmail.comwrote in message news:
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.

No.
ANSI C has no directory functions, which at first sight may seem surprising
since there are fucntions to open files from paths.
However on many systems directories can be very large, and can be alteredby
other users. This makes it quite difficult to devise a robust interface
which will hold for every system.
Thus you have to use OS-specific functions.

--
Free games and programming goodies.http://www.personal.leeds.ac.uk/~bgy1mm
yes i know that ANSI C has no directory functions,to make my question
clear,how can i write a function that search for files using a native
C code (without using Windows APIs)i know it's possible to write that
code, the obvious example is the windows APIs
themselves(FindFirstFile() and FindNextFile())if it's not possible how
these two functions are coded?
Jun 29 '08 #5

P: n/a
In comp.lang.c, Jrdman wrote:
hi there
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
Technically, with the proper 3rd-party addon, anyone can write this. In
fact, given my current platform, I can definitely write a directory search
program in C (with POSIX extensions) without using /any/ Windows APIs. It
helps that I don't run Windows, of course ;-)

or even has a small idea on how to do that.
thanks.
--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
Jun 29 '08 #6

P: n/a
Jrdman wrote:
yes i know that ANSI C has no directory functions,to make my question
clear,how can i write a function that search for files using a native
C code (without using Windows APIs)i know it's possible to write that
code,
the obvious example is the windows APIs
themselves(FindFirstFile() and FindNextFile())if it's not possible how
these two functions are coded?
It seems as though:
1 Those functions are your examples of functions
coded in "native c code".
2 You have no idea how those functions are coded.

Am I reading you correctly?

--
pete
Jun 29 '08 #7

P: n/a
Jrdman wrote:
On Jun 29, 1:21 pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
>"Jrdman" <ahmed.bo...@gmail.comwrote in message news:
>>can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.
No.
ANSI C has no directory functions, which at first sight may seem surprising
since there are fucntions to open files from paths.
However on many systems directories can be very large, and can be altered by
other users. This makes it quite difficult to devise a robust interface
which will hold for every system.
Thus you have to use OS-specific functions.

yes i know that ANSI C has no directory functions,to make my question
clear,how can i write a function that search for files using a native
C code (without using Windows APIs)i know it's possible to write that
code, the obvious example is the windows APIs
themselves(FindFirstFile() and FindNextFile())if it's not possible how
these two functions are coded?
There is no requirement that Windows API functions are coded in C. For
all we know, they're coded in assembler. There are many ways to make
functions available to C without writing those functions themselves in
C, though the techniques are off-topic here.

There is _no_ portable way to do what you're asking. C does not even
acknowledge that directories exist, since C has to work on platforms
that have no concept of directories. Therefore, there is no 100%
portable way to write code that manipulates or even examines directories.

The usual solution when running into problems like this is to create
your own wrapper interface and a few different implementations (with
suitable #ifdef's) that call the native functions. Of course, at that
point your program is only "portable" to the systems that implement one
of the native interfaces you know how to call...

S
Jun 29 '08 #8

P: n/a
On Jun 29, 2:32*pm, pete <pfil...@mindspring.comwrote:
Jrdman wrote:
yes i know that ANSI C has no directory functions,to make my question
clear,how can i write a function that search for files using a native
C code (without using Windows APIs)i know it's possible to write that
code,
*the obvious example is the windows APIs
themselves(FindFirstFile() and FindNextFile())if it's not possible how
these two functions are coded?

It seems as though:
* * 1 * *Those functions are your examples of functions
* * * * *coded in "native c code".
* * 2 * *You have no idea how those functions are coded.

Am I reading you correctly?

--
pete
As i know(i've heard) and i'm not sure that windows APIs are coded in
C and those two functions are part of Windows APIs.if i'm wrong you
can correct me not just tell me that i'm wrong coz this is not
helpfull anymore
Jun 29 '08 #9

P: n/a
On Jun 29, 2:57*pm, Stephen Sprunk <step...@sprunk.orgwrote:
Jrdman wrote:
On Jun 29, 1:21 pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
"Jrdman" <ahmed.bo...@gmail.comwrote in message news:
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.
No.
ANSI C has no directory functions, which at first sight may seem surprising
since there are fucntions to open files from paths.
However on many systems directories can be very large, and can be altered by
other users. This makes it quite difficult to devise a robust interface
which will hold for every system.
Thus you have to use OS-specific functions.
yes i know that ANSI C has no directory functions,to make my question
clear,how can i write a function that search for files using a native
C code (without using Windows APIs)i know it's possible to write that
code, the obvious example is the windows APIs
themselves(FindFirstFile() and FindNextFile())if it's not possible how
these two functions are coded?

There is no requirement that Windows API functions are coded in C. *For
all we know, they're coded in assembler. *There are many ways to make
functions available to C without writing those functions themselves in
C, though the techniques are off-topic here.

There is _no_ portable way to do what you're asking. *C does not even
acknowledge that directories exist, since C has to work on platforms
that have no concept of directories. *Therefore, there is no 100%
portable way to write code that manipulates or even examines directories.

The usual solution when running into problems like this is to create
your own wrapper interface and a few different implementations (with
suitable #ifdef's) that call the native functions. *Of course, at that
thanks.but what do you mean by native functions(what functions?)?
point your program is only "portable" to the systems that implement one
of the native interfaces you know how to call...

S- Hide quoted text -

- Show quoted text -
Jun 29 '08 #10

P: n/a
"Jrdman" writes:
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.
That's going to be a pain in the butt. Kind of like learning how to make
gunpowder with horse urine and swamp grass; a dying art. Lot's of arcane
jargon to work your way through. You have to be have some competence with
trees and recursion. I am sure you have figured out by now that this is not
the right froup. The best idea I have is to search old entries (ca.
1990-1995) in ms-dos oriented google groups. It's not a *good* idea, it is
just the best I can come up with.

Don't try to do it all at once, creep rather than walk. Start by using
findfirst() on a file you know exists. Then one you know doesn't exist.
And so on.
Jun 29 '08 #11

P: n/a

"Jrdman" <ah*********@gmail.comwrote in message
>As i know(i've heard) and i'm not sure that windows APIs are coded in
C and those two functions are part of Windows APIs.if i'm wrong you
can correct me not just tell me that i'm wrong coz this is not
helpfull anymore
The bulk of FindFirstFile() is probably coded in C. However at some point it
will make a call to a low-level function to detect that a file is a
directory and load it. I don't actually know how directories are laid out in
DOS, but probably they are just flat files with lists of contents. It will
then call fopen() on this file - fopen() itself can't be written in portable
C.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Jun 29 '08 #12

P: n/a
Jrdman wrote:
On Jun 29, 2:32 pm, pete <pfil...@mindspring.comwrote:
>Jrdman wrote:
>>yes i know that ANSI C has no directory functions,to make my question
clear,how can i write a function that search for files using a native
C code (without using Windows APIs)i know it's possible to write that
code,
the obvious example is the windows APIs
themselves(FindFirstFile() and FindNextFile())if it's not possible how
these two functions are coded?
It seems as though:
1 Those functions are your examples of functions
coded in "native c code".
2 You have no idea how those functions are coded.

Am I reading you correctly?

--
pete

As i know(i've heard) and i'm not sure that windows APIs are coded in
C and those two functions are part of Windows APIs.if i'm wrong you
can correct me not just tell me that i'm wrong coz this is not
helpfull anymore
Not just tell you that you're wrong?
OK.

You have absolutely no idea of what you're talking about.
You can't even use the word "know" correctly in a sentence.
Give up programming.

--
pete
Jun 29 '08 #13

P: n/a
On Jun 29, 3:47*pm, pete <pfil...@mindspring.comwrote:
Jrdman wrote:
On Jun 29, 2:32 pm, pete <pfil...@mindspring.comwrote:
Jrdman wrote:
yes i know that ANSI C has no directory functions,to make my question
clear,how can i write a function that search for files using a native
C code (without using Windows APIs)i know it's possible to write that
code,
*the obvious example is the windows APIs
themselves(FindFirstFile() and FindNextFile())if it's not possible how
these two functions are coded?
It seems as though:
* * 1 * *Those functions are your examples of functions
* * * * *coded in "native c code".
* * 2 * *You have no idea how those functions are coded.
Am I reading you correctly?
--
pete
As i know(i've heard) and i'm not sure that *windows APIs are coded in
C and those two functions are part of Windows APIs.if i'm wrong you
can correct me not just tell me that i'm wrong coz this is not
helpfull anymore

Not just tell you that you're wrong?
OK.

You have absolutely no idea of what you're talking about.
You can't even use the word "know" correctly in a sentence.
Give up programming.

--
pete- Hide quoted text -

- Show quoted text -
you can't even make the difference between computer languages and
human languages,sorry but here we are learning C not english
and noone is pushing you to answear my question, if you don't "KNOW"
just shutup,and if you have a problem with humans relationships
i'm really sorry for you...
Jun 29 '08 #14

P: n/a
Jrdman wrote:
>
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.
No. There is no reason to assume directories exist on a file
system. As an example, consider the CP/M-80 file system. Which
supported a lot of software.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Jun 29 '08 #15

P: n/a
On Sun, 29 Jun 2008 08:22:18 -0700 (PDT), Jrdman
<ah*********@gmail.comwrote:
>On Jun 29, 2:57*pm, Stephen Sprunk <step...@sprunk.orgwrote:
>Jrdman wrote:
On Jun 29, 1:21 pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
"Jrdman" <ahmed.bo...@gmail.comwrote in message news:
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.
No.
ANSI C has no directory functions, which at first sight may seem surprising
since there are fucntions to open files from paths.
However on many systems directories can be very large, and can be altered by
other users. This makes it quite difficult to devise a robust interface
which will hold for every system.
Thus you have to use OS-specific functions.
yes i know that ANSI C has no directory functions,to make my question
clear,how can i write a function that search for files using a native
C code (without using Windows APIs)i know it's possible to write that
code, the obvious example is the windows APIs
themselves(FindFirstFile() and FindNextFile())if it's not possible how
these two functions are coded?

There is no requirement that Windows API functions are coded in C. *For
all we know, they're coded in assembler. *There are many ways to make
functions available to C without writing those functions themselves in
C, though the techniques are off-topic here.

There is _no_ portable way to do what you're asking. *C does not even
acknowledge that directories exist, since C has to work on platforms
that have no concept of directories. *Therefore, there is no 100%
portable way to write code that manipulates or even examines directories.

The usual solution when running into problems like this is to create
your own wrapper interface and a few different implementations (with
suitable #ifdef's) that call the native functions. *Of course, at that
thanks.but what do you mean by native functions(what functions?)?
Functions specifically provided by the system you intend to execute on
for the purpose of dealing with directories. The Windows API is one
set of such functions designed to work on Windows. There may be
others for Windows. There probably are others for Unix. You might
check to see if POSIX provides some. In any event, you need to ask in
a group that deals with your execution environment because the
language itself offers no support in this area.
>point your program is only "portable" to the systems that implement one
of the native interfaces you know how to call...

Remove del for email
Jun 29 '08 #16

P: n/a
Jrdman wrote:
hi there
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.
thanks.
Just curious but why do you want to do this? Is it for purposes of
learning (dubious value), or because you might believe the APIs
provided by the system are too inefficient, or some other reason?

Serious code should use APIs provided by the system vendor unless there
is a very good reason to do otherwise.

Now coming to your actual question, you will essentially have to
directly interpret the filesystem structure that the system uses to
represent directories. This may be some version of the FAT or NTFS
filesystem. Your program might need administrative rights to do this
too. Your best bet is to ask in a group for your system like
<news:comp.os.ms-windows.programmer.win32or <news:comp.os.ms-dosor
some related group. There are no dearth of Usenet groups for Windows
programming. Just search the groups list of your news provider or use
the "search for group" facility of Google Groups.

Jun 30 '08 #17

P: n/a
On Jun 30, 6:41*am, santosh <santosh....@gmail.comwrote:
Jrdman wrote:
hi there
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.
thanks.

Just curious but why do you want to do this? Is it for purposes of
learning (dubious value), or because you might believe the APIs
provided by the system are too inefficient, or some other reason?

Serious code should use APIs provided by the system vendor unless there
is a very good reason to do otherwise.

Now coming to your actual question, you will essentially have to
directly interpret the filesystem structure that the system uses to
represent directories. This may be some version of the FAT or NTFS
filesystem. Your program might need administrative rights to do this
too. Your best bet is to ask in a group for your system like
<news:comp.os.ms-windows.programmer.win32or <news:comp.os.ms-dosor
some related group. There are no dearth of Usenet groups for Windows
programming. Just search the groups list of your news provider or use
the "search for group" facility of Google Groups.
thanks for your help,and as an answer to your first question ,i'm just
doing this for learning purposes.I will certainly use the API
functions provided with MS Windows to programming in that system,but i
first prefer to know how these functions work and then use them.i've
created a group for that purpose (lang.c&asm) if you wanna help you
are welcome.
Jun 30 '08 #18

P: n/a
On Sun, 29 Jun 2008 05:24:30 -0700 (PDT), Jrdman
<ah*********@gmail.comwrote:
hi there
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.
How about the following?

#include <stdio.h>
#include <stdlib.h>

#define MAXPATTERN 12
#define MAXCOMMAND 80

int main(void) {
char cmd_string[MAXCOMMAND +1];
char pattern[MAXPATTERN + 1];

printf("Enter the pattern to search for: ");
if (fgets(pattern, MAXPATTERN + 1, stdin) == NULL) {
printf("An error occurred.\n");
exit(EXIT_FAILURE);
}

strcpy(cmd_string, "dir /s ");
strcat(cmd_string, pattern);
system(cmd_string);
return EXIT_SUCCESS;
}

See - no mention of FindFirstFile or FindNextFile. Course, it only
works for files with short names, but it should be good enough for
your homework. For extra credit you could try using gets instead of
fgets, but that is left as an exercise for the reader.

Tony
Jun 30 '08 #19

P: n/a
On Jun 30, 10:38 pm, Tony Mc <af...@btinternet.comwrote:
On Sun, 29 Jun 2008 05:24:30 -0700 (PDT), Jrdman

<ahmed.bo...@gmail.comwrote:
hi there
can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.

How about the following?

#include <stdio.h>
#include <stdlib.h>

#define MAXPATTERN 12
#define MAXCOMMAND 80

int main(void) {
char cmd_string[MAXCOMMAND +1];
char pattern[MAXPATTERN + 1];
why the +1's?
>
printf("Enter the pattern to search for: ");
flush stdout() if you expect this to be written by the time you reach
the fgets() call.
if (fgets(pattern, MAXPATTERN + 1, stdin) == NULL) {
printf("An error occurred.\n");
Write to 'stderr' instead or use perror().
exit(EXIT_FAILURE);
}

strcpy(cmd_string, "dir /s ");
Where's <string.hor a declaration for strcpy (and strcat)?
strcat(cmd_string, pattern);
sprintf(cmd_string "dir /s %s", pattern);
MAXCOMMAND is quite bigger than what it actually needs to be.
system(cmd_string);
At least try this:
if(system(NULL)) system(cmd_string);
return EXIT_SUCCESS;

}

See - no mention of FindFirstFile or FindNextFile. Course, it only
works for files with short names, but it should be good enough for
It doesn't work. You assume a lot of things, that the implementation
has a command processor, that 'dir' does exist, that '/s' is
meaningful for 'dir', that it does what is assumed, that the user
won't input something malicious.
Your code invokes undefined behavior in several places.
your homework. For extra credit you could try using gets instead of
fgets, but that is left as an exercise for the reader.
gets() does not seem appropriate for this problem.
Jun 30 '08 #20

P: n/a
On Mon, 30 Jun 2008 15:51:13 -0700 (PDT), vi******@gmail.com wrote:
On Jun 30, 10:38 pm, Tony Mc <af...@btinternet.comwrote:
How about the following?

#include <stdio.h>
#include <stdlib.h>

#define MAXPATTERN 12
#define MAXCOMMAND 80

int main(void) {
char cmd_string[MAXCOMMAND +1];
char pattern[MAXPATTERN + 1];
why the +1's?
I used +1 here because the buffers can then hold up to MAX...
characters as well as the nul terminator. This seems more intuitive to
me, so that a published value of MAXPATTERN means the user can enter
up to MAXPATTERN characters (rather than MAXPATTERN - 1). That is the
same reason for using MAXPATTERN + 1 in the call to fgets, since
fgets(s, n, stream) will get up to n-1 characters into s, and then
append a nul terminator. Isn't that right?

printf("Enter the pattern to search for: ");
flush stdout() if you expect this to be written by the time you reach
the fgets() call.
if (fgets(pattern, MAXPATTERN + 1, stdin) == NULL) {
printf("An error occurred.\n");
Write to 'stderr' instead or use perror().
exit(EXIT_FAILURE);
}

strcpy(cmd_string, "dir /s ");
Where's <string.hor a declaration for strcpy (and strcat)?
Oops, yes I missed the header inclusion.
strcat(cmd_string, pattern);
sprintf(cmd_string "dir /s %s", pattern);
MAXCOMMAND is quite bigger than what it actually needs to be.
Is that a problem?
system(cmd_string);
At least try this:
if(system(NULL)) system(cmd_string);
return EXIT_SUCCESS;

}

See - no mention of FindFirstFile or FindNextFile. Course, it only
works for files with short names, but it should be good enough for
It doesn't work. You assume a lot of things, that the implementation
has a command processor, that 'dir' does exist, that '/s' is
meaningful for 'dir', that it does what is assumed, that the user
won't input something malicious.
See below.
Your code invokes undefined behavior in several places.
your homework. For extra credit you could try using gets instead of
fgets, but that is left as an exercise for the reader.
gets() does not seem appropriate for this problem.
Hi vippstar,

my post was intended as a joke - I'm sorry you missed that. However, I
am interested by your claim that the code invokes undefined behaviour
"in several places". I intended to write correct, though useless, code
in response to a hopelessly vague specification. A sort of "everything
you asked for but none of what you need" response. So please do point
out the undefined behaviour, because I am always eager to learn from
my mistakes. Thanks for pointing out the missing header though.

Tony

Jul 1 '08 #21

P: n/a
On Jul 1, 11:29 am, Tony Mc <af...@btinternet.comwrote:
Hi vippstar,

my post was intended as a joke - I'm sorry you missed that. However, I
am interested by your claim that the code invokes undefined behaviour
"in several places". I intended to write correct, though useless, code
in response to a hopelessly vague specification. A sort of "everything
you asked for but none of what you need" response. So please do point
out the undefined behaviour, because I am always eager to learn from
my mistakes. Thanks for pointing out the missing header though.
The strcpy() line, the strcat() line, the system() line.
The first two, you call the functions without the declaration in
scope.
The last one, anything passed to system() other than a null pointer
invokes undefined behavior.
That's 3 UBs in 17 lines code, thus several.
Jul 1 '08 #22

P: n/a
On Tue, 1 Jul 2008 04:47:51 -0700 (PDT), vi******@gmail.com wrote:
On Jul 1, 11:29 am, Tony Mc <af...@btinternet.comwrote:
Hi vippstar,

my post was intended as a joke - I'm sorry you missed that. However, I
am interested by your claim that the code invokes undefined behaviour
"in several places". I intended to write correct, though useless, code
in response to a hopelessly vague specification. A sort of "everything
you asked for but none of what you need" response. So please do point
out the undefined behaviour, because I am always eager to learn from
my mistakes. Thanks for pointing out the missing header though.
The strcpy() line, the strcat() line, the system() line.
The first two, you call the functions without the declaration in
scope.
The last one, anything passed to system() other than a null pointer
invokes undefined behavior.
That's 3 UBs in 17 lines code, thus several.
OK, I have already said oops about the missing stdio.h header
inclusion. Is the use of strcpy, strcat UB apart from not including
their prototypes? As for system, my reading of 7.20.4.6 in the C99
standard is that as long as the string passed to system() is not a
NULL pointer, the behaviour is *implementation defined* because the
string is passed to the system's command processor (I think appendix
J.3.2 makes this explicit). How is that undefined behaviour? I think I
am probably taking your objections more seriously than I should, since
the original was not intended seriously and you seem to have a humour
impairment, but if you can show me where I am going wrong, I would
still value the lesson. Unfortunately what you have said so far is too
lacking in detail to be of much use to me.

Tony
Jul 1 '08 #23

P: n/a
On Jul 1, 7:30 pm, Tony Mc <af...@btinternet.comwrote:
On Tue, 1 Jul 2008 04:47:51 -0700 (PDT), vipps...@gmail.com wrote:
The strcpy() line, the strcat() line, the system() line.
The first two, you call the functions without the declaration in
scope.
The last one, anything passed to system() other than a null pointer
invokes undefined behavior.
That's 3 UBs in 17 lines code, thus several.

OK, I have already said oops about the missing stdio.h header
inclusion. Is the use of strcpy, strcat UB apart from not including
their prototypes? As for system, my reading of 7.20.4.6 in the C99
Apart from *not* including the prototypes? Of course not, if you
include the prototype these two lines in your program do not invoke
undefined behavior.
standard is that as long as the string passed to system() is not a
NULL pointer, the behaviour is *implementation defined* because the
string is passed to the system's command processor (I think appendix
J.3.2 makes this explicit). How is that undefined behaviour? I think I
am probably taking your objections more seriously than I should, since
the original was not intended seriously and you seem to have a humour
impairment, but if you can show me where I am going wrong, I would
I don't have a humour impairment (or do I?) but I believe that a
newbie would trust your code instead of realizing you're joking.
still value the lesson. Unfortunately what you have said so far is too
lacking in detail to be of much use to me.
For system() I think you will enjoy this article and the follow-ups:
<9r*********@enews2.newsguy.com>
As for strcpy() and strcat() I'm only positive undefined behavior is
invoked but I cannot back up this with a section/verse from the
standard because I don't know where exactly to look. Perhaps someone
else will shed some light on the matter?
Jul 1 '08 #24

P: n/a
vi******@gmail.com wrote:
>
.... snip ...
>
As for strcpy() and strcat() I'm only positive undefined behavior
is invoked but I cannot back up this with a section/verse from
the standard because I don't know where exactly to look. Perhaps
someone else will shed some light on the matter?
For a sufficiently accurate draft of the standard, formatted and
suitable for quoting on usenet, try the following link. The item
is bzip compressed. This is the last version available as text.

<http://cbfalconer.home.att.net/download/n869_txt.bz2>

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Jul 1 '08 #25

P: n/a
CBFalconer <cb********@yahoo.comwrites:
vi******@gmail.com wrote:
... snip ...

As for strcpy() and strcat() I'm only positive undefined behavior
is invoked but I cannot back up this with a section/verse from
the standard because I don't know where exactly to look. Perhaps
someone else will shed some light on the matter?

For a sufficiently accurate draft of the standard, formatted and
suitable for quoting on usenet, try the following link. The item
is bzip compressed. This is the last version available as text.

<http://cbfalconer.home.att.net/download/n869_txt.bz2>
For a more accurate post-C99 draft of the standard, see:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

It's perfectly suitable for quoting on Usenet if you have the right
tools, and it includes semantically significant formatting that's lost
in any conversion to plain text.

Chuck, I understand that you prefer your plain-text n869, but wouldn't
it be better to refer to *both*?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 1 '08 #26

P: n/a
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
.... snip ...
>
For a more accurate post-C99 draft of the standard, see:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

It's perfectly suitable for quoting on Usenet if you have the
right tools, and it includes semantically significant formatting
that's lost in any conversion to plain text.

Chuck, I understand that you prefer your plain-text n869, but
wouldn't it be better to refer to *both*?
Well, when I use the following sig, I do. :-)

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://c-faq.com/ (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf(C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2(C99, txt)
<http://www.dinkumware.com/c99.aspx (C-library}
<http://gcc.gnu.org/onlinedocs/ (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>
Jul 2 '08 #27

P: n/a
On Sun, 29 Jun 2008 14:17:07 UTC, Jrdman <ah*********@gmail.com>
wrote:

yes i know that ANSI C has no directory functions,to make my question
clear,how can i write a function that search for files using a native
C code (without using Windows APIs)i know it's possible to write that
code, the obvious example is the windows APIs
themselves(FindFirstFile() and FindNextFile())if it's not possible how
these two functions are coded?
It's easy. We'll use the OS/2 APIs when on OS2 or xyz-AOIs when on the
system xyz. But never use the Windows-APIs when not on a Windows
version that accepts then.

Yes, it is possible to write programsd compatible to any specified
number of systems one likes. A proven method for that is to write
wrappers around system specific code and avoiding stirctly to write a
single system specific statement outside such wrappers and marked as
systemspecific functions or modules.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
Jul 2 '08 #28

P: n/a
On Tue, 1 Jul 2008 09:47:03 -0700 (PDT), vi******@gmail.com wrote:
For system() I think you will enjoy this article and the follow-ups:
<9r*********@enews2.newsguy.com>
As for strcpy() and strcat() I'm only positive undefined behavior is
invoked but I cannot back up this with a section/verse from the
standard because I don't know where exactly to look. Perhaps someone
else will shed some light on the matter?
Ok, thanks for that reference, lots of interesting reading there. I
don't see that it shows that calling system() with a non-NULL pointer
invokes undefined behaviour, though the majority view seemed to be
that the standard had no way of defining the behaviour (and for some
that counted as UB in all but name, a point I can see but which I
think confuses the use of the term UB). As I understand it, that makes
the call implementation defined (which the standard also cannot
define, but requires the implementation to), which is not the same as
undefined. However, as you have probably guessed, I have never called
system() in code I meant seriously (remember, the code that started
this was intended humorously) and, particularly after reading much of
the discussion you referred me to, I can't see that I ever would. And
thanks for clarifying that the only problem with my use of strcpy and
strcat was the missing header - I thought you were onto something more
subtle than that.

And finally, I take your point about potentially misleading newbies
with a non-serious posting. I don't know how I might have flagged up
the fact that it was not to be taken seriously more clearly than the
invitation to use gets() already did. But evidently you thought I
meant that, so I need to be more careful in future.

Best,
Tony
Jul 2 '08 #29

P: n/a
Tony Mc <af***@btinternet.comwrites:
[...]
Ok, thanks for that reference, lots of interesting reading there. I
don't see that it shows that calling system() with a non-NULL pointer
invokes undefined behaviour, though the majority view seemed to be
that the standard had no way of defining the behaviour (and for some
that counted as UB in all but name, a point I can see but which I
think confuses the use of the term UB).
C99 3.4.3:

undefined behavior

behavior, upon use of a nonportable or erroneous program construct
or of erroneous data, for which this International Standard
imposes no requirements

NOTE Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic of the environment (with or without the issuance of
a diagnostic message), to terminating a translation or execution
(with the issuance of a diagnostic message).

EXAMPLE An example of undefined behavior is the behavior on
integer overflow.

C99 4p2:

If a shall or shall not requirement that appears outside of a
constraint is violated, the behavior is undefined. Undefined
behavior is otherwise indicated in this International Standard by
the words undefined behavior or by the omission of any explicit
definition of behavior. There is no difference in emphasis among
these three; they all describe behavior that is undefined.
As I understand it, that makes
the call implementation defined (which the standard also cannot
define, but requires the implementation to), which is not the same as
undefined.
Here's what the standard says about system() (C99 7.20.4.6):

If *string* is a null pointer, the *system* function determines
whether the host environment has a _command processor_. If
*string* is not a null pointer, the *system* function passes the
string pointed to by *string* to that command processor to be
executed in a manner which the implementation shall document; this
might then cause the program calling *system* to behave in a
non-conforming manner or to terminate.

The standard uses boldface (which I've represented as *...*) and
italics (which I've represented as _..._).

This doesn't actually say that the behavior of system() with a
non-null argument is undefined, but behaving "in a non-conforming
manner" seems to me to be about as undefined as you can get.

Of course, an implementation is free to document the behavior.

[...]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 3 '08 #30

P: n/a
On Sun, 29 Jun 2008 13:52:08 -0400, CBFalconer <cb********@yahoo.com>
wrote:
Jrdman wrote:

can any one write a C code that search for files in a directory
without using the windows apis(FindFirstFile() and FindNextFile())
or even has a small idea on how to do that.

No. There is no reason to assume directories exist on a file
system. As an example, consider the CP/M-80 file system. Which
supported a lot of software.
That didn't have multiple (user or hierarchical) directories, but it
did have A (single, one) directory, which is all the OP asked for. I'm
pretty sure it didn't have an 'API' (then just an OS function number)
to enumerate the directory. Which as I recall was at a fixed location
and definitely in a fixed format, so easy enough to read on your own.

RT-11 similarly had a single directory per volume, in a fixed format
at a fixed location (block 6 IIRC), and no API. Heck, I remember
patching damaged RT-11 dirs/volumes with DDT or equivalent.

And 'a lot' of software is arguable. Even for its day, compared to
larger machines then existing. _Enough_ software, I'd agree.

- formerly david.thompson1 || achar(64) || worldnet.att.net
Jul 14 '08 #31

This discussion thread is closed

Replies have been disabled for this discussion.