String manipulation program not returning expected output

[Logan Lee]

Hi. I've written a small program to learn to write in C. But unfortunately the output is all jumbled up and not nice.


/* read_file.c
The whole point of this code is to read the entire content from a file then arrange the data as a single string. */

#include <stdio.h>

char* returnArrayFromFile(char* file_name) {
// Try opening a file
FILE *text_file=fopen(file_name,"r");

// Total number of characters in the file.
int m=0;
while(feof(text_file)==0) {
fgetc(text_file); m++;
}
fclose(text_file);
fopen("text_file","r");

char file_content[m];

int i=0;
while(i<m) {
fscanf(text_file, "%c", &file_content[i++]);
}

fclose(text_file);

return file_content;
}


/* substring.c
Return B from ABC */
char* getSubstring(char* larger, int a, int b) {
char* smaller=(char *)malloc(sizeof(char) * b);
int i;
for(i=0; i<b; i++) {
if (larger[a+i]=='\0') {
break;
}
smaller=larger[a+i];
}
return smaller;
}

/* main.c */
#include "read_file.h"
#include "substring.h"

int main(int argc, char* argv[]) {
char* file_name=argv[1];
int a=atoi(argv[2]);
int b=atoi(argv[3]);
char* larger=returnArrayFromFile(file_name);
char* smaller=getSubstring(larger, a, b);
printf("%s", smaller);
}

/* Lastly, text_file */
abcdefghi

If I compile them with gcc *.c -o main and execute by

main text_file 3 3

I'm expecting the output

def

But I'm getting others with jumbled characters.

 

[Logan Lee]

Hi. I've written a small program to learn to write in C. But unfortunately the output is all jumbled up and not nice.


/* read_file.c
The whole point of this code is to read the entire content from a file then arrange the data as a single string. */

#include <stdio.h>

char* returnArrayFromFile(char* file_name) {
// Try opening a file
FILE *text_file=fopen(file_name,"r");

// Total number of characters in the file.
int m=0;
while(feof(text_file)==0) {
fgetc(text_file); m++;
}
fclose(text_file);
fopen("text_file","r");

char file_content[m];

int i=0;
while(i<m) {
fscanf(text_file, "%c", &file_content[i++]);
}

fclose(text_file);

return file_content;
}


/* substring.c
Return B from ABC */
char* getSubstring(char* larger, int a, int b) {
char* smaller=(char *)malloc(sizeof(char) * b);
int i;
for(i=0; i<b; i++) {
if (larger[a+i]=='\0') {
break;
}
smaller=larger[a+i];
}
return smaller;
}

/* main.c */
#include "read_file.h"
#include "substring.h"

int main(int argc, char* argv[]) {
char* file_name=argv[1];
int a=atoi(argv[2]);
int b=atoi(argv[3]);
char* larger=returnArrayFromFile(file_name);
char* smaller=getSubstring(larger, a, b);
printf("%s", smaller);
}

/* Lastly, text_file */
abcdefghi

If I compile them with gcc *.c -o main and execute by

main text_file 3 3

I'm expecting the output

def

But I'm getting others with jumbled characters.

I forgot to include header files but they are obvious from the code given.

 

[krishan]

int m=0;

while(feof(text_file)==0) {
fgetc(text_file); m++;
}
fclose(text_file);
fopen("text_file","r");

-->>>>>>> char file_content[m];

Which compiler are u using?
The highlighted line makes me suspicious. can u do that ?

 

[krishan]

int m=0;
while(feof(text_file)==0) {
fgetc(text_file); m++;
}
fclose(text_file);
fopen("text_file","r");

-->>>>>>> char file_content[m];

Which compiler are u using?
The highlighted line makes me suspicious. can u do that ?

WOW gcc allows me to do that.....

 

[pete]

int m=0;
while(feof(text_file)==0) {
fgetc(text_file); m++;
}
fclose(text_file);
fopen("text_file","r");

-->>>>>>> char file_content[m];

Which compiler are u using?
The highlighted line makes me suspicious. can u do that ?

In C99, yes.
In C89, no.

 

[Flash Gordon]

Logan Lee wrote, On 15/12/07 02:08:

Hi. I've written a small program to learn to write in C. But unfortunately the output is all jumbled up and not nice.


/* read_file.c
The whole point of this code is to read the entire content from a file then arrange the data as a single string. */

