«

I need to help in my assignment. I need to wrap a text with the
following indications:
1.If you have reached the end of the line (number of characters on this
line >= 40) AND you have reached the end of the current word, start a
new line and reset the number of characters on the line to 0. The end
of a word will be denoted by one of these: blank space, '\n',
'.', ',' or ';'.

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

main()
{
FILE *fp1,*fp2; //fp1 input file, fp2 output file
char filename[30]; //filename character and x is character
char line[80];
char x;
int count=0; // count the line of the file 1
int j=0; //count of character of file 2

printf("Enter the filename to be scanned: "); // ask the user
scanf("%s", filename);

fp1= fopen(filename, "r"); //open input file,read-only
fp2= fopen("output.txt", "w"); //open outp file,write-only

while((x=getc(fp1))!=EOF) //get next char from input file, store
in x
{


if(x=='\n' || x=='*') //count the lines of the file1
count++;


if(x=='\n') //separete words

putc(' ' ,fp2);

else if(x=='*'){ //new line with an indentation \t

putc('\t',fp2);


}
else if(x!='*') //delete *
{



j++;

putc(x,fp2); //output file

//Begin the Wrap up text but I have problem here. Help!!!
if((j>=40) && (x==' ' || x==';' || x=='.' || x==',' || x=='\n'))

do{
putc('\n',fp2); //start new line
count1++;
j=0;
}while(j!=0);
if(x=='\n')
putc('\n',fp2);
}



}

In article <. com>,
FUGATO <> wrote:
>I need to help in my assignment.

>1.If you have reached the end of the line (number of characters on this
>line >= 40) AND you have reached the end of the current word, start a
>new line and reset the number of characters on the line to 0. The end
>of a word will be denoted by one of these: blank space, '\n',
>'.', ',' or ';'.

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

>main()

Minus 1 point for not using integer main(void)

>{
> FILE *fp1,*fp2; //fp1 input file, fp2 output file

Noted: C99 style comments, not valid in C89.

> char filename[30]; //filename character and x is character
> char line[80];
> char x;
> int count=0; // count the line of the file 1
> int j=0; //count of character of file 2
>
> printf("Enter the filename to be scanned: "); // ask the user

Minus 1 point for not ending the prompt with '\n' and another for
not using fflush() to ensure that the prompt will be displayed before the
read.

> scanf("%s", filename);

Automatic 2 grade-letter deduction using scanf() to read a string you
don't control the size of. What happens if the user enters a 35
character filename?

Minus 1 point for using scanf("%s") to read a filename that might
contain a blank. The %s format skips leading whitespace, then reads
consequative non-whitespace, stopping at the first whitespace. That's
not going to be able to handle a filename such as

C:\Program Files\Fugato\WordWrap.data

> fp1= fopen(filename, "r"); //open input file,read-only

Minus 1 point for not checking that the input file was opened properly.

> fp2= fopen("output.txt", "w"); //open outp file,write-only

Minus 1 point for not checking that the out file was opened properly.

> while((x=getc(fp1))!=EOF) //get next char from input file, store

Minus 1 point for assigning the result of getc() to a char variable
that might be unsigned and thus not able to store a value equal to
EOF (which is certain to be negative.)

>in x
> {
>
>
> if(x=='\n' || x=='*') //count the lines of the file1
> count++;

Minus 1 point for using the magic test against '*' which is not
documented in the requirements as being one of the special characters
to be tested for.

Minus 1 point for counting * as indicating the end of a line -- it
isn't. If there was a special requirement that it be treated
as a newline, then instead minus 1 point for not fully stating
the requirements.

>
> if(x=='\n') //separete words

Typo in comment. Noted but we'll let it go this time.

>
> putc(' ' ,fp2);

Minus 1 point for bug of assuming that end of line in the
input will always result in a space in the output file. If you've
reached the natural end of a word and you are over the column
limit, then there should not be a space emitted before the output
lineline.

> else if(x=='*'){ //new line with an indentation \t
>
> putc('\t',fp2);

Minus 3 points: 1 for not adjusting the character count to take
into account the indentation; 1 for not documenting
what the indentation size is nor allowing the user to control
the indentation; and 1 for outputting indentation even if there is
no further output to go on the line (e.g., end of file.)

>
> }
> else if(x!='*') //delete *

Minus 1 point for redundant condition: if x was '\n' or '*' then
you could not have gotten here through the chain of if/else
so testing for non-'*' is unnecessary.

> {
>
> j++;
>
> putc(x,fp2); //output file
>
>//Begin the Wrap up text but I have problem here. Help!!!
> if((j>=40) && (x==' ' || x==';' || x=='.' || x==',' || x=='\n'))

Minus 1 point for not recognizing that x cannot be '\n' here because
of the if/else chains.

>
> do{
> putc('\n',fp2); //start new line
> count1++;

Minus 3 points for using an undeclared variable (count1). This would
not compile, so you have submitted an answer which is not the one
you have actually run: minus 7 points for that.

> j=0;
> }while(j!=0);

Minus 1 point for not recognizing that j will always be 0 after the
do{}, so the while() condition is not useful, and the construct
should just be replaced with a plain statement block {}.

> if(x=='\n')

x cannot be '\n' here, but we already docked you for that.

> putc('\n',fp2);

On the other hand, this would get you a double newline on output if you
did manage to get here, so that's another logic bug and another
point docked.
> }

Minus 1 point for failing to return an exit status to the
operating system, which is recommended for C89 programs.

Minus another point for failing to return an exit status to the
operating system, which is mandatory for C99 programs. We know
that you are using C99 because of the comment style. If you wish
to claim that you should not be docked here because you are using
C89 and returning a value is optional for C89, then you will
instead be docked for using C99 style comments in a C89 program.


Minus 1 point for failing to ensure that the text file fp2 ends
in a newline.

Minus 1 point for failing to close the input and output files.

Minus 1 point for not using the result of counting the lines.
If you don't use the count, then don't do the count.

Minus 1 point for not using the declared array 'line'.
> }

--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)

On 2006-03-03, Walter Roberson <> wrote:
> Minus 1 point for not using integer main(void)

I guess you mean "int", there is no type named "integer" that I know
of

> Minus 1 point for failing to return an exit status to the
> operating system, which is recommended for C89 programs.
>
> Minus another point for failing to return an exit status to the
> operating system, which is mandatory for C99 programs. We know
> that you are using C99 because of the comment style. If you wish
> to claim that you should not be docked here because you are using
> C89 and returning a value is optional for C89, then you will
> instead be docked for using C99 style comments in a C89 program.

If I'm not mistaken you got this backwards.
C89 I believe required an explicit return statement at the end of main,
while C99 does not.

5.1.2.2.3 Program Termination
"reaching the } that terminates the main function returns a value of 0"

> Minus 1 point for failing to close the input and output files.

That's more of an issue of style and hardly grounds for removing points,
as all open files are closed upon program exit.

7.19.3 Files
5) "... If the main function returns to its original caller or if the
exit function is called, all open files are closed (hence all output
streams are flushed) before program termination."

