Printing "hello , wolrd" with out using semicolon

[Prashanth Badabagni]

Hi,
Can any body tell me how to print "hello,worl d" with out using semicolon

Thanks in advance ..
Bye
Prashanth Badabagni

[CBFalconer]

Jeremy Yallop wrote:

Martin Dickopp wrote:

int main(void) { if (putchar((((mai n==main)+(main= =main))*((main= =
main)+(main==ma in)) * ((main==main)+( main==main)) * ((main==main)+
(main==main))* ((main==main)+( main==main)) * ((main==main)+( main==
main)))-(((main==main)+ (main==main))*( (main==main)+(m ain==main)))-
(main==main)), putchar((((main ==main)+(main== main))*((main== main)+
(main==main)) * ((main==main)+( main==main)))+( (main==main)+(m ain==
main))),exit(ma in!=main),main= =main){}}

That's undefined behaviour: exit() is implicitly declared by the call
as a function returning int, but the standard function exit() is
defined as returning void.

Nope. exit is defined as never returning, so there is no
behaviour to become undefined.

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush.
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.

[Ben Pfaff]

CBFalconer <cb********@yah oo.com> writes:

Jeremy Yallop wrote:

That's undefined behaviour: exit() is implicitly declared by the call
as a function returning int, but the standard function exit() is
defined as returning void.

Nope. exit is defined as never returning, so there is no
behaviour to become undefined.

Nonsense. You are wrong for the same reason that anyone who
makes the same claim about main() is wrong.
--
"What is appropriate for the master is not appropriate for the novice.
You must understand the Tao before transcending structure."
--The Tao of Programming

[Arthur J. O'Dwyer]

On Tue, 11 May 2004, CBFalconer wrote:

Jeremy Yallop wrote:

Martin Dickopp wrote:

int main(void) { if (putchar((((mai n==main)+(main= =main))*((main= =
main)+(main==ma in)) * ((main==main)+( main==main)) * ((main==main)+
(main==main))* ((main==main)+( main==main)) * ((main==main)+( main==
main)))-(((main==main)+ (main==main))*( (main==main)+(m ain==main)))-
(main==main)), putchar((((main ==main)+(main== main))*((main== main)+
(main==main)) * ((main==main)+( main==main)))+( (main==main)+(m ain==
main))),exit(ma in!=main),main= =main){}}

That's undefined behaviour: exit() is implicitly declared by the call
as a function returning int, but the standard function exit() is
defined as returning void.

Nope. exit is defined as never returning, so there is no
behaviour to become undefined.

You should know better than that! One of the possible effects of
undefined behavior is the computer's actually coming backwards in
time to mess up the program before it even gets to the trouble spot...

Suppose 'exit' is defined with a calling convention such that
it expected to see one parameter on the stack, followed by a return
address which it will use to print a diagnostic message to the
user if 'errno' is set. Suppose further that to preserve register
real estate, 'int' values are returned by the caller's allocating
some (write-only) space on the stack prior to pushing its return
address and any arguments to the function. (Note that variadic
functions must be *really* perverse on this implementation! )
Now, we call 'exit' as if it is a regular function returning an
'int'. We push our return address, then a write-only buffer for
the return value, and then the argument 0. 'exit' tries to read our
buffer as if it were an address, and we get an exception. Ta-da!

HTH,
-Arthur

[CBFalconer]

Ben Pfaff wrote:

CBFalconer <cb********@yah oo.com> writes:

Jeremy Yallop wrote:

That's undefined behaviour: exit() is implicitly declared by
the call as a function returning int, but the standard function
exit() is defined as returning void.

Nope. exit is defined as never returning, so there is no
behaviour to become undefined.

Nonsense. You are wrong for the same reason that anyone who
makes the same claim about main() is wrong.

But main will return sooner or later, and its return value will be
used somehow. This does not apply to exit.

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush.
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.

[Ben Pfaff]

CBFalconer <cb********@yah oo.com> writes:

Ben Pfaff wrote:

CBFalconer <cb********@yah oo.com> writes:

Jeremy Yallop wrote:

That's undefined behaviour: exit() is implicitly declared by
the call as a function returning int, but the standard function
exit() is defined as returning void.

Nope. exit is defined as never returning, so there is no
behaviour to become undefined.

Nonsense. You are wrong for the same reason that anyone who
makes the same claim about main() is wrong.

But main will return sooner or later, and its return value will be
used somehow. This does not apply to exit.

Irrelevant. Read the standard. There is no difference between
the situations. Both instances are undefined.
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[CBFalconer]

"Arthur J. O'Dwyer" wrote:

On Tue, 11 May 2004, CBFalconer wrote:

Jeremy Yallop wrote:

Martin Dickopp wrote:
> int main(void) { if (putchar((((mai n==main)+(main= =main))*((main= =
> main)+(main==ma in)) * ((main==main)+( main==main)) * ((main==main)+
> (main==main))* ((main==main)+( main==main)) * ((main==main)+( main==
> main)))-(((main==main)+ (main==main))*( (main==main)+(m ain==main)))-
> (main==main)), putchar((((main ==main)+(main== main))*((main== main)+
> (main==main)) * ((main==main)+( main==main)))+( (main==main)+(m ain==
> main))),exit(ma in!=main),main= =main){}}

That's undefined behaviour: exit() is implicitly declared by the call
as a function returning int, but the standard function exit() is
defined as returning void.

Nope. exit is defined as never returning, so there is no
behaviour to become undefined.

You should know better than that! One of the possible effects of
undefined behavior is the computer's actually coming backwards in
time to mess up the program before it even gets to the trouble spot...

Suppose 'exit' is defined with a calling convention such that
it expected to see one parameter on the stack, followed by a return
address which it will use to print a diagnostic message to the
user if 'errno' is set. Suppose further that to preserve register
real estate, 'int' values are returned by the caller's allocating
some (write-only) space on the stack prior to pushing its return
address and any arguments to the function. (Note that variadic
functions must be *really* perverse on this implementation! )
Now, we call 'exit' as if it is a regular function returning an
'int'. We push our return address, then a write-only buffer for
the return value, and then the argument 0. 'exit' tries to read our
buffer as if it were an address, and we get an exception. Ta-da!

We can agree on don't do dat, and that this whole thread is silly
and totally without redeeming features, but ...

Why can't we just use K&R source, not needing any prototypes, and
which has never heard the word 'void'? The need to handle such
prevents your mechanism above, IMO. Since the system is using
implicit int it must be C90, not C99.

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush.
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.

[Richard Bos]

ai***@acay.com. au (Peter Nilsson) wrote:

"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> wrote in message

#define P(x) printf(#x
#define L(x) #x
#define S L(| |)[!Z]
int f(int l,int i){if((i=l,!Z)& &l==Z&&P(%c%c%d \n),S,S,Z)&&f
(++i,i)){}else if(--l==Z&&P(\n))&&f (++i,i)){}else if(--l==Z

The \ in \n is not at the end of a line, not part of a character or
string literal, not part of a universal character, not part of an
include header, and does not constitute a punctuator or other
preprocessor token.

Macro processing, including # stringising macros, is done in translation
phase 4; escape sequences are translated in phase 5. AFAICT this is
enough to ensure that the above is legal (at least in this regard!),
since by the time the backslash is seen, it _is_ part of a string
literal.

Richard

[Richard Bos]

"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> wrote:

#include <stdio.h>
#include <stdlib.h>
#define Z ((int)NULL)
#define P(x) printf(#x
#define L(x) #x
#define S L(| |)[!Z]
int f(int l,int i){if((i=l,!Z)& &l==Z&&P(%c%c%d \n),S,S,Z)&&f
(++i,i)){}else if(--l==Z&&P(\n))&&f (++i,i)){}else if(--l==Z
&&P(%c%c%d\n),S ,S,Z)&&f(++i,i) ){}else if(--l==Z&&P(%c/\n),S
)&&f(++i,i)){}e lse if(exit(Z),Z){} }int main(){if(f(Z,Z )){}}

Alas, there is another, quite serious, bug in this program... it invokes
undefined behaviour! It calls f(++i,i) four times, each time modifying
the object i and accessing it for another purpose without an intervening
sequence point - that's a separator, not a comma operator! Fortunately,
this can easily be solved by changing all of these calls to f(++i,l).

Richard

[Daniel Haude]

On Mon, 10 May 2004 22:12:34 +0200,
Martin Dickopp <ex************ ****@zero-based.org> wrote
in Msg. <cu************ *@zero-based.org>

Jeremy Yallop <je****@jdyallo p.freeserve.co. uk> writes:

Martin Dickopp wrote:

int main(void) { if (putchar((((mai n==main)+(main= =main))*((main= =
main)+(main==ma in)) * ((main==main)+( main==main)) * ((main==main)+
(main==main))* ((main==main)+( main==main)) * ((main==main)+( main==
main)))-(((main==main)+ (main==main))*( (main==main)+(m ain==main)))-
(main==main)), putchar((((main ==main)+(main== main))*((main== main)+
(main==main)) * ((main==main)+( main==main)))+( (main==main)+(m ain==
main))),exit(ma in!=main),main= =main){}}

That's undefined behaviour: exit() is implicitly declared by the call
as a function returning int, but the standard function exit() is
defined as returning void.

Good catch. The only solution I can think of is to rely on the
"implicitly return 0 from main" behavior in C99.

How about (int)exit() ?

--Daniel

--
"With me is nothing wrong! And with you?" (from r.a.m.p)

[Martin Dickopp]

Daniel Haude <ha***@physnet. uni-hamburg.de> writes:

On Mon, 10 May 2004 22:12:34 +0200,
Martin Dickopp <ex************ ****@zero-based.org> wrote
in Msg. <cu************ *@zero-based.org>

Jeremy Yallop <je****@jdyallo p.freeserve.co. uk> writes:

Martin Dickopp wrote:
int main(void) { if (putchar((((mai n==main)+(main= =main))*((main= =
main)+(main==ma in)) * ((main==main)+( main==main)) * ((main==main)+
(main==main))* ((main==main)+( main==main)) * ((main==main)+( main==
main)))-(((main==main)+ (main==main))*( (main==main)+(m ain==main)))-
(main==main)), putchar((((main ==main)+(main== main))*((main== main)+
(main==main)) * ((main==main)+( main==main)))+( (main==main)+(m ain==
main))),exit(ma in!=main),main= =main){}}

That's undefined behaviour: exit() is implicitly declared by the call
as a function returning int, but the standard function exit() is
defined as returning void.

Good catch. The only solution I can think of is to rely on the
"implicitly return 0 from main" behavior in C99.

How about (int)exit() ?

That doesn't help, and wouldn't have any effect anyway, as `exit'
doesn't return. The problem is that the behavior becomes undefined as
soon as an undeclared (or "implictly declared") function returning
anything but `int' is /called/.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/