#include <stdio.h>

char* returnArrayFromFile(char* file_name) {
// Try opening a file
FILE *text_file=fopen(file_name,"r");

// Total number of characters in the file.
int m=0;
while(feof(text_file)==0) {

This is classic incorrect usage of feof. See the FAQ at
http://c-faq.com/ specifically question 12.2

fgetc(text_file); m++;

It might be slightly better to use getc since text_file does not have a
side effect. getc is allowed to be a macro with a lot of freedom and so
can make it easier for the compiler to do optimisation.

}
fclose(text_file);
fopen("text_file","r");

char file_content[m];

You can only do this in C99, which is not fully implemented by most
compilers. So whilst correct it limits the portability of your code.

More seriously, you have not left space for a null termination of the
string.

int i=0;
while(i<m) {
fscanf(text_file, "%c", &file_content[i++]);

Why on earth are you using fscanf? Use getc (or fgetc).

}

You do not nul terminate your string so you cannot use standard string
functions on it.

fclose(text_file);

return file_content;

This is wrong. See question 7.5a of the comp.lang.c FAQ. I believe this
problem was pointed out to you recently with reference to another function.

}


/* substring.c
Return B from ABC */
char* getSubstring(char* larger, int a, int b) {

Use sensible parameter names to people know what the parameters are
meant to be without reading the function body.

char* smaller=(char *)malloc(sizeof(char) * b);

Scrap the cast, and sizeof(char) is 1 by *definition*.
char *smaller=malloc(b);
Then the compiler will complain at you (if it isn't already). The
solution to the error/warning is *not* adding a cast, it is including
stdlib.h to provide the correct prototype for malloc.

int i;
for(i=0; i<b; i++) {
if (larger[a+i]=='\0') {
break;
}
smaller=larger[a+i];
}
return smaller;

Again you have not nul terminated your data (you have no space for the
nul termination) so you cannot use C string functions on the returned data.

}

/* main.c */
#include "read_file.h"
#include "substring.h"

If these headers are wrong they can also break things.

int main(int argc, char* argv[]) {
char* file_name=argv[1];

What if the user does not provide any parameters? BANG!

int a=atoi(argv[2]);
int b=atoi(argv[3]);

Validate your input. What if the user enters "-5" or "fred" or "a" is
bigger than the size of the file.

char* larger=returnArrayFromFile(file_name);
char* smaller=getSubstring(larger, a, b);
printf("%s", smaller);

smaller is not nul terminated so you cannot print it. Also you need to
terminate the last line of your printout with a new line to ensure
correct behaviour.

main is defined as returning an int, so return one. 0, EXIT_SUCCESS and
EXIT_FAILURE are the values the standard guarantees, 0 being success.

}

/* Lastly, text_file */
abcdefghi

If I compile them with gcc *.c -o main and execute by

<snip>

Add at least "-ansi -pedantic" or "-std=c99 -pedantic" to your options.
It would be better to add "-Wall -Wextra" as well.

 

[Rod Pemberton]

Hi. I've written a small program to learn to write in C. But unfortunately

the output is all jumbled up and not nice.

....
I'm expecting the output

def

But I'm getting others with jumbled characters.

There are numerous issues, but the reason your getting "jumbled" characters
is due to the way you dynamically allocate space for file_content.

/* read_file.c
The whole point of this code is to read the entire content from a file

then arrange the data as a single string. */

#include <stdio.h>

I treated all three routines as one file and needed these includes for my
suggested changes:

#include <stdlib.h>

char* returnArrayFromFile(char* file_name) {
// Try opening a file
FILE *text_file=fopen(file_name,"r");

There's non-obvious coding error here interacting with the rest of the
program. It has to due with the character(s) '\n'... I don't expect you to
understand this. Anyway, you'll want to use "rb" instead of "r". In fact,
you'll save yourself much grief if you just learn to avoid non-binary modes
as much as possible. So, use this:
FILE *text_file=fopen(file_name,"rb");

// Total number of characters in the file.
int m=0;
while(feof(text_file)==0) {
fgetc(text_file); m++;
}

The while loop is equivalent to using fseek() and ftell():
fseek(text_file,0L,SEEK_END);
m=ftell(text_file);

fclose(text_file);
fopen("text_file","r");

The fopen line is erroneous. You meant file_name instead of "text_file".
Again, you'll need "rb" instead of "r":
fopen(file_name,"rb");

char file_content[m];

The declaration of file_content has two errors. The first is that the scope
of the storage is limited to returnArrayFromFile(), i.e., you can't use the
storage outside of returnArrayFromFile()... You want to use malloc(). The
second error is an off by one. You need to allocate m+1 since you need to
ensure that the array in main(), called larger, has an additional character
so it can be nul terminated. You want this:
char *file_content=malloc(m+1);

int i=0;
while(i<m) {
fscanf(text_file, "%c", &file_content[i++]);
}

This while loop is equivalent to a call to fread(). one(1) in the following
is the size which is sizeof(char), i.e., one(1).
fread(file_content,1,m,text_file);

fclose(text_file);

return file_content;
}


/* substring.c
Return B from ABC */
char* getSubstring(char* larger, int a, int b) {
char* smaller=(char *)malloc(sizeof(char) * b);

There are two errors in the malloc of smaller. The first is that the cast
on malloc is unecessary, an obsolete coding style, and some say prevents
locating certain errors. The second is that it too is off by one. You'll
need an additional character for the nul. Also, the sizeof(char) is always
one(1). You want this:
char* smaller=malloc(b+1);

int i;
for(i=0; i<b; i++) {
if (larger[a+i]=='\0') {
break;
}
smaller=larger[a+i];
}

There is a coding error in the loop. You are checking for nul, '\0', but
you never set a nul in larger or file_content... One doesn't exist in the
text file. I believe, but didn't thoroughly check, that the if()-break
should be after the smaller=larger statement to copy the nul, _if_ it had
been there... Anyway, the for loop can be reworked to the following which
nul terminates both larger and smaller.

larger[a+b]='\0';
strcpy(smaller,&larger[a]);

return smaller;
}

/* main.c */
#include "read_file.h"
#include "substring.h"

int main(int argc, char* argv[]) {
char* file_name=argv[1];
int a=atoi(argv[2]);
int b=atoi(argv[3]);
char* larger=returnArrayFromFile(file_name);
char* smaller=getSubstring(larger, a, b);
printf("%s", smaller);
}

/* Lastly, text_file */
abcdefghi

If I compile them with gcc *.c -o main and execute by

If you rework the C99 features to C90, declarations at the top of the
procedure, no C++ comments, no dynamic allocations, then you can increase
the level of warnings to detect problems:
gcc -Wall -ansi -pedantic *.c -o main

Anyway there are other issues you need to look into:
1) not checking that malloc returned space
2) missing return(0) or exit(EXIT_SUCCESS) for main()
3) strtod,strtol,strtoul have fewer side effects than atoi
4) assumed passed in parameters are the correct type


Rod Pemberton

 

[Keith Thompson]

There's non-obvious coding error here interacting with the rest of the
program. It has to due with the character(s) '\n'... I don't expect you to
understand this.

Perhaps you'd care to explain it, because I don't understand it
either.

Anyway, you'll want to use "rb" instead of "r". In fact,
you'll save yourself much grief if you just learn to avoid non-binary modes
as much as possible. So, use this:
FILE *text_file=fopen(file_name,"rb");

[...]

That's bad advice. Use "r" if you want to read a text file; use "rb"
if you want to read a file in binary mode.

It's possible that the OP would be better off using binary mode,
depending on exactly what he's trying to do, but it's by no means
certain, especially given the name "text_file".

 

[William Pursell]

Hi. I've written a small program to learn to write in C. But unfortunately the output is all jumbled up and not nice.

/* read_file.c
The whole point of this code is to read the entire content from a file then arrange the data as a single string. */

#include <stdio.h>

char* returnArrayFromFile(char* file_name) {
// Try opening a file
FILE *text_file=fopen(file_name,"r");

You need to check that fopen was successful.

// Total number of characters in the file.
int m=0;
while(feof(text_file)==0) {
fgetc(text_file); m++;
}
fclose(text_file);

It is not necessary to precompute the size of
the file. It would be a good exercise to
allocate a buffer, read into it, and resize
it if you don't reach eof. If you do feel
it appropriate to pre-compute the size of
the file, it may be a good idea to do it
non-portably and use features of the OS,
such as a call to stat. It would definitely
be a good idea to put it in a function.

fopen("text_file","r");

That's odd. I thought we were given a name in
file_name, but now you seem to be reading from
a file with the hard coded name "text_file"...except
that you are discarding the result of the fopen().

char file_content[m];

int i=0;
while(i<m) {
fscanf(text_file, "%c", &file_content[i++]);
}

Ack. What's wrong with fread()? Putting
fscanf inside a loop like this is...really weird.
Especially considering that you are reading from
a FILE * that you already closed.

fclose(text_file);

return file_content;

}

/* substring.c
Return B from ABC */
char* getSubstring(char* larger, int a, int b) {
char* smaller=(char *)malloc(sizeof(char) * b);

Don't cast. Do check the return value.

int i;
for(i=0; i<b; i++) {
if (larger[a+i]=='\0') {
break;
}
smaller=larger[a+i];
}
return smaller;

}

/* main.c */
#include "read_file.h"
#include "substring.h"

int main(int argc, char* argv[]) {
char* file_name=argv[1];
int a=atoi(argv[2]);
int b=atoi(argv[3]);
char* larger=returnArrayFromFile(file_name);
char* smaller=getSubstring(larger, a, b);
printf("%s", smaller);

}

/* Lastly, text_file */
abcdefghi

If I compile them with gcc *.c -o main and execute by

main text_file 3 3

I'm expecting the output

def

But I'm getting others with jumbled characters.

You don't properly null terminate the value
created in getSubstring.

 

[Rod Pemberton]

Perhaps you'd care to explain it, because I don't understand it
either.

The details of the issue are beyond the OP's understanding at this point in
time. Further explanation, other than use "rb", would only confuse the
issues for him.

But as for you, Keith, stop being lazy. The code, both his and mine, are
available for you to work through. It'd behoove you to actually compile
some code for once in your life instead only coding C mentally...

Anyway, you'll want to use "rb" instead of "r". In fact,
you'll save yourself much grief if you just learn to avoid non-binary modes
as much as possible. So, use this:
FILE *text_file=fopen(file_name,"rb");

[...]

That's bad advice.

Without understanding the issue, your claim is suspect at best. At worst,
it's flat out wrong.


Rod Pemberton

 

[pete]

news:[email protected]... [...]
char* returnArrayFromFile(char* file_name) {
// Try opening a file
FILE *text_file=fopen(file_name,"r");

There's non-obvious coding error here interacting
with the rest of the program.
It has to due with the character(s) '\n'...
I don't expect you to understand this.

Perhaps you'd care to explain it,
because I don't understand it either.

The details of the issue are beyond
the OP's understanding at this point in time.
Further explanation, other than use "rb",
would only confuse the issues for him.

But as for you, Keith, stop being lazy.
The code, both his and mine,
are available for you to work through.
It'd behoove you to actually compile
some code for once in your life instead only coding C mentally...

I've posted more tested C code to this newsgroup
than I have posted English text,
and I don't know what you mean either.

I like working with text files.

 

[Keith Thompson]

news:[email protected]... [...]
char* returnArrayFromFile(char* file_name) {
// Try opening a file
FILE *text_file=fopen(file_name,"r");

There's non-obvious coding error here interacting with the rest
of the program. It has to due with the character(s) '\n'... I
don't expect you to understand this.

Perhaps you'd care to explain it, because I don't understand it
either.

The details of the issue are beyond the OP's understanding at this
point in time. Further explanation, other than use "rb", would only
confuse the issues for him.

But as for you, Keith, stop being lazy. The code, both his and
mine, are available for you to work through. It'd behoove you to
actually compile some code for once in your life instead only coding
C mentally...

I looked at the OP's code. Though it contains numerous errors (which
have already been discussed), it's clear enough what he's trying to
do. Opening the file in text mode makes perfect sense for what he's
doing.

He reads the contents of a file into a single string, then extracts a
specified substring (the file name and the substring bounds are
specified via command-line arguments), then he prints the substring.

On systems that distinguish between text mode and binary mode
(<OT>Windows does, Unix doesn't</OT>), opening the file in binary mode
would change the program's behavior. I see no basis for assuming that
the behavior seen in binary mode would be preferred.

It would be nice for the program's behavior to be specified more
precisely; a proper specification would settle the question of text
mode vs. binary mode.

Anyway, you'll want to use "rb" instead of "r".
In fact, you'll save yourself much grief if you just learn to
avoid non-binary modes as much as possible. So, use this: FILE
*text_file=fopen(file_name,"rb");

[...]

That's bad advice.

Without understanding the issue, your claim is suspect at best. At
worst, it's flat out wrong.

I understand the difference between text mode and binary mode. I
don't understand what "issue" you're talking about. Until and unless
you choose to explain it to the rest of us, I'll simply advise the OP
(and everyone else) to ignore your advice.

If you're reading text files, you should use text mode.

 

[Philip Potter]

news:[email protected]... [...]
char* returnArrayFromFile(char* file_name) {
// Try opening a file
FILE *text_file=fopen(file_name,"r");
There's non-obvious coding error here interacting with the rest of the
program. It has to due with the character(s) '\n'... I don't expect you to
understand this.

Perhaps you'd care to explain it, because I don't understand it
either.

The details of the issue are beyond the OP's understanding at this point in
time. Further explanation, other than use "rb", would only confuse the
issues for him.

But as for you, Keith, stop being lazy. The code, both his and mine, are
available for you to work through. It'd behoove you to actually compile
some code for once in your life instead only coding C mentally...

Rod, you're the one being lazy by making assertions without backing them
up. I don't know what you're talking about, but I've a feeling it may
have to do with the crlf/cr/lf differences in text files between
operating systems. In this case, using text mode is the *correct* way to
handle these situations, unless you want to write an application which
should accept all three conventions rather than the local convention.

Anyway, you'll want to use "rb" instead of "r". In fact,
you'll save yourself much grief if you just learn to avoid non-binary modes
as much as possible. So, use this:
FILE *text_file=fopen(file_name,"rb");

[...]

That's bad advice.

Without understanding the issue, your claim is suspect at best. At worst,
it's flat out wrong.

Until you explain what your claim is, let alone justify that claim,
you'll win no arguments here. The only substantial claim you've made is
"avoid non-binary modes as much as possible". I can't think what
persuades you to think that is good advice.

 

[Bill Reid]

[...]
char* returnArrayFromFile(char* file_name) {
// Try opening a file
FILE *text_file=fopen(file_name,"r");
There's non-obvious coding error here interacting with the rest of the
program. It has to due with the character(s) '\n'... I don't expect you to
understand this.
Perhaps you'd care to explain it, because I don't understand it
either.

The details of the issue are beyond the OP's understanding at this point in
time. Further explanation, other than use "rb", would only confuse the
issues for him.

But as for you, Keith, stop being lazy. The code, both his and mine, are
available for you to work through. It'd behoove you to actually compile
some code for once in your life instead only coding C mentally...

Rod, you're the one being lazy by making assertions without backing them
up. I don't know what you're talking about, but I've a feeling it may
have to do with the crlf/cr/lf differences in text files between
operating systems. In this case, using text mode is the *correct* way to
handle these situations, unless you want to write an application which
should accept all three conventions rather than the local convention.

Anyway, you'll want to use "rb" instead of "r". In fact,
you'll save yourself much grief if you just learn to avoid non-binary modes
as much as possible. So, use this:
FILE *text_file=fopen(file_name,"rb");
[...]

That's bad advice.

Without understanding the issue, your claim is suspect at best. At worst,
it's flat out wrong.

Until you explain what your claim is, let alone justify that claim,
you'll win no arguments here. The only substantial claim you've made is
"avoid non-binary modes as much as possible". I can't think what
persuades you to think that is good advice.

He doesn't "think" anything, he's an insane looney troll. Problem
is, he's an insane looney troll that has several "enablers" among the
frequent posters here:

From: Richard Heathfield <[email protected]>
Subject: Re: rolling dice
Date: Sunday, October 15, 2006

Rod Pemberton said:

<lots, all snipped>

Rod, this is why I don't agree with the "party line" that claims you're a
troll. Okay, the subject of this discussion has long since stopped being
topical, but so what? Topics do drift. Okay, so you were close to losing
your temper with this guy once or twice, but so what? Tempers do sometimes
fray. Okay, so I wasn't all that interested in the subject matter, but so
what? We can't all be interested in everything.

Mostly, it was an excellent, well-reasoned, and good-tempered rebuttal.

Yeah, okay, so we don't always see eye to eye. But so what?

BTW I owe you an apology for a snide one-liner I posted rather thoughtlessly
- yesterday, I think. Sorry about that. I do try not to say such things,
but I don't always manage it.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

---end of archived post

In a merciful society, he'd be locked up for his own protection (and
I actually suspect he has been incarcerated at times, since I know that
other looney trolls on Usenet have breaks in their posting histories
that they've admitted were due to periods of institutionalization).

But in the cruel world of the Internet, we have out-and-out psychopaths
like the above who "goose" the loons, along with other personality types
who, while maybe well-meaning and reasonable, unwittingly reinforce
his unfortunate mental condition by engaging in unwarranted respectful
"discussion"...

The proper thing to do when you encounter a looney troll is to
succinctly correct their factual inaccuracies, point out the fact that
they are a looney troll, and move on...

 

[Philip Potter]

>>> [Something which I found questionable]

Until you explain what your claim is, let alone justify that claim,
you'll win no arguments here. The only substantial claim you've made is
"avoid non-binary modes as much as possible". I can't think what
persuades you to think that is good advice.

He doesn't "think" anything, he's an insane looney troll. Problem
is, he's an insane looney troll that has several "enablers" among the
frequent posters here:
[snip]

In a merciful society, he'd be locked up for his own protection (and
I actually suspect he has been incarcerated at times, since I know that
other looney trolls on Usenet have breaks in their posting histories
that they've admitted were due to periods of institutionalization).

See below.

But in the cruel world of the Internet, we have out-and-out psychopaths
like the above who "goose" the loons, along with other personality types
who, while maybe well-meaning and reasonable, unwittingly reinforce
his unfortunate mental condition by engaging in unwarranted respectful
"discussion"...

The proper thing to do when you encounter a looney troll is to
succinctly correct their factual inaccuracies, point out the fact that
they are a looney troll, and move on...

I thought I did succinctly argue with him (though there were few factual
inaccuracies because there were few facts.) You, on the other hand, have
accused him of being either a criminal or a lunatic. I prefer my method,
because I think treating everyone with respect, even when they don't
reciprocate, sets an example for a better Usenet.

Phil

 

[Barry Schwarz]

Hi. I've written a small program to learn to write in C. But unfortunately the output is all jumbled up and not nice.


/* read_file.c
The whole point of this code is to read the entire content from a file then arrange the data as a single string. */

#include <stdio.h>

char* returnArrayFromFile(char* file_name) {
// Try opening a file
FILE *text_file=fopen(file_name,"r");

// Total number of characters in the file.
int m=0;
while(feof(text_file)==0) {

This will cause you to attempt to read the next character after you
have already read the last. However, as a consequence of the law of
compensating errors, you actually needed file_content to be one larger
than the character count to hold the terminating '\0' which you forgot
to add.

fgetc(text_file); m++;
}
fclose(text_file);
fopen("text_file","r");

char file_content[m];

Unless you have C99, array dimensions must be constant and
declarations must precede statements.

int i=0;
while(i<m) {
fscanf(text_file, "%c", &file_content[i++]);
}

fclose(text_file);

return file_content;

file_content ceases to exist when the function returns. The return
statement actually returns the address of file_content but as soon as
the function ends this value becomes indeterminate by definition.

}


/* substring.c
Return B from ABC */
char* getSubstring(char* larger, int a, int b) {
char* smaller=(char *)malloc(sizeof(char) * b);
int i;
for(i=0; i<b; i++) {
if (larger[a+i]=='\0') {

Due to the error in returnArrayFromFile, this if can never be true.

break;
}
smaller=larger[a+i];

As a result, smaller is never a string.

}
return smaller;
}

/* main.c */
#include "read_file.h"
#include "substring.h"

int main(int argc, char* argv[]) {
char* file_name=argv[1];
int a=atoi(argv[2]);
int b=atoi(argv[3]);
char* larger=returnArrayFromFile(file_name);
char* smaller=getSubstring(larger, a, b);

You are not allowed to evaluate larger at this point. Doing so
invokes undefined behavior.

getSubstring allocates space. You should free it.

printf("%s", smaller);

Since smaller is not terminated, this also invokes undefined behavior.

}

/* Lastly, text_file */
abcdefghi

If I compile them with gcc *.c -o main and execute by

main text_file 3 3

I'm expecting the output

def

But I'm getting others with jumbled characters.

That's why it's called undefined behavior.


Remove del for email