473,396 Members | 1,907 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,396 software developers and data experts.

Portable EOL?

I have written the program below to just create and populate an html
file. I am running into a problem when viewing the created file in vi.
I am told by vi that the file does not have an end of line.

Here's the code:

int
main(int argc, char **argv) {

FILE *fd;
int x;

char buff[8196];
x = 0;

bzero(buff, sizeof(buff));

(void)strlcpy(buff,"<HTML>", sizeof(buff));

while (x < 1024) {
(void)strlcat(buff,"A",sizeof(buff));
x++;
}
(void)strlcat(buff, "</HTML>", sizeof(buff));

fd = fopen("test5.html", "w+");
if (fd == NULL)
errx(-1, "failed to open");
(void)fprintf(fd, "%s", buff);
(void)fclose(fd);
exit(EXIT_SUCCESS);
}

Now, vi will not warn about noeol if I change this line:

(void)fprintf(fd, "%s", buff);

to

(void)fprintf(fd, "%s\n", buff);

Where I am confused is that I thought streams automatically terminated
the file with an CR (0a) in a unix environment. What bothers me is
that the above would in theory make the code less portable. Am I
overlooking something?

Aug 19 '06 #1
13 2049
"bw*****@yahoo.com" <bw*****@yahoo.comwrites:
Now, vi will not warn about noeol if I change this line:

(void)fprintf(fd, "%s", buff);

to

(void)fprintf(fd, "%s\n", buff);

Where I am confused is that I thought streams automatically terminated
the file with an CR (0a) in a unix environment.
No, that's just wrong. The last line in a text stream needs to
be explicitly terminated with a new-line character.
--
"Programmers have the right to be ignorant of many details of your code
and still make reasonable changes."
--Kernighan and Plauger, _Software Tools_
Aug 19 '06 #2
On 19 Aug 2006 11:08:32 -0700, "bw*****@yahoo.com" <bw*****@yahoo.com>
wrote:
>I have written the program below to just create and populate an html
file. I am running into a problem when viewing the created file in vi.
I am told by vi that the file does not have an end of line.

Here's the code:

int
main(int argc, char **argv) {

FILE *fd;
int x;

char buff[8196];
x = 0;

bzero(buff, sizeof(buff));

(void)strlcpy(buff,"<HTML>", sizeof(buff));
Why a non-standard function? What does it do that you could not do
with strcpy or strncpy? Since the source string is only seven
characters, do you really want to process 8,196.
>
while (x < 1024) {
(void)strlcat(buff,"A",sizeof(buff));
x++;
}
(void)strlcat(buff, "</HTML>", sizeof(buff));
At this point, buff contains a six character header, 1024 copies of
the letter A, a seven character trailer, a sting terminating '\0', and
some 7000+ characters of no interest. At no point did you ever place
a '\n' in this array.
>
fd = fopen("test5.html", "w+");
if (fd == NULL)
errx(-1, "failed to open");
(void)fprintf(fd, "%s", buff);
Your file now contains the characters described above, up to but not
including the '\0'.
> (void)fclose(fd);
exit(EXIT_SUCCESS);
}

Now, vi will not warn about noeol if I change this line:

(void)fprintf(fd, "%s", buff);

to

(void)fprintf(fd, "%s\n", buff);
Your format string now includes an additional character which will get
written to the file immediately after your data.
>
Where I am confused is that I thought streams automatically terminated
the file with an CR (0a) in a unix environment. What bothers me is
If that were true, then multiple calls to fprintf could not be used to
build up a line from separate pieces.
>that the above would in theory make the code less portable. Am I
overlooking something?
Less portable than what? The \n is C's portable way of indicating
that the output should contain an end of line indicator at this point.
The run time library will perform the magic necessary for your system.
This may be an 0a for unix or 0a0d (or is it 0d0a) for windows. It
will be something completely different for my IBM mainframe depending
on whether the RECFM is U, V, or F. The point is it is portable. The
code doesn't have to care and the compiler doesn't care much, if at
all.
Remove del for email
Aug 19 '06 #3

