Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

C Programming Language

How to print "\n" or '\0'


please help. thanks.
you're welcome

"Umesh" <fraternitydispo@gmail.com> ha scritto nel messaggio
news:1180176113.567261.267090@a26g2000pre.googlegroups.com...

> please help. thanks.

To print a newline, simplily use putchar('\n');
I can't imagine why you want to print a null character, but
putchar(0) should work.

Umesh <fraternitydispo@gmail.com> wrote:
> please help. thanks.

I would like to, but:

1) please put your question into the body of your posting,
2) please phrase your question in a way that it makes some
   sense.
             How to print "\n" or '\0'
   doesn't.
                           Regards, Jens
--
  \   Jens Thoms Toerring  ___      j@toerring.de
   \__________________________      http://toerring.de

"Umesh"

> please help. thanks.

Are you purposely being dense?  Haven't you been told to post your question
in the body of your message?

WRT the '\0'. That stand for null - note the lower case spelling - it's an
ordinary English word.  Now look up null.

http://www.answers.com/null&r=67

Pay particular attention to definitions 3 and 4.  Now how does one represent
nothing? Difficult isn't it?  Perhaps you want to learn about the
hexadecimal representation of numbers.  Look at the format specifier "%x".

//how to print "\n"  or '\0'

#include"stdio.h"
int main()
{
 printf("\\n");
 printf("\n");
 printf("'\\0'");
 return 0;

"Jens Thoms Toerring" <j@toerring.de> wrote in message
news:5bqkvuF2u5a74U1@mid.uni-berlin.de...

> Umesh <fraternitydispo@gmail.com> wrote:
>> please help. thanks.

> I would like to, but:

> 1) please put your question into the body of your posting,
> 2) please phrase your question in a way that it makes some
>   sense.
>             How to print "\n" or '\0'
>   doesn't.
>                           Regards, Jens
> --
>  \   Jens Thoms Toerring  ___      j@toerring.de
>   \__________________________      http://toerring.de

I'm amazed that only one person answered the question, while the rest of you
were overly concerned about specific structuring of the body of his post and
specific requirements for the wording.

The OP is building quite a reputation for idiotic posts and ignoring advice.

--
Ian Collins.

Eigenvector said:

<snip>

> I'm amazed that only one person answered the question, while the rest
> of you were overly concerned about specific structuring of the body of
> his post and specific requirements for the wording.

I'm astounded that anyone answered his question at all. I'd have thought
he'd be in everyone's killfiles by now.

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

Not to mention that the one person answered only one of the many
possible interpretations of the question.  Which is more helpful,
answering the wrong question, or asking for clarification?
--
clvrmnky <mailto:spamt@clevermonkey.org>

Direct replies will be blacklisted.  Replace "spamtrap" with my name to
contact me directly.

Groovy hepcat Umesh was jivin' on 26 May 2007 09:25:29 -0700 in
comp.lang.c.
Re: How to print "\n" or '\0''s a cool scene! Dig it!

>//how to print "\n"  or '\0'

>#include"stdio.h"

  Now, I know you know better than that, Umesh. You must be trolling,
I think. The only explanation I can think of for your baffling
behaviour is that you are a troll.
  That said, the only reason I'm responding to a troll is to encourage
others to ignore Umesh, and all trolls. Killfile the fool.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?

Peter 'Shaggy' Haywood wrote:
> Groovy hepcat Umesh was jivin' on 26 May 2007 09:25:29 -0700 in
> comp.lang.c.
> Re: How to print "\n" or '\0''s a cool scene! Dig it!

>>//how to print "\n"  or '\0'

>>#include"stdio.h"

>   Now, I know you know better than that, Umesh. You must be trolling,
> I think. The only explanation I can think of for your baffling
> behaviour is that you are a troll.
>   That said, the only reason I'm responding to a troll is to encourage
> others to ignore Umesh, and all trolls. Killfile the fool.

#include "stdio.h" is allowed in standard C. When #include "..." does not
pick up a file in the locations for user headers, it is replaced by the
compiler as if it read #include <...>.

"Harald van D?k" <true@gmail.com> ha scritto nel messaggio
news:f3hl6t$8ci$1@news1.zwoll1.ov.home.nl...

I don't think Peter referred to that. Umesh asked a question which
can be misunderstood very easily, then, after being told how to
print a newline or a null character[1], he answered his question
himself, showing that what he was trying to do was printing a
backslash followed by a lowercase n, or an apostrophe followed by
a backslash followed by the digit 0 followed by another apostrophe,
a question which could be asked much less ambiguously as "how can I
print a backslash?".

