C Program [ Turbo-C ] , to extract only-Printable-characters from a file ( any type of file) and dis

S

SunRise

Hi

I am creating a C Program [ Turbo-C ] , to extract
only-Printable-characters from a file ( any type of file) and display
them.
OS: Windows-XP

Ple help me to fix the Errors & Warnings and explain how to use
Command-Line Arguments inside C program.

thanks
SunRise

--------------------------------------------------------
Warnings & Errors:

WARNING : Non-portable pointer compariosn in function main
Error(1) : Illegal structure operation in function main
Error(2) : Illegal structure operation in function main
Error(3) : Illegal structure operation in function main
Error(4) : type mismatch in parameter 'c' in call to "_fputc" in
function main*/

--------------------------------------------------------


#include <stdio.h>
#include <ctype.h>
#include <process.h>


void main()
{

/*char *file1 = argv[1]; */

FILE *fp1;

fp1=fopen("c:\\tmp\\tmp\\CPUCount20.exe","r");

if ( fp1 == NULL ) /* WARNING is here */
{
/* printf("Error opening file : %s\n\n", file1); */
printf("Exiting ...\n");
exit(1) ;
}

while( fp1 != EOF )
{

if( isprint(*fp1) ) /* Error(1) & Error(2) */
{
putc(*fp1,stdout); /* Error(3) & Error(4) */
}
fp1++;
}


printf(" ======= End of strings1 ======== \n\n");


}
 
C

CBFalconer

SunRise said:
I am creating a C Program [ Turbo-C ] , to extract
only-Printable-characters from a file ( any type of file) and
display them.
OS: Windows-XP

Ple help me to fix the Errors & Warnings and explain how to use
Command-Line Arguments inside C program.

Turbo-C is a 16 bit DOS program, and generally usable on DOS.
However it doesn't know anything about long file names (anything
over the 8.3 mark) and WinXP has deliberately crippled the DOS
operation in order to sell more software :-( However the DJGPP
system is available for all these problems - see
<http://www.delorie.com>.

There, among other things, you will find binutils available. After
installing that you will find the strings command to be available.
You can also get the GNU source, together with whatever patches
were needed to function under DJGPP. gcc comes with it all.

For examples of source using the command line for parameters, just
snoop about my download section. See:

<http://cbfalconer.home.att.net/download>
 
E

Emmanuel Delahaye

SunRise wrote on 02/07/05 :
#include <stdio.h>
#include <ctype.h>
#include <process.h>

Not standard. Use said:
void main()

main() returns int. Always.
FILE *fp1;

fp1=fopen("c:\\tmp\\tmp\\CPUCount20.exe","r");

If you intend to read a binary file (made of characters 0-255), use
"rb" instead.
while( fp1 != EOF )

Please read a C-book. The files functions are fgetc(), fgets() etc. And
don't forget fclose() when finished...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++
 
O

Old Wolf

Emmanuel said:
SunRise wrote on 02/07/05 :


main() returns int. Always.

main() may have any number of implementation-defined return types
and parameter lists, as long as two of them are "int main(void)"
and "int main(int, char **)".

In fact the OP's implementation defines "void main(void)" as
a valid form of main.
 
L

Lawrence Kirby

main() may have any number of implementation-defined return types
and parameter lists, as long as two of them are "int main(void)"
and "int main(int, char **)".

But anything other than these two, or forms compatible with them are not
supported by standard C. The "implementation-defined" bit is also a
C99ism, not that it makes a great deal of difference.
In fact the OP's implementation defines "void main(void)" as
a valid form of main.

Does it define it formally as an extension or just use it in code
examples? But even if it does that doesn't make the construct valid C,
just valid for that implementation.

Lawrence
 
O

Old Wolf

Lawrence said:
Does it define it formally as an extension or just use it in code
examples? But even if it does that doesn't make the construct valid C,
just valid for that implementation.

Well, does the Standard define how an implementation must
define its implementation-defined behaviours? :)
Anyway, I think this qualifies as an exception to "Always",
as Emmanuel Delahaye wrote.
The "implementation-defined" bit is also a C99ism

So C89 did not permit void main() at all?
 
L

Lawrence Kirby

Well, does the Standard define how an implementation must
define its implementation-defined behaviours? :)

C99 says "or in some other implementation-defined manner". The key thing
about "implementation-defined" is that the implementation must document
it. So C99 formalises the idea that aform of main() is valid on an
implementaton not because it "happend to work" but because the the
implementation documents it as an extension.
Anyway, I think this qualifies as an exception to "Always",
as Emmanuel Delahaye wrote.

In the context of standard C, the topic of this newsgroup, "Always" is
correct. OK I see an argument that the bit from C99 above legitimises
documented extensions. I don't like this though because the standard
doesn't constrain the bahaviour of implementation-defined forms, you
effectively have undefined behaviour under an implementation-defined
label. This goes against the nature of the term "implementation-defined"
which usually gives the implementation a restricted choice of possible
behaviours. The bottom line is that C99 doesn't specify any behaviour for
void main(void) and in my book that makes void main(void) an invalid
construct in C99.
So C89 did not permit void main() at all?

It simply has undefined behaviour in C89. That permits an implementation
to support it as an extension but it is very clearly not part of the C89
language.

Lawrence
 
S

S.Tobias

Lawrence Kirby said:
C99 says "or in some other implementation-defined manner". The key thing
about "implementation-defined" is that the implementation must document
it. So C99 formalises the idea that aform of main() is valid on an
implementaton not because it "happend to work" but because the the
implementation documents it as an extension.


In the context of standard C, the topic of this newsgroup, "Always" is
correct. OK I see an argument that the bit from C99 above legitimises
documented extensions. I don't like this though because the standard
doesn't constrain the bahaviour of implementation-defined forms, you
effectively have undefined behaviour under an implementation-defined
label. This goes against the nature of the term "implementation-defined"
which usually gives the implementation a restricted choice of possible
behaviours. The bottom line is that C99 doesn't specify any behaviour for
void main(void) and in my book that makes void main(void) an invalid
construct in C99.

I don't understand what is "undefined" about `void main(void)', would
you please expand on that? ISTM that in defining behaviour the Std
does not distinguish between different `main' forms, and defines it
only where applicable; in `void main(void)' case, the termination
status is (explicitly) unspecified.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top