C
CBFalconer
Mark said:
All he is proving is that he has watched SNL from the 70s, and
picked up the rudest and most ignorant phrases therefrom.
All he is proving is that he has watched SNL from the 70s, and
picked up the rudest and most ignorant phrases therefrom.
E
Eric Sosman
Mark said:Actually, that was 'my' poor attempt at being funny
But feel free to kick in with a post that actually contributes
something to the discussion Eric. You are one of the
brighter posters on CLC and I'd hate for you to limit your
response to: 'poor kid can't even google.'
Well, I gave a citation from the Standard. You're choosing
to impose some sort of contorted Topsy-Turvy-Land mis-reading,
and I can't rescue you from your folly. What's left besides
innocent merriment?
P
Peter Nilsson
Mark said:
No. Whether the last line _requires_ a newline is implementation
defined.
The behaviour of a program that fails to supply such a newline on an
implementation which requires it is technically undefined.
Members of the committee have commented that the only difference is
whether or not the last (newline free) line is actually output or not.
[Output to old line printers is a classic example. You won't see a line
until it encounters a newline.]
M
Mark
Eric Sosman said:
"Contorted Topsy-Turvy-Land mis-reading"???
Once again, my interpretation of the citation in question is:
a line is required to contain a terminating new-line unless it happens
to be the last line, in which case it is implementation defined as to
whether or not a new-line is required.
Please, enlighten me... what am I mis-reading?
P
pete
If a newline character is required,
then a partial line isn't a line.
Line semantics wouldn't apply to partial lines.
M
Mark
pete said:
I've stated as much earlier in the thread... but that is irrelevant.
As you know, fflush() doesn't deal with lines, it deals with unwritten
'data'.
Line semantics aren't the issue. The purpose of fflush() is to deliver the
unwritten data to the host environment, no?
Had the data been terminated with a new-line when written there would
be no need to call fflush(), agreed?
The question amounts to: is fflush() enough to 'portably' ensure that
any unwritten data is delivered to the host environment.
Based on my interpretations of the standard, I think it should be
enough, but apparently others disagree. I'd like to understand why?
Therefore, I ask again, what am I misreading?
Where am I misinterpreting the standard?
I realize this thread may not be as interesting as some of the other
easily answered 'homework' threads everyone seems to jump at,
but I think it warrants proper discussion and it relates directly to
the interpretation of the standard... no?
Mark
C
Chris Torek
Indeed. But sometimes "text files" (including stdout) require "lines".
Yes, but some host environments are mean, nasty, and rotten.
IBM mainframes in particular tend to be like this.
If you write a "partial line" and fflush() it, nothing comes out!
(They sometimes put a special hack into the stdin-reading code, so
that if you do:
fputs("some prompt: ", stdout);
fflush(stdout);
result = fgets(line, sizeof line, stdin);
the fgets() outputs an extra newline, so that the prompt appears.
But sometimes even that does not happen.)
It gets "delivered" all right, but the mean nasty host does not pass
it on to the user.
Obnoxious, no? But it happens. It is safer to end your last output
line with a newline. This also prevents the output line from being
overwritten by mean, nasty, rotten Unix-clone shells.
M
Mark
Finally, a real guru!
Thanks for responding Chris.
My questions below are not meant to be argumentative or contradictive,
but only to answer a few questions I have.
Doesn't that render the implementation 'non-conforming'?
Agreed. (Safer) But the real question is portability...
I've mentioned upwards in the thread that it's possible that output
may not be visible for a number of other reasons (such as a terminal
window being closed immediately following program termination, in
which case a new-line won't help) but does the exclusion of a final
new-line written to a text stream make the program 'non-portable'?
Let's forget about terminals for a second... consider the following
trivial utility which attempts to store the date/time of last execution.
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int
main(void)
{
FILE *fp = fopen("last.run", "w");
if(fp) {
time_t tt = time(NULL);
struct tm *tms = localtime(&tt);
if(tms != NULL)
fprintf(fp, "%d/%d/%d %d:%d:%d", tms->tm_mon, tms->tm_mday,
tms->tm_year +1900, tms->tm_hour, tms->tm_min,
tms->tm_sec);
fclose(fp);
}
return 0;
}
Does the lack of a new-line prevent this code from being portable?
Is it or is it not a strictly conforming program?
I look forward to any response and plan to let the thread die after that.
Thanks again,
Mark
Thanks for responding Chris.
My questions below are not meant to be argumentative or contradictive,
but only to answer a few questions I have.
Doesn't that render the implementation 'non-conforming'?
(They sometimes put a special hack into the stdin-reading code, so
that if you do:
fputs("some prompt: ", stdout);
fflush(stdout);
result = fgets(line, sizeof line, stdin);
the fgets() outputs an extra newline, so that the prompt appears.
But sometimes even that does not happen.)
It gets "delivered" all right, but the mean nasty host does not pass
it on to the user.
Obnoxious, no? But it happens. It is safer to end your last output
line with a newline. This also prevents the output line from being
overwritten by mean, nasty, rotten Unix-clone shells.
Agreed. (Safer) But the real question is portability...
I've mentioned upwards in the thread that it's possible that output
may not be visible for a number of other reasons (such as a terminal
window being closed immediately following program termination, in
which case a new-line won't help) but does the exclusion of a final
new-line written to a text stream make the program 'non-portable'?
Let's forget about terminals for a second... consider the following
trivial utility which attempts to store the date/time of last execution.
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int
main(void)
{
FILE *fp = fopen("last.run", "w");
if(fp) {
time_t tt = time(NULL);
struct tm *tms = localtime(&tt);
if(tms != NULL)
fprintf(fp, "%d/%d/%d %d:%d:%d", tms->tm_mon, tms->tm_mday,
tms->tm_year +1900, tms->tm_hour, tms->tm_min,
tms->tm_sec);
fclose(fp);
}
return 0;
}
Does the lack of a new-line prevent this code from being portable?
Is it or is it not a strictly conforming program?
I look forward to any response and plan to let the thread die after that.
Thanks again,
Mark
M
Mark McIntyre
We're saying the same thing. If the reqirement to have a newline is
implementation defined, then the behaviour in its absence is
implementation defined and unportable.
M
Mark McIntyre
Flushing the buffers is not obligated to cause something to appear
onscreen or whatever. After all, when you flush the loo, nothing comes
out of it (hopefully).
Define portable. The definition round here tends to be "works the same
on all platforms", and since we know that newline-less lines don't
always get printed, we can safely say the code isn't portable.
C
Chris Torek
No, because the standard only requires that the bytes be "delivered
to the host environment", which in this particular case means the
runtime libraries the C compiler uses to interface to the OS (MVS,
OS/360, etc.).
It causes the output to be other than desired, at least.
without including a final newline]
"Strictly conforming" is not, in a practical sense, a very useful
property of programs. Here is what the Standard (well, C99 draft)
says:
[#1] A strictly conforming program shall use only those
features of the language and library specified in this
International Standard.2 It shall not produce output
dependent on any unspecified, undefined, or implementation-
defined behavior, and shall not exceed any minimum
implementation limit.
It is quite difficult to avoid exceeding *some* "minimum
implementation limit" and all "implementation-defined behavior".
But you asked
, so:What happens on those annoying mainframe-type machines is that the
file may wind up empty, or may have a newline you did not really
want added to it, depending on the chosen output format (usually
selected via JCL or some other ugliness). (The reason is that the
system has too many file formats. One set of file formats, the
"varying length record", consists of a sequence of "records" of
"varying length" -- hence the name. One of the encodings for this
is "byte count of first output line, followed by the line's bytes,
followed by byte count of second output line, followed by the line's
bytes", and so on. A special count means "skip to end of disk
block", after which one resumes the logical-record sequence; logical
records are not normally broken across disk blocks.)
In order for the C library stdio to handle this file format, it
has to count bytes up to the newline:
/* write one character to a file */
void __sputc(FILE *fp, int c) {
... various tests, after which we decide that we have one
of these annoying logical-record files ...
if (c == '\n') {
reclen = fp->__reclen; /* __ names are in our implementor space */
/*
* Write 2-byte record length in host order, to the file
* specified by the File Control Block. Then, if there
* are any bytes, write them. (First skip to new block
* if needed, of course.)
*/
if (fp->__fcb.partblk + reclen + 2 > fp->__fcb.__blksize)
__lib_fcb_padblk(&fp->__fcb);
__lib_fcb_write(&fp->__fcb, &reclen, 2);
if (reclen > 0)
__lib_fcb_write(&fp->__fcb, fp->__buf, reclen);
/*
* Reset record length to zero and return success, because
* we "wrote the newline".
*/
fp->__reclen = 0;
return '\n';
}
/*
* Not a newline: accumulate the byte. Return failure if the
* accumulated record would exceed a single file block.
*/
if (fp->__reclen + 2 > fp->__fcb.__blksize)
return EOF;
fp->__buf[fp->__reclen++] = c;
return c;
}
(This code assumes there is a whole separate wrapper layer,
__lib_fcb_*, that deals with the underlying disk blocks and
accumulating data until one has a full block. In practice, that
code would probably be folded in with the stdio layer. Of course,
in VMS, this code all lies in the RMS system in the "supervisor"
or "executive" [I forget which], so it is not even in the C library
at all! The file control blocks are manipulated via the QIO
system calls, as I recall.)
Whether fclose() and/or the stdio shutdown code (at exit) checks
for fp->__reclen > 0, and appends a newline, is "implementation-defined".
So code that depends on this (by not adding a final newline before
fclose()ing or exit()ing or returning from main) is not "strictly
conforming", using the Standard's definition of "strictly conforming".
The output is one line (including final newline) on Implementation
A, and no lines on Implementation B. (And both differ from Unix-like
systems, where you get a non-\n-terminated line in the file,
creating headaches for someone who wants to count lines.
)The comp.lang.c and/or comp.std.c groups have occasionally
proposed that the Standard should have a term like "strongly
conforming" that would be more useful than "strictly conforming".
A program that fails to print a final newline would probably
be "strongly conforming", even though there would be machines
where nothing gets written.
The folks who edit the standards have never taken this up.
J
junaid
Song
printf("Yu Song's E-mail:"User At Warwick);
This Will Work fine after all User,At,Warwick are the macros and
releted to preprocessor tasks not a variable.
Thanks Junaid
HI to all why to use format specifier %s and %c whatever it may be
printf("Yu Song's E-mail:"User At Warwick);
This Will Work fine after all User,At,Warwick are the macros and
releted to preprocessor tasks not a variable.
Thanks Junaid
K
Keith Thompson
junaid said:
For one thing, only adjacent string literals are concatanated, not
character constants, so the suggested code would be a syntax error.
This is easily avoided by defining At as "@" rather than '@', but that
leaves another potential problem: if one of the defined strings
happens to contain a '%' character, it will be interpreted as a format
specifier if it's part of the format string. Using "%s" avoids this.
There don't happen to be any '%' characters present, but it's still
one less thing to worry about. (I remember when e-mail addresses
often did contain '%' characters.)
If you want to make the code more efficient, you could just print a
single string literal -- but that would violate the whole purpose of
the program, which is to obfuscate the poster's e-mail address, but
not too badly.
Finally, if I had written it, I probably would have added a
"#include <stdio.h>" at the top and a newline at the end of the
output, even though it's not really meant to be a useful program.
J
Joona I Palaste
28 replies about someone's signature and only one actually answering the
original question. What a newsgroup!
(Signature in question intentionally snipped because it's covered
already)
J
junaid
That means we have an eye, which captures even minute things about the
C language, whether it's an intentionally posted question or
someone's signature.
If someone's signatures gives 28 people to talk on technical topics
what's wrong with it? And the plus point is the newcomer like me gets
knowledge from it.
J
Jean-Claude Arbaut
Le 13/06/2005 23:40, dans
(e-mail address removed), « junaid »
Still, nobody has given a clue on the original question... Sad. The parallel
and very interesting discussion about '\n' is not an excuse
(e-mail address removed), « junaid »
Still, nobody has given a clue on the original question... Sad. The parallel
and very interesting discussion about '\n' is not an excuse
J
junaid
Still, nobody has given a clue on the original question... Sad. The parallel
I am happy with the first reply i.e. from jacob navia
Because I have objection on the line
You not even interested how the program will be implemented and the
logic about it but directly asking for the final result,really a bad
use of the group.
and very interesting discussion about '\n' is not an excuse
I am happy with the first reply i.e. from jacob navia
Because I have objection on the line
of the main question.
You not even interested how the program will be implemented and the
logic about it but directly asking for the final result,really a bad
use of the group.
P
Paul Mesken
It was more like a (underspecified) request for free code
J
junaid
It was more like a (underspecified) request for free code
Not free code but free exe.
I also appritiate the attempt for the free code.(Being a penguin lover)
I also applogise for the mistake that I have made (not all the
remaining 28 posts are technical some of them are simply personal)and
we also wasting our time (I think)on a nontechnical things.
I am sorry if I have hurted you,but What I mean from my earlier post is
we dont have to miss the chance to learn something new ,I dont care if
it comes from someones signature ,but if the disscussion is going to be
personal it must be stoped.
so I stop here
Thanks
Not free code but free exe.
I also appritiate the attempt for the free code.(Being a penguin lover)
I also applogise for the mistake that I have made (not all the
remaining 28 posts are technical some of them are simply personal)and
we also wasting our time (I think)on a nontechnical things.
I am sorry if I have hurted you,but What I mean from my earlier post is
we dont have to miss the chance to learn something new ,I dont care if
it comes from someones signature ,but if the disscussion is going to be
personal it must be stoped.
so I stop here
Thanks
P
Paul Mesken
I'd say, roughly, a good 25% of the follow-up posts here are intended
to be personal (looking at the insults contained within them).
Who? Me? I didn't even note an attempt to hurt my feelings
Okay, here's something you might not know. Did you know that fruit
juice (like orange juice or lemon juice) erodes our teeth more than
cola? It's more acidic and keeps its eroding action longer.
Amazing.
It's recommended to rinse your mouth with water after drinking fruit
juice to neutralize the acid. It also helps to use a straw. Human
teeth aren't worth beans. Some of the few liquids that don't erode our
teeth are water, milk and tea.
If only it was that easy ;-)