Ben Pfaff wrote:
No, that's just wrong. The last line in a text stream needs to
be explicitly terminated with a new-line character.
Thanks. That is where I am wrong.

Are there any good reasons to use streams versus unix I/O besides
portability? I realize that if I use unix I/O I have to do my own
buffering,
but that's not a big deal.

Oh, the 8196 buffer was left over from re-writing this from unix I/O to
streams.
And strlcat is vastly superior to strcat and strncat.

Aug 19 '06 #4
<bw*****@yahoo.comwrote in message
>I have written the program below to just create and populate an html
file. I am running into a problem when viewing the created file in vi.
I am told by vi that the file does not have an end of line.

Here's the code:

int
main(int argc, char **argv) {

FILE *fd;
int x;

char buff[8196];
x = 0;

bzero(buff, sizeof(buff));

(void)strlcpy(buff,"<HTML>", sizeof(buff));

while (x < 1024) {
(void)strlcat(buff,"A",sizeof(buff));
x++;
}
(void)strlcat(buff, "</HTML>", sizeof(buff));

fd = fopen("test5.html", "w+");
if (fd == NULL)
errx(-1, "failed to open");
(void)fprintf(fd, "%s", buff);
(void)fclose(fd);
exit(EXIT_SUCCESS);
}

Now, vi will not warn about noeol if I change this line:

(void)fprintf(fd, "%s", buff);

to

(void)fprintf(fd, "%s\n", buff);

Where I am confused is that I thought streams automatically terminated
the file with an CR (0a) in a unix environment. What bothers me is
that the above would in theory make the code less portable. Am I
overlooking something?
So OSes might be a bit hazy about text files that don't end with a newline
character.
The C standard doesn't specify that fclose() will automatically append a
newline if missing, so the only sensible thing to do is to add it yourself.
All file systems will handle

fp = fopen("temp.txt", "w");
fprintf(fp, "Hello world\n");
fclose(fp);

in a sensible way. If you don't add the newline you may or may not cause
problems.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Aug 19 '06 #5
Ben Pfaff <bl*@cs.stanford.eduwrites:
"bw*****@yahoo.com" <bw*****@yahoo.comwrites:
>Now, vi will not warn about noeol if I change this line:

(void)fprintf(fd, "%s", buff);

to

(void)fprintf(fd, "%s\n", buff);

Where I am confused is that I thought streams automatically terminated
the file with an CR (0a) in a unix environment.

No, that's just wrong. The last line in a text stream needs to
be explicitly terminated with a new-line character.
More precisely, "Whether the last line requires a terminating new-line
character is implementation-defined." (C99 7.19.2p2)

<OT>
In Unix, there's nothing *inherently* wrong with having a text file
without a terminating new-line, but it's rarely what you want. vi
will most likely complain about it, emacs can be configured to behave
in any of several ways, and other utilities might or might not
misbehave in various ways.
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Aug 19 '06 #6
"bw*****@yahoo.com" <bw*****@yahoo.comwrites:
Ben Pfaff wrote:
>No, that's just wrong. The last line in a text stream needs to
be explicitly terminated with a new-line character.

Thanks. That is where I am wrong.

Are there any good reasons to use streams versus unix I/O besides
portability? I realize that if I use unix I/O I have to do my own
buffering, but that's not a big deal.
The question is, are there any good reasons to use Unix I/O rather
than standard C streams?

One good reason *not* to use Unix-specific I/O is that it's less
portable; there are some extra features, but I don't think you're
using any of them. Another good reason is that we don't discuss
system-specific features here.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Aug 19 '06 #7
On Sat, 19 Aug 2006 21:19:19 GMT, Keith Thompson <ks***@mib.orgwrote
in comp.lang.c:
Ben Pfaff <bl*@cs.stanford.eduwrites:
"bw*****@yahoo.com" <bw*****@yahoo.comwrites:
Now, vi will not warn about noeol if I change this line:

(void)fprintf(fd, "%s", buff);

to

(void)fprintf(fd, "%s\n", buff);

Where I am confused is that I thought streams automatically terminated
the file with an CR (0a) in a unix environment.
No, that's just wrong. The last line in a text stream needs to
be explicitly terminated with a new-line character.

More precisely, "Whether the last line requires a terminating new-line
character is implementation-defined." (C99 7.19.2p2)
Actually, in this particular case, this is not really relevant. It
has nothing to do with an "ordinary" text file, and everything to do
with the format of the particular file type he is writing.

The file he produces might or might not be a valid text file on his
platform. Even if it is, it is not a valid HTML file because it
violates the HTML standard. That standard, like the C standard for C
source files, requires that the last line of a file have a terminating
newline.
<OT>
In Unix, there's nothing *inherently* wrong with having a text file
without a terminating new-line, but it's rarely what you want. vi
will most likely complain about it, emacs can be configured to behave
in any of several ways, and other utilities might or might not
misbehave in various ways.
</OT>
Right, it is merely some HTML validation tool pointing out a violation
of the HTML standard.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Aug 20 '06 #8

Jack Klein wrote:
Actually, in this particular case, this is not really relevant. It
has nothing to do with an "ordinary" text file, and everything to do
with the format of the particular file type he is writing.

The file he produces might or might not be a valid text file on his
platform. Even if it is, it is not a valid HTML file because it
violates the HTML standard. That standard, like the C standard for C
source files, requires that the last line of a file have a terminating
newline.
My thought that streams automatically terminate with CR's followed by a
NULL value was incorrect. The file definitely does not follow the
requirements for the HTTP Protocol.

Now, since the string is a C string, I would follow the terminating new
line
with \0, right?

So following the C standard, I would be:

<text><\n><\0>

where the C standard just requires the string to be terminated with a
NULL value,
right?

Aug 20 '06 #9
"bw*****@yahoo.com" <bw*****@yahoo.comwrites:
Jack Klein wrote:
>Actually, in this particular case, this is not really relevant. It
has nothing to do with an "ordinary" text file, and everything to do
with the format of the particular file type he is writing.

The file he produces might or might not be a valid text file on his
platform. Even if it is, it is not a valid HTML file because it
violates the HTML standard. That standard, like the C standard for C
source files, requires that the last line of a file have a terminating
newline.

My thought that streams automatically terminate with CR's followed by a
NULL value was incorrect. The file definitely does not follow the
requirements for the HTTP Protocol.

Now, since the string is a C string, I would follow the terminating new
line
with \0, right?

So following the C standard, I would be:

<text><\n><\0>

where the C standard just requires the string to be terminated with a
NULL value,
right?
Um, no.

First of all, you're misusing the word NULL. NULL is a macro, defined
in <stddef.h>, that expands to a null pointer constant. It is *not*
the same thing as a null character, '\0' (sometimes called NUL).

A C string, stored in memory, is terminated by a trailing '\0'
character. A text file consists of a sequence of lines, where each
line is terminated by an end-of-line marker that appears as '\n' when
you read or write it in a C program. Text files normally do not
contain null characters.

For example:

char s[] = "hello, world";
/*
* The compiler implicitly adds a '\0' to the end of s, making it
* a valid string.
*/
fprintf(some_file, "%s\n", s);
/*
* This writes the characters of s, *not* including the trailing
* '\0', to some_file. The added '\n' makes it a line.
*/

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Aug 20 '06 #10
bw*****@yahoo.com wrote:
Where I am confused is that I thought streams automatically terminated
the file with an CR (0a) in a unix environment.
CR short for carriage return is 0c in hexadecimal. NL short
for newline or LF short for linefeed is 0a. And as others have
pointed out neither is guaranteed to be the last byte in a Unix
file. Try typing
cat some-file
type a few characters and press Control-D twice. You'll get a
file without a newline in the end.

By the way , all the above is out of topic here.

Aug 20 '06 #11
sp****@gmail.com wrote:
bw*****@yahoo.com wrote:
>Where I am confused is that I thought streams automatically terminated
the file with an CR (0a) in a unix environment.

CR short for carriage return is 0c in hexadecimal. NL short
for newline or LF short for linefeed is 0a. And as others have
pointed out neither is guaranteed to be the last byte in a Unix
file. Try typing
cat some-file
type a few characters and press Control-D twice. You'll get a
file without a newline in the end.

By the way , all the above is out of topic here.
Both spibou and bwaichu seem unable to read a simple ASCII code chart.
The CR character is 0D (13). The Unix newline char NL is (10). It is the
formfeed character FF which is 0C or (12).

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Aug 20 '06 #12

Joe Wright wrote:
>
Both spibou and bwaichu seem unable to read a simple ASCII code chart.
The CR character is 0D (13). The Unix newline char NL is (10). It is the
formfeed character FF which is 0C or (12).
What the deal with the insults? If we had all the answers, we wouldn't
be asking questions.
And NL is 0a.

Here's the acsii table:

http://www.lookuptables.com/

I made a typo. Just like I wrote NULL instead of NUL. Typos happen.
That is why editors have jobs.

Jeez.

Aug 20 '06 #13
bw*****@yahoo.com wrote:
Joe Wright wrote:
>Both spibou and bwaichu seem unable to read a simple ASCII code chart.
The CR character is 0D (13). The Unix newline char NL is (10). It is the
formfeed character FF which is 0C or (12).

What the deal with the insults? If we had all the answers, we wouldn't
be asking questions.
And NL is 0a.

Here's the acsii table:

http://www.lookuptables.com/

I made a typo. Just like I wrote NULL instead of NUL. Typos happen.
That is why editors have jobs.
I didn't mean it as a personal insult. I was correcting errors. I don't
like to correct careless errors, typographical or otherwise. I expect
you to proof-read your article and correct your own errors as best you
can before posting it. Too much to expect?

I wrote NL is (10) and you correct it to 0a? What's that about? As to
correctness, 10 is ten. 0x0a is ten. 012 is ten.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Aug 21 '06 #14

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

13
by: James Harris | last post by:
Hi, Can someone recommend a book that will teach me how to approach C programming so that code is modularised, will compile for different environments (such as variations of Unix and Windows),...
22
by: SeeBelow | last post by:
Is there any way, in C, of interacting with a running program, but still using code that is portable, at least between linux and Windows? By "interacting" it could be something as simple as...
10
by: Jason Curl | last post by:
Dear C group, I'm very interested in writing portable C, but I only have GNU, Sparc and Cygwin to compile on. What I find is the biggest problem to writing portable C is what headers to...
8
by: suresh_C# | last post by:
Dear All, What is difference between Portable Executable (PE) file and a Assembly? Thanks, Mahesh
2
by: Tull Clancey | last post by:
Hi all. I'm nearing completion of a host app that needs to send data to, and receive data back from a portable, an HP device. The application running on the portable will be a .net application....
131
by: pemo | last post by:
Is C really portable? And, apologies, but this is possibly a little OT? In c.l.c we often see 'not portable' comments, but I wonder just how portable C apps really are. I don't write...
162
by: Richard Heathfield | last post by:
I found something interesting on the Web today, purely by chance. It would be funny if it weren't so sad. Or sad if it weren't so funny. I'm not sure which. ...
409
by: jacob navia | last post by:
I am trying to compile as much code in 64 bit mode as possible to test the 64 bit version of lcc-win. The problem appears now that size_t is now 64 bits. Fine. It has to be since there are...
10
by: bramnizzle | last post by:
I don't know if this is the right thread or not, but... In my endless pursuit to hold on to my dinosaur laptop (Dell 1100 Inspiron - circa 2004)...I want to keep as much space free for my...
23
by: asit | last post by:
what is the difference between portable C, posix C and windows C ???
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.