> Minus 1 point for not using the result of counting the lines.
> If you don't use the count, then don't do the count.

Minus 1 point for keeping a point counter during your whole reply, and
not telling us the final count at the end


--
John Tsiombikas (Nuclear / Mindlapse)

http://nuclear.demoscene.gr/

(Walter Roberson) writes:
> In article <. com>,
> FUGATO <> wrote:
[...]
>> printf("Enter the filename to be scanned: "); // ask the user
>
> Minus 1 point for not ending the prompt with '\n' and another for
> not using fflush() to ensure that the prompt will be displayed before the
> read.

With a call to fflush(stdout) after the printf(), a newline is not
necessary. (In fact, I prefer not to have a newline at the end of a
prompt; it makes things clearer to the user.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

"John Tsiombikas (Nuclear / Mindlapse)" <> writes:
> On 2006-03-03, Walter Roberson <> wrote:
[...]
>> Minus 1 point for failing to close the input and output files.
>
> That's more of an issue of style and hardly grounds for removing points,
> as all open files are closed upon program exit.

Style issues can certainly be grounds for removing points; after all,
good style is one of the things we're trying to teach.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

In article <>,
Keith Thompson <kst-> wrote:
> (Walter Roberson) writes:
>> In article <. com>,
>> FUGATO <> wrote:

>>> printf("Enter the filename to be scanned: "); // ask the user

>> Minus 1 point for not ending the prompt with '\n' and another for
>> not using fflush() to ensure that the prompt will be displayed before the
>> read.

>With a call to fflush(stdout) after the printf(), a newline is not
>necessary.

For text files, the status of the last line is officially indeterminate
if there is no newline at the end of the line. fflush() does not
introduce that newline: it just spills the accumulated buffer.
Hence to be -sure- that prompt will be visible, you must terminate
it with a newline.

>(In fact, I prefer not to have a newline at the end of a
>prompt; it makes things clearer to the user.)

Yeah, but it relies upon system-specific behaviour.

Though this discussion does lead to the question of whether
stdout is a text stream or a binary stream ?
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

(Walter Roberson) writes:
> In article <>,
> Keith Thompson <kst-> wrote:
>> (Walter Roberson) writes:
>>> In article <. com>,
>>> FUGATO <> wrote:
>
>>>> printf("Enter the filename to be scanned: "); // ask the user
>
>>> Minus 1 point for not ending the prompt with '\n' and another for
>>> not using fflush() to ensure that the prompt will be displayed before the
>>> read.
>
>>With a call to fflush(stdout) after the printf(), a newline is not
>>necessary.
>
> For text files, the status of the last line is officially indeterminate
> if there is no newline at the end of the line. fflush() does not
> introduce that newline: it just spills the accumulated buffer.
> Hence to be -sure- that prompt will be visible, you must terminate
> it with a newline.

Only if it's the last line of output.

>>(In fact, I prefer not to have a newline at the end of a
>>prompt; it makes things clearer to the user.)
>
> Yeah, but it relies upon system-specific behaviour.
>
> Though this discussion does lead to the question of whether
> stdout is a text stream or a binary stream ?

It's a text stream.

C99 7.19.1p3:

stderr
stdin
stdout

which are expressions of type "pointer to FILE" that point to the
FILE objects associated, respectively, with the standard error,
input, and output streams.

C99 7.19.3p7:

At program startup, three text streams are predefined and need not
be opened explicitly -- _standard input_ (for reading conventional
input), _standard output_ (for writing conventional output), and
_standard error_ (for writing diagnostic output). As initially
opened, the standard error stream is not fully buffered; the
standard input and standard output streams are fully buffered if
and only if the stream can be determined not to refer to an
interactive device.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

On Fri, 3 Mar 2006 06:01:43 UTC, "John Tsiombikas (Nuclear /
Mindlapse)" <> wrote:

> > Minus 1 point for failing to close the input and output files.
>
> That's more of an issue of style and hardly grounds for removing points,
> as all open files are closed upon program exit.

Noways, failing to close the files is failing any chance to dedect
errors. Econ fclose() will return an error indicator showing that data
is not written and/or that the filecan't simply closed at all because
some error on the target device hinders that.

> 7.19.3 Files
> 5) "... If the main function returns to its original caller or if the
> exit function is called, all open files are closed (hence all output
> streams are flushed) before program termination."

Yeah - but what is when the last byte can't been written to the file
because device is full, gets crashed....? What is when the underlying
system is unable to write the management information to the file? A
failsave application will inform the user about any critical error
that it can not recover from itself.

So -30 points to the OP by leaving off each and any error handling.
-3,000 points to you by giving false hints to the OP and to the
community.


--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

On 2006-03-04, Herbert Rosenau <> wrote:
>
> On Fri, 3 Mar 2006 06:01:43 UTC, "John Tsiombikas (Nuclear /
> Mindlapse)" <> wrote:
>
>> > Minus 1 point for failing to close the input and output files.
>>
>> That's more of an issue of style and hardly grounds for removing points,
>> as all open files are closed upon program exit.
>
> Noways, failing to close the files is failing any chance to dedect
> errors.

I agree, still it's perfectly valid for a C program to not close them
explicitly.

> Econ fclose() will return an error indicator showing that data
> is not written and/or that the filecan't simply closed at all because
> some error on the target device hinders that.
.... snip ...
> A failsave application will inform the user about any critical error
> that it can not recover from itself.

The stream (FILE*) *will* be closed, regardless of what the OS does with
the actual file.
Your point is just that you miss a chance to provide an error message to
the user (or error code to the caller) that some of the data may have
not being written. While this is a very good practice, and I definitely
want to encourage it, however the OP's program was not *wrong* in this
respect, just not very user-friendly.

> So -30 points to the OP by leaving off each and any error handling.
> -3,000 points to you by giving false hints to the OP and to the
> community.

Charming ...

--
John Tsiombikas (Nuclear / Mindlapse)

http://nuclear.demoscene.gr/