Library functions

[Kenny McCormack]

Counter example, on Mac O/S the bundled compiler is gcc but the linker is not
GNU's, it is the Mach-O linker.

It could be argued that the Mac is not a PC (therefore osmium's claim
stands). Certainly, in the parlance of the man-on-the-street, Macs and
PCs are distinct sets (which, again, in the mind of the m-o-t-s,
together comprise the universe of computing).

Now, you may think the above is just sophistry (which, as has been
noted, makes it entirely at home and appropriate here in CLC), but the
fact is that current Macs are more like generic Unix boxes (including
a friendly relationship with open source software - including the
supported compiler/dev-env) than they are like Windows boxes (aka, PCs).

 

[amit.codename13]

[...]

i am indeed curious.

Message-ID: <[email protected]>

well may be not worth a discussion but how did you actually know that
my program ended without a terminating new-line character in my post.

I meant the program's output, not the text of the program itself.

Thanks for answering.
i really wanted pedantic answers...

Then you've come to the right place.

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <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"

I meant the program's output, not the text of the program itself.

[] i missed that *output* in your post. that was my bad...

 

[Keith Thompson]

(e-mail address removed) said:



Keith is referring not to your program (although the rule also
applies there), but to the *output* of your program.

[...]

Actually, a different rule applies to source files.

For source files, C99 5.1.1.2 says, under translation phase 2:

A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character
before any such splicing takes place.

For output files, 7.19.2p2 applies:

Whether the last line requires a terminating new-line character is
implementation-defined.

So even if the implementation doesn't require a trailing new-line for
an output file, leaving it off for a source file invokes undefined
behavior. (One compiler I tried simply ignored the fact that the
trailing new-line was missing, which is of course permissible
behavior.)

And something I just realized: If a text stream requires a trailing
new-line, then you can't have an empty text file; the minimal text
file has exactly one empty line.

 

[Keith Thompson]

And something I just realized: If a text stream requires a trailing
new-line, then you can't have an empty text file; the minimal text
file has exactly one empty line.

N869
7.19.3 Files
[#4]

Whether a file of zero length
(on which no characters have been written by an output stream)
actually exists is implementation-defined.

Thanks, I had missed that. It's also in N1256 (without change bars),
and therefore presumably in the C99 standard itself.

Note that this appears to be independent of whether text streams in
general require trailing new-lines. I suppose there's a possible
contradiction here: an implementation could say that an empty text
file can exist, but that text files require trailing new-lines. But
in practice I don't think that's an issue.

I suppose the intent of 7.19.3p4 is to allow for systems that don't
distinguish between empty files and nonexistent files. I've never
heard of such a system (note that this applies only to hosted
implementations; otherwise stdio isn't required), but I guess it's
possible.

And how many empty text files can dance on the head of a pin?