[1]Not always meaningless. For example, if you freopen()ed stdout
as a binary file (or if you are working on a Unix-like system where
there is no real difference between binary and text), and are
creating a PPM picture,
putchar(p.Red); putchar(p.Green); putchar(p.Blue);
should work even to put a black pixel.

What you are saying would also make sense, but I think he referred to the
#include style, because he snipped every other part of Umesh's code in his
reply.

"Harald van D?k" <true@gmail.com> ha scritto nel messaggio
news:f3phej$31b$1@news2.zwoll1.ov.home.nl...

Or he simplily arbitrarily snipped from that point onwards, considering he
did not snip the previous comment...
Groovy hepcat Harald van =?UTF-8?B?RMSzaw==?= was jivin' on Tue, 29
May 2007 18:43:15 +0200 in comp.lang.c.
Re: How to print "\n" or '\0''s a cool scene! Dig it!

  It's allowed (by the compiler). But that doesn't make it right. What
you say is true. However, if the compiler does find a header named
stdio.h before looking in the place it looks for <stdio.h>, then the
consequences depend on what's in that header.
  In any case, the correct way to include the standard (or
implementation provided) stdio.h header is like so:

#include <stdio.h>

Anything else is the wrong way.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?

It's allowed by the standard, and that does make it right.

> What
> you say is true. However, if the compiler does find a header named
> stdio.h before looking in the place it looks for <stdio.h>, then the
> consequences depend on what's in that header.

Of course. And if the umesh did place a file named stdio.h in one of the
paths the compiler looks at only for #include "..." directives, presumably
he wanted it to be used, and then #include "stdio.h" is the only way to do
it.

>   In any case, the correct way to include the standard (or
> implementation provided) stdio.h header is like so:

> #include <stdio.h>

> Anything else is the wrong way.

What's correct depends on what the C standard and the implementation's
documentation say is correct.
Harald van D k <true@gmail.com> writes:

> Peter 'Shaggy' Haywood wrote:
>> Groovy hepcat Harald van =?UTF-8?B?RMSzaw==?= was jivin' on Tue, 29
>> May 2007 18:43:15 +0200 in comp.lang.c.
[...]
>>>#include "stdio.h" is allowed in standard C. When #include "..." does not
>>>pick up a file in the locations for user headers, it is replaced by the
>>>compiler as if it read #include <...>.

>>   It's allowed (by the compiler). But that doesn't make it right.

> It's allowed by the standard, and that does make it right.

No, it makes it legal; it may or may not be "right" in a particular
context.

>> What
>> you say is true. However, if the compiler does find a header named
>> stdio.h before looking in the place it looks for <stdio.h>, then the
>> consequences depend on what's in that header.

> Of course. And if the umesh did place a file named stdio.h in one of the
> paths the compiler looks at only for #include "..." directives, presumably
> he wanted it to be used, and then #include "stdio.h" is the only way to do
> it.

If Umesh placed a file named stdio.h in some directory, it's probably
a mistake.  This is a judgement based on the level of expertise Umesh
has displayed so far in this newsgroup.

>>   In any case, the correct way to include the standard (or
>> implementation provided) stdio.h header is like so:

>> #include <stdio.h>

>> Anything else is the wrong way.

> What's correct depends on what the C standard and the implementation's
> documentation say is correct.

And on the requirements in any particular case, unless you have a very
narrow definition of "correct".  For example, the following program is
perfectly legal (in fact, I believe it's strictly conforming), but
it's not "correct".

#include <stdio.h>

#define SIX 1+5
#define NINE 8+1

int main(void)
{
    printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
    return 0;

}

--
Keith Thompson (The_Other_Keith) k@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."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

See below, I used "right" as "correct".

>>> What
>>> you say is true. However, if the compiler does find a header named
>>> stdio.h before looking in the place it looks for <stdio.h>, then the
>>> consequences depend on what's in that header.

>> Of course. And if the umesh did place a file named stdio.h in one of the
>> paths the compiler looks at only for #include "..." directives,
>> presumably he wanted it to be used, and then #include "stdio.h" is the
>> only way to do it.

> If Umesh placed a file named stdio.h in some directory, it's probably
> a mistake.  This is a judgement based on the level of expertise Umesh
> has displayed so far in this newsgroup.

Fair enough.

Here's what I meant by correct:

If this is intended to print "6 * 9 = 54", the standard doesn't say that it
does (in fact, it says that it doesn't), so it is then not correct.

If this is intended to print "6 * 9 = 42", the standard says that it does,
so it is then correct.

I think this is not very different from what you mean, but please tell me if
I'm misunderstanding what you consider correct.

The above shown code is a correct program.
The C99 standard says what a "correct program" is.

N869
      4.  Conformance
       [#1]  In  this  International  Standard,  ``shall'' is to be
       interpreted as a requirement on an implementation  or  on  a
       program; conversely, ``shall not'' is to be interpreted as a
       prohibition.
       [#2] If  a  ``shall''  or  ``shall  not''  requirement  that
       appears outside of a constraint is violated, the behavior is
       undefined.  Undefined behavior  is  otherwise  indicated  in
       this   International   Standard  by  the  words  ``undefined
       behavior'' or by the omission of any explicit definition  of
       behavior.   There  is  no difference in emphasis among these
       three; they all describe ``behavior that is undefined''.
       [#3] A  program  that  is  correct  in  all  other  aspects,
       operating  on  correct data, containing unspecified behavior
       shall be a  correct  program  and  act  in  accordance  with
       5.1.2.3.

--
pete

Harald van D k <true@gmail.com> writes:

I had forgotten that the standard uses the word "correct" in a sense
that differs from the way I've been using it here; thanks to pete for
reminding us.

    A program that is correct in all other aspects, operating on
    correct data, containing unspecified behavior shall be a correct
    program and act in accordance with 5.1.2.3.

(Note that this isn't presented as a definition of the word "correct"
I presume that a program doesn't *have* to contain unspecified
behavior to be considered correct.)

I've been trying to draw a strong distinction between programs that
don't violate the standard and programs that, in addition, actually
work the way they're supposed to.

Going back to what started this, using
    #include "stdio.h"
is legal and "correct" in the sense that the standard uses the term,
but it's almost certainly not *right* unless the author actually
intends to allow the program to use a stdio.h header other than the
one provided by the implementation.

It's important to point out that using
    #include "stdio.h"
rather than
    #include <stdio.h>
is almost certainly a mistake.

--
Keith Thompson (The_Other_Keith) k@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."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:
> [snip]
> Going back to what started this, using
>     #include "stdio.h"
> is legal and "correct" in the sense that the standard uses the term,
> but it's almost certainly not *right* unless the author actually
> intends to allow the program to use a stdio.h header other than the
> one provided by the implementation.

> It's important to point out that using
>     #include "stdio.h"
> rather than
>     #include <stdio.h>
> is almost certainly a mistake.

I have to disagree here. Since until you get to the point where creating a
file named stdio.h is a good idea, there is no difference between the two
forms, I don't think the first form is a mistake at all. If you mix
the "..." and <...> forms, there are many cases where it's not clear which
form is most appropriate and whether the answer may change. If you always
use the "..." form, you can't go wrong. So why not always use the "..."
form?
Harald van D k <true@gmail.com> writes:

Using the "..." form tells a knowledgeable reader that the directive
might refer to some arbitrary file other than the standard header.  It
tells me that either (a) the author might have inserted his own
stdio.h file for some reason, and I'd better figure out why if I want
to understand the code, or (b) the author doesn't really know what
he's doing, and he's just wasted my time.

Using the <...> form *for the standard headers* cannot go wrong.
Using the "..." form can go wrong if there happens to be a file named
"stdio.h" (or with whatever name the implementation maps "stdio.h" to)
anywhere in some set of directories that varies from one
implementation to another.

There are legitimate reasons to use either the "..." form or the <...>
form for headers other than the ones defined by the standard.  None of
those reasons apply to stdio.h.

(Do you use #include "stdio.h" in your own code?)

--
Keith Thompson (The_Other_Keith) k@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."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson <k@mib.org> wrote:
> Using the <...> form *for the standard headers* cannot go wrong.

There are exceptions to that rule,
as you would realize on a moment's reflection.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

In article <136akkjres2j@corp.supernews.com>,
Thomas Dickey  <dic@saltmine.radix.net> wrote:

>> Using the <...> form *for the standard headers* cannot go wrong.
>There are exceptions to that rule,
>as you would realize on a moment's reflection.

Why not save us a moment and tell us?

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc