hie..
Do any one knows how to write a C program without using the
conditional statements if, for, while, do, switch, goto and even
condotional statements ? It would be a great help for me if someone
helps me...
Urgent - Please reply soon !
Thanks, Raghu
Nov 14 '05
92  9748 
"Jack Klein" <ja*******@spamcop.net> wrote in message
news:d5********************************@4ax.com... On Tue, 03 Feb 2004 12:48:54 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote in comp.lang.c:
int min(int i, int j) {
return (i < j)? i: j;
}
which can be used to define constants:
const int k = min(i, j);
Why bring up this rubbish here? While the function definition might
be perfectly legal C, the definition of k most certainly is not.
I nearly replied in a similar fashion last night, but then I realized
that it *may* actually be valid (e.g. if used in a function scope) :-(
As someone pointed out recently, you cannot guess wrong all the time.
Peter
Jack Klein wrote: E. Robert Tisdale wrote:
The idea is to write programs containing *only* constant
(because C supports numerous different types) and function definitions.
Functions return values of expressions:
int min(int i, int j) {
return (i < j)? i: j;
}
which can be used to define constants:
const int k = min(i, j);
Why bring up this rubbish here?
While the function definition might be perfectly legal C,
the definition of k most certainly is not.
What sort-of-C-like-but-not-really-C language are you thinking of?
On second thought, please don't tell us.
Nonsense!
It is both legal *and* recommended C 99.
You are out-of-touch Jack.
The world is passing you by.
"gabriel" <no@no--spam.com> wrote in message
news:1a***************************@msgid.meganewss ervers.com... Raghavendra R A V, CSS India wrote:
condotional statements ? It would be a great help for me if someone
helps me...
Just out of curiosity... How did you come up with this question? School
assignment, or just something you thought up, perhaps?
Possible. When I was in school, my prof (who was barred from teaching any
programming courses) divided the class into 4 groups. One group was supposed
to write a C program, for a particular problem, using for loops, the other
with gotos and the other using both, and the last one, using neither.
I ended up initializing an array using...
a[0] = 1;
a[1] = 2;
a[2] = 3;
a[3] = 4;
....
*sigh*
Stupid prof, but fortunately the course lasted only 4 months. I'm still
recovering.
Ashish wrote: I ended up initializing an array using...
a[0] = 1;
a[1] = 2;
a[2] = 3;
a[3] = 4;
...
*sigh*
LOL! Cut and paste baby, cut and paste!
In my CS coursework, I ended up coding everything in C/C++ with Visual C++
6, debugging it there too, and also doing Boundschecker tests under
Windows. When when the source was fully clean and debugged, I would
compile under UNIX for submittal. Doing the whole thing under UNIX was
hell and I gave up soon.
--
gabriel
Ashish wrote:
"gabriel" <no@no--spam.com> wrote in message
news:1a***************************@msgid.meganewss ervers.com... Raghavendra R A V, CSS India wrote:
> condotional statements ? It would be a great help for me if someone
> helps me...
Just out of curiosity... How did you come up with this question? School
assignment, or just something you thought up, perhaps?
Possible. When I was in school, my prof (who was barred from teaching any
programming courses) divided the class into 4 groups. One group was
supposed to write a C program, for a particular problem, using for loops,
the other with gotos and the other using both, and the last one, using
neither.
I ended up initializing an array using...
a[0] = 1;
a[1] = 2;
a[2] = 3;
a[3] = 4;
...
*sigh*
Stupid prof, but fortunately the course lasted only 4 months. I'm still
recovering.
Well, you could've used recursion... Now you'll tell me that functions, if
and arithmetic, logical operators were banned as well :-) If that were the
case, you should tell your prof:
Real computer scientists don't write in anything less portable than a 2B
pencil. Its a shame that Turing machines are so poor at I/O.
#include <stdio.h>
int initarray(int *array, int len, int cur) {
if ( cur >= len ) return 0;
array[cur] = cur+1;
return initarray(array, len, ++cur);
}
int main(void) {
int a[10];
size_t i;
initarray(a, sizeof a/sizeof a[0], 0);
for ( i = 0; i < sizeof a/sizeof a[0]; ++i )
printf("%d\n", a[i]);
return 0;
}
-nrk.
--
Remove devnull for email
nrk wrote: Well, you could've used recursion...
But with a 10000 element array will will blow your stack. Of course, with
a 10K element array your fingers would hurt as well from all the typing if
you do not use some sort of loop!
--
gabriel
gabriel wrote: nrk wrote:
Well, you could've used recursion...
But with a 10000 element array will will blow your stack. Of course, with
a 10K element array your fingers would hurt as well from all the typing if
you do not use some sort of loop!
Even my poorly written code would likely be converted by an optimizing
compiler into a non-recursive solution. If you make that:
void initarray(int *array, int len, int cur) {
if ( cur < len ) array[cur] = cur + 1, initarray(array, len, ++cur);
}
it is almost certain that most modern compilers will optimize away the
recursion. Read about tail call optimization if you're interested in
finding more.
-nrk.
--
Remove devnull for email
"nrk" <ra*********@devnull.verizon.net> wrote in message
news:aa*****************@nwrddc02.gnilink.net... Ashish wrote:
"gabriel" <no@no--spam.com> wrote in message
news:1a***************************@msgid.meganewss ervers.com... Raghavendra R A V, CSS India wrote:
> condotional statements ? It would be a great help for me if someone
> helps me...
Just out of curiosity... How did you come up with this question?
School assignment, or just something you thought up, perhaps?
Possible. When I was in school, my prof (who was barred from teaching
any programming courses) divided the class into 4 groups. One group was
supposed to write a C program, for a particular problem, using for
loops, the other with gotos and the other using both, and the last one, using
neither.
I ended up initializing an array using...
a[0] = 1;
a[1] = 2;
a[2] = 3;
a[3] = 4;
...
*sigh*
Stupid prof, but fortunately the course lasted only 4 months. I'm still
recovering.
Well, you could've used recursion... Now you'll tell me that functions,
if and arithmetic, logical operators were banned as well :-) If that were
the case, you should tell your prof:
Real computer scientists don't write in anything less portable than a 2B
pencil. Its a shame that Turing machines are so poor at I/O.
#include <stdio.h>
int initarray(int *array, int len, int cur) {
if ( cur >= len ) return 0;
array[cur] = cur+1;
return initarray(array, len, ++cur);
}
int main(void) {
int a[10];
size_t i;
initarray(a, sizeof a/sizeof a[0], 0);
for ( i = 0; i < sizeof a/sizeof a[0]; ++i )
printf("%d\n", a[i]);
return 0;
}
-nrk.
--
What I gave was a simple example. The real example couldnt be done using
recursion. If I clearly remember, we had to read from a file containing
course and student info, and fill arrays.
So...
"nrk" <ra*********@devnull.verizon.net> wrote in message
news:aa*****************@nwrddc02.gnilink.net... Ashish wrote:
"gabriel" <no@no--spam.com> wrote in message
news:1a***************************@msgid.meganewss ervers.com... Raghavendra R A V, CSS India wrote:
> condotional statements ? It would be a great help for me if someone
> helps me...
Just out of curiosity... How did you come up with this question?
School assignment, or just something you thought up, perhaps?
Possible. When I was in school, my prof (who was barred from teaching
any programming courses) divided the class into 4 groups. One group was
supposed to write a C program, for a particular problem, using for
loops, the other with gotos and the other using both, and the last one, using
neither.
I ended up initializing an array using...
a[0] = 1;
a[1] = 2;
a[2] = 3;
a[3] = 4;
...
*sigh*
Stupid prof, but fortunately the course lasted only 4 months. I'm still
recovering.
Well, you could've used recursion... Now you'll tell me that functions,
if and arithmetic, logical operators were banned as well :-) If that were
the case, you should tell your prof:
Real computer scientists don't write in anything less portable than a 2B
pencil. Its a shame that Turing machines are so poor at I/O.
#include <stdio.h>
int initarray(int *array, int len, int cur) {
if ( cur >= len ) return 0;
array[cur] = cur+1;
return initarray(array, len, ++cur);
}
int main(void) {
int a[10];
size_t i;
initarray(a, sizeof a/sizeof a[0], 0);
for ( i = 0; i < sizeof a/sizeof a[0]; ++i )
printf("%d\n", a[i]);
return 0;
}
-nrk.
And if the problem were that simple, I didnt need an array. I could've
simply used the fact that a[i] = i + 1 :-)
-Ashish
On Wed, 4 Feb 2004, Papadopoulos Giannis wrote:
nrk wrote: Peter Pichler wrote:
And things like
if (x)
foo();
else
bar();
could be written as ((x) && foo()) || (bar()), given some restrictions on
foo() and bar(). Ugly.
((x) && (foo(), 1)) || (bar(), 1);
Look mama, creative abuse of the comma operator :-)
((x) && ({foo();}) || ({bar();});
uglier
{[(x])}&(&{{foo}{};)] || ([)[bar][]()]};;)
uglier still
[That was a joke, son. :) Plays off of the fact that the text
you posted was not C, it was just a collection of parens and braces
superficially similar to nrk's C example. So duh, it's uglier.
It's easy to make things ugly when you don't care about sense.]
-Arthur
>"Jack Klein" <ja*******@spamcop.net> wrote in message news:d5********************************@4ax.com.. . > const int k = min(i, j);
Why bring up this rubbish here? While the function definition might
be perfectly legal C, the definition of k most certainly is not.
In article <40********@mk-nntp-2.news.uk.tiscali.com>
Peter Pichler <pi*****@pobox.sk> writes:I nearly replied in a similar fashion last night, but then I realized
that it *may* actually be valid (e.g. if used in a function scope) :-(
As someone pointed out recently, you cannot guess wrong all the time.
It *is* valid when in a function, as you note.
On the other hand, it is *not* a constant, as can be seen
by referring to it in a "case" statement, for instance:
void f(int i, int j) {
const int k = min(i, j);
switch (i) {
case k:
puts("i was the min (or equal to j -- degenerate case)");
break;
default:
puts("j was the min");
break;
}
}
Moreover, readonly variables in C cannot be used to dimension
non-VLAs (VLAs being new in C99):
% cat foo.c
const int N = 20;
int a[N];
is illegal in both C89 and C99, and replacing the second line with:
void f(void) {
int b[N];
}
is valid only in C99 (at which point "sizeof b" requires a runtime
evaluation of sizeof, in the abstract machine, though a good compiler
can still optimize it away).
(C++ is, in my opinion, far better than C here. C should have
spelled the keyword "readonly", since it never makes constants.
But then, C has a tradition of misspelling keywords, such as
"typedef" for "do not define a type". :-) )
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
nrk wrote: Real computer scientists don't write in anything less portable than a 2B
pencil. Its a shame that Turing machines are so poor at I/O.
Poor at I/O? Granted, an fseek() is a bit sluggish, but at least there's
no need to check fprintf() results for fear of filling up the tape!
Best regards,
Sidney
Arthur J. O'Dwyer wrote:
On Wed, 4 Feb 2004, Papadopoulos Giannis wrote:
nrk wrote: > Peter Pichler wrote:
>>
>>And things like
>>
>>if (x)
>> foo();
>>else
>> bar();
>>
>>could be written as ((x) && foo()) || (bar()), given some restrictions
>>on foo() and bar(). Ugly. > ((x) && (foo(), 1)) || (bar(), 1);
>
> Look mama, creative abuse of the comma operator :-) ((x) && ({foo();}) || ({bar();});
uglier
{[(x])}&(&{{foo}{};)] || ([)[bar][]()]};;)
uglier still
[That was a joke, son. :) Plays off of the fact that the text
you posted was not C, it was just a collection of parens and braces
superficially similar to nrk's C example. So duh, it's uglier.
It's easy to make things ugly when you don't care about sense.]
LOL!! Time to dust up RJH's excellent quote and paraphrase it to suit the
occasion:
If we remove the requirement that the code must work correctly, I can write
a version that will take no memory, run in zero time, and is virtually
indistinguishable from line noise :-)
-nrk.
-Arthur
--
Remove devnull for email
gabriel wrote: In my CS coursework, I ended up coding everything in C/C++ with Visual C++
6, debugging it there too, and also doing Boundschecker tests under
Windows. When when the source was fully clean and debugged, I would
compile under UNIX for submittal. Doing the whole thing under UNIX was
hell and I gave up soon.
<OT>
Just a bit of well-meant advice: don't give up too soon. Persist, if
only to broaden your horizon. Most of the more interesting work in CS is
done on non-Windows platforms. If you don't get acquainted with
alternatives (which aren't so 'alternative' as they may seem from your
perspective), you are severely limiting your options...
Best regards,
Sidney
nrk wrote: Ashish wrote:
.... snip ...
I ended up initializing an array using...
a[0] = 1;
a[1] = 2;
a[2] = 3;
a[3] = 4;
...
*sigh*
Stupid prof, but fortunately the course lasted only 4 months.
I'm still recovering.
Well, you could've used recursion... Now you'll tell me that
functions, if and arithmetic, logical operators were banned as
well :-) If that were the case, you should tell your prof:
Real computer scientists don't write in anything less portable
than a 2B pencil. Its a shame that Turing machines are so poor
at I/O.
#include <stdio.h>
int initarray(int *array, int len, int cur) {
if ( cur >= len ) return 0;
array[cur] = cur+1;
return initarray(array, len, ++cur);
}
int main(void) {
int a[10];
size_t i;
initarray(a, sizeof a/sizeof a[0], 0);
for ( i = 0; i < sizeof a/sizeof a[0]; ++i )
printf("%d\n", a[i]);
return 0;
}
No no no. Replace the for statement with:
showarray(a, sizeof a/sizeof a[0], 0);
and my suggestion for showarray is:
void showarray(int *array, size_t len, size_t cur)
{
if (cur < len ) {
array[cur] = cur+1;
showarray(array, len, ++cur);
}
}
which I recently discovered will not create stack overflows with
gcc -O2. initarray could be similar.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address! Da*****@cern.ch (Dan Pop) writes: In <bv**********@titan.btinternet.com> Richard Heathfield
<do******@address.co.uk.invalid> writes:donLouis wrote:
I believe that the missing return is OK for C89,
It isn't.
Chapter and verse, please.
C90 5.1.2.2.3 "Program Termination":
A return from the initial call to the main function is equivalent
to calling the exit function with the value returned by the main
function as its argument. If the main function executes a return
that specifies no value, the termination status returned to the
host environment is undefined.
C90 6.6.6.4, "The return statement":
If a return statement without an expression is executed. and the
value of the function call is used by the caller, the behavior is
undefined. Reaching the } that terminates a function is
equivalent to executing a return statement without an expression.
It's not illegal, and it doesn't invoke undefined behavior (since
there's no "caller"), but I'd say that returning an undefined
termination status to the host environment doesn't qualify as "OK".
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
CBFalconer wrote: void showarray(int *array, size_t len, size_t cur) {
if (cur < len) {
array[cur] = cur + 1;
showarray(array, len, ++cur);
}
}
which I recently discovered
will not create stack overflows with gcc -O2.
If you inspect the assembler emitted by gcc,
you will discover that the compiler automatically
"flattens" the recursion into a loop for you
so that showarray never actually calls itself.
The GNU C/C++ compilers will not flatten every recursion yet
but they are getting better and this optimization is now common
in other compilers as well now.
Ashish wrote:
"gabriel" <no@no--spam.com> wrote in message
news:1a***************************@msgid.meganewss ervers.com... Raghavendra R A V, CSS India wrote:
> condotional statements ? It would be a great help for me if someone
> helps me...
Just out of curiosity... How did you come up with this question? School
assignment, or just something you thought up, perhaps?
Possible. When I was in school, my prof (who was barred from teaching any
programming courses) divided the class into 4 groups. One group was
supposed to write a C program, for a particular problem, using for loops,
the other with gotos and the other using both, and the last one, using
neither.
I ended up initializing an array using...
a[0] = 1;
a[1] = 2;
a[2] = 3;
a[3] = 4;
...
*sigh*
That sigh is the sigh of a man who hasn't yet considered the possibility of
using C code to write C code!
You will observe that I have nothing up either sleeve (except my arms, of
course).
Watch closely...
#include <stdio.h>
#define LIMIT 1000 /* adjust to taste */
int main(void)
{
unsigned long i = 0;
puts("#include <stdio.h>\n\nint main(void)\n{");
printf(" int a[%d];\n", LIMIT);
for(i = 0; i < LIMIT; i++)
{
printf(" a[%lu] = %lu;\n", i, i + 1);
}
/* whatever else you want the program to do can go here,
* or you can just generate the array this way and then
* hand-hack the generated code. Of course, you don't
* show the professor /this/ program!
*/
puts(" return 0;\n}");
return 0;
}
And hey! Presto! The silly professor is confounded by Gaussian optimisation!
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
On Thu, 05 Feb 2004 02:07:51 GMT
Keith Thompson <ks***@mib.org> wrote: Da*****@cern.ch (Dan Pop) writes: In <bv**********@titan.btinternet.com> Richard Heathfield
<do******@address.co.uk.invalid> writes:donLouis wrote:
> I believe that the missing return is OK for C89,
It isn't.
Chapter and verse, please.
C90 5.1.2.2.3 "Program Termination":
A return from the initial call to the main function is equivalent
to calling the exit function with the value returned by the main
function as its argument. If the main function executes a return
that specifies no value, the termination status returned to the
host environment is undefined.
C90 6.6.6.4, "The return statement":
If a return statement without an expression is executed. and the
value of the function call is used by the caller, the behavior is
undefined. Reaching the } that terminates a function is
equivalent to executing a return statement without an expression.
It's not illegal, and it doesn't invoke undefined behavior (since
there's no "caller"), but I'd say that returning an undefined
termination status to the host environment doesn't qualify as "OK".
I bring this up for three reasons;
1) I'm sitting at home coding in exercises from a text book. Stuff
like
#include <stdio.h>
int main(void) {
printf("whatever\n");
/* more basic i/o stuff */
}
no filtering, no checking the return status (if I even can), just
learning basic for, while, do, case, whatever. There are plenty
of these types of programs that don't _necessarily_ need a return.
2) Infinite loops. In the bulk of the code that I write these
days, returning from main (or most other functions) is a fatal
error.
3) <OT?> Adding "dummy" returns to GUI code, just to silence
a warning that, based on the cited text above, I think is
harmless.
Comments or corrections are welcome.
--
donLouis
On Wed, 4 Feb 2004 19:11:32 -0000
"Peter Pichler" <pi*****@pobox.sk> wrote: "donLouis" <pa*******@earthlink.net> wrote: >> > Sidney Cadot wrote:
>> >
>> > int main(){for(;;)}
Question; does adding the semi-colon disqualify the program as a
"one liner"?
Doesn't it depend on *where* you put the semicolon? ;-)
I was semi-serious, actually. Which is the correct interpretation?
1. the white space is irrelevant, therefore, it's a one liner.
2. the semi-colon implies a statement, therefore, it's a two liner.
--
donLouis
On Thu, 05 Feb 2004 07:49:46 +0000, donLouis wrote: On Wed, 4 Feb 2004 19:11:32 -0000
"Peter Pichler" <pi*****@pobox.sk> wrote:
"donLouis" <pa*******@earthlink.net> wrote: > > >> > Sidney Cadot wrote:
> > >> >
> > >> > int main(){for(;;)}
>
> Question; does adding the semi-colon disqualify the program as a
> "one liner"?
Doesn't it depend on *where* you put the semicolon? ;-)
I was semi-serious, actually. Which is the correct interpretation?
1. the white space is irrelevant, therefore, it's a one liner.
So by definition any program can be turned into a one liner. Just do the
preprosessing first. Is there a limit to line length?
2. the semi-colon implies a statement, therefore, it's a two liner.
Arn't you allowed statements in one liners?
int main(){for(;;){}}
No additional semicolon :)
--
NPV
"the large print giveth, and the small print taketh away"
Tom Waits - Step right up
Nils Petter Vaskinn <no@spam.for.me.invalid> writes: So by definition any program can be turned into a one liner. Just do
the preprosessing first. Is there a limit to line length?
Yes. A conforming C99 implementation is not required to support logical
source lines (i.e. source lines after backslash-newline-sequences have
been removed) longer than 4095 characters (5.2.4.1#1).
Martin
On Thu, 05 Feb 2004 10:02:44 +0100, Martin Dickopp wrote: Nils Petter Vaskinn <no@spam.for.me.invalid> writes:
So by definition any program can be turned into a one liner. Just do
the preprosessing first. Is there a limit to line length?
Yes. A conforming C99 implementation is not required to support logical
source lines (i.e. source lines after backslash-newline-sequences have
been removed) longer than 4095 characters (5.2.4.1#1).
So the rule would be: "A one liner can be no more that 4095 characters".
Since a conforming compiler could reject it if it was longer.
Does anyone know if different compilers enforce this limit? I've never
written a 4096 character line so I wouldn't know.
--
NPV
"the large print giveth, and the small print taketh away"
Tom Waits - Step right up
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: Da*****@cern.ch (Dan Pop) writes: In <bv**********@titan.btinternet.com> Richard Heathfield
<do******@address.co.uk.invalid> writes: >donLouis wrote:
>
>> I believe that the missing return is OK for C89,
>
>It isn't.
Chapter and verse, please.
C90 5.1.2.2.3 "Program Termination":
A return from the initial call to the main function is equivalent
to calling the exit function with the value returned by the main
function as its argument. If the main function executes a return
that specifies no value, the termination status returned to the
host environment is undefined.
C90 6.6.6.4, "The return statement":
If a return statement without an expression is executed. and the
value of the function call is used by the caller, the behavior is
undefined. Reaching the } that terminates a function is
equivalent to executing a return statement without an expression.
It's not illegal, and it doesn't invoke undefined behavior (since
there's no "caller"), but I'd say that returning an undefined
termination status to the host environment doesn't qualify as "OK".
The question is what the standard says, not what you or anyone else does.
The C89 standard *explicitly* allows this programming construct, therefore
it is OK from the standard's point of view.
Not every program is supposed to return a meaningful value to the host
environment. If I end all my toy programs with a return statement it is
to get a clean compile from gcc -Wall, not because the program termination
status has any meaning to anyone (which is always the case with programs
that only return one exit status: it contains as much information as no
exit status at all).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
donLouis <pa*******@earthlink.net> writes:
[...] 1) I'm sitting at home coding in exercises from a text book. Stuff
like
#include <stdio.h>
int main(void) {
printf("whatever\n");
/* more basic i/o stuff */
}
no filtering, no checking the return status (if I even can), just
learning basic for, while, do, case, whatever. There are plenty
of these types of programs that don't _necessarily_ need a return.
2) Infinite loops. In the bulk of the code that I write these
days, returning from main (or most other functions) is a fatal
error.
3) <OT?> Adding "dummy" returns to GUI code, just to silence
a warning that, based on the cited text above, I think is
harmless.
My advice: Develop good habits now. If a function is declared to
return an int, return an int; main is no different this respect than
any other function.
Ok, that's not quite true, for two reasons. First, C99, unlike C90,
explicitly requires falling off the end of main to be equivalent to
"return 0;" (a feature that I dislike, but there it is). Second, for
most functions, if you don't want to return a value, you can declare
it to return void; you don't really have that option for main.
But the point remains: even if you're not going to use the returned
value, it's easier just to be consistent about returning a value than
to worry about when you can get away with not doing so.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be" Da*****@cern.ch (Dan Pop) writes: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
[...]It's not illegal, and it doesn't invoke undefined behavior (since
there's no "caller"), but I'd say that returning an undefined
termination status to the host environment doesn't qualify as "OK".
The question is what the standard says, not what you or anyone else does.
The C89 standard *explicitly* allows this programming construct, therefore
it is OK from the standard's point of view.
Please cite the section of the standard that defines its use of the
term "OK".
In the absence of such a definition, I will feel free to use the term
in its colloquial sense, based on my own opinion. Failing to return a
value from main() is not "OK". What I mean by that is that it's a bad
idea. It doesn't violate the standard, it doesn't invoke undefined
behavior (unless you call main() recursively and try to use the
result), and it doesn't make hair grow on the palms of your hands.
It was perfectly clear that that was what I meant.
OK?
Not every program is supposed to return a meaningful value to the host
environment. If I end all my toy programs with a return statement it is
to get a clean compile from gcc -Wall, not because the program termination
status has any meaning to anyone (which is always the case with programs
that only return one exit status: it contains as much information as no
exit status at all).
My environment is configured to complain if I run a program that
returns a failure status. <OT>I use tcsh with the $printexitvalue
variable set.</OT> If you don't care about the status returned by a
toy program, that's fine, but I do care about it.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Peter Pichler wrote: "CBFalconer" <cb********@yahoo.com> wrote: nrk wrote:
.... snip ... int main(void) {
int a[10];
size_t i;
initarray(a, sizeof a/sizeof a[0], 0);
for ( i = 0; i < sizeof a/sizeof a[0]; ++i )
printf("%d\n", a[i]);
return 0;
}
No no no. Replace the for statement with:
showarray(a, sizeof a/sizeof a[0], 0);
and my suggestion for showarray is:
void showarray(int *array, size_t len, size_t cur)
{
if (cur < len ) {
array[cur] = cur+1;
showarray(array, len, ++cur);
}
}
Which is equivalent to the for loop above exactly how? (Hint: no output)
I do seem to have goofed thoroughly. :-[ Maybe the "arr[cur] =
cur+1;" line should be revised :-)
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
On Thu, 05 Feb 2004 20:30:27 GMT
Keith Thompson <ks***@mib.org> wrote: donLouis <pa*******@earthlink.net> writes:
[...] 1) I'm sitting at home coding in exercises from a text book. Stuff
like
#include <stdio.h>
int main(void) {
printf("whatever\n");
/* more basic i/o stuff */
}
no filtering, no checking the return status (if I even can), just
learning basic for, while, do, case, whatever. There are plenty
of these types of programs that don't _necessarily_ need a return.
2) Infinite loops. In the bulk of the code that I write these
days, returning from main (or most other functions) is a fatal
error.
3) <OT?> Adding "dummy" returns to GUI code, just to silence
a warning that, based on the cited text above, I think is
harmless.
My advice: Develop good habits now. If a function is declared to
return an int, return an int; main is no different this respect than
any other function.
Ok, that's not quite true, for two reasons. First, C99, unlike C90,
explicitly requires falling off the end of main to be equivalent to
"return 0;" (a feature that I dislike, but there it is). Second, for
most functions, if you don't want to return a value, you can declare
it to return void; you don't really have that option for main.
But the point remains: even if you're not going to use the returned
value, it's easier just to be consistent about returning a value than
to worry about when you can get away with not doing so.
In the above example #1 and #3, I do habitually return a value from
main. My contention is that it is _not_ required in C89/90. For a
long time, I thought that it was. Your point on consistency,
however, is well taken.
--
donLouis
donLouis wrote:
On Thu, 05 Feb 2004 20:30:27 GMT
Keith Thompson <ks***@mib.org> wrote:
donLouis <pa*******@earthlink.net> writes:
[...] 1) I'm sitting at home coding in exercises from a text book. Stuff
like
#include <stdio.h>
int main(void) {
printf("whatever\n");
/* more basic i/o stuff */
}
no filtering, no checking the return status (if I even can), just
learning basic for, while, do, case, whatever. There are plenty
of these types of programs that don't _necessarily_ need a return.
2) Infinite loops. In the bulk of the code that I write these
days, returning from main (or most other functions) is a fatal
error.
3) <OT?> Adding "dummy" returns to GUI code, just to silence
a warning that, based on the cited text above, I think is
harmless.
My advice: Develop good habits now. If a function is declared to
return an int, return an int; main is no different this respect than
any other function.
Ok, that's not quite true, for two reasons. First, C99, unlike C90,
explicitly requires falling off the end of main to be equivalent to
"return 0;" (a feature that I dislike, but there it is). Second, for
most functions, if you don't want to return a value, you can declare
it to return void; you don't really have that option for main.
But the point remains: even if you're not going to use the returned
value, it's easier just to be consistent about returning a value than
to worry about when you can get away with not doing so.
In the above example #1 and #3, I do habitually return a value from
main. My contention is that it is _not_ required in C89/90. For a
long time, I thought that it was. Your point on consistency,
however, is well taken.
It is easier for me to memorize, that
int main(void)
{
return 0;
}
will work in all C programs, in all standards,
than it is to know the variations of what will work
according to year of the standard and whatever else might matter.
--
pete
pete wrote: It is easier for me to memorize, that
int main(void)
{
return 0;
}
will work in all C programs, in all standards,
Shouldn't you use EXIT_SUCCESS in C89?
Best regards,
Sidney
Sidney Cadot wrote:
pete wrote:
It is easier for me to memorize, that
int main(void)
{
return 0;
}
will work in all C programs, in all standards,
Shouldn't you use EXIT_SUCCESS in C89?
I suppose you could, if you also wanted to #include <stdlib.h>,
but I don't get your point.
Are you saying that there's something
wrong with the above program in C89 ?
--
pete
Sidney Cadot wrote: pete wrote:
It is easier for me to memorize, that
int main(void)
{
return 0;
}
will work in all C programs, in all standards,
Shouldn't you use EXIT_SUCCESS in C89?
0 works just fine in C89 and C99. Like EXIT_SUCCESS, 0 communicates the
successful completion of the program to the calling environment.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Keith Thompson wrote: Da*****@cern.ch (Dan Pop) writes: In <bv**********@titan.btinternet.com> Richard Heathfield
<do******@address.co.uk.invalid> writes: >donLouis wrote:
>
>> I believe that the missing return is OK for C89,
>
>It isn't.
Chapter and verse, please.
C90 5.1.2.2.3 "Program Termination":
A return from the initial call to the main function is equivalent
to calling the exit function with the value returned by the main
function as its argument. If the main function executes a return
that specifies no value, the termination status returned to the
host environment is undefined.
C90 6.6.6.4, "The return statement":
If a return statement without an expression is executed. and the
value of the function call is used by the caller, the behavior is
undefined. Reaching the } that terminates a function is
equivalent to executing a return statement without an expression.
Thanks, Keith.
It's not illegal, and it doesn't invoke undefined behavior (since
there's no "caller"), but I'd say that returning an undefined
termination status to the host environment doesn't qualify as "OK".
That's basically my take on it, too. (I note that Dan Pop disagrees.)
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: Da*****@cern.ch (Dan Pop) writes: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:[...] >It's not illegal, and it doesn't invoke undefined behavior (since
>there's no "caller"), but I'd say that returning an undefined
>termination status to the host environment doesn't qualify as "OK".
The question is what the standard says, not what you or anyone else does.
The C89 standard *explicitly* allows this programming construct, therefore
it is OK from the standard's point of view.
Please cite the section of the standard that defines its use of the
term "OK".
In the absence of such a definition, I will feel free to use the term
in its colloquial sense, based on my own opinion.
It is perfectly possible and sensible to use the colloquial sense when
deciding whether it is OK or not from the standard's point of view. So,
I fail to see your point about OK not being defined by the standard...
Failing to return a
value from main() is not "OK". What I mean by that is that it's a bad
idea. It doesn't violate the standard, it doesn't invoke undefined
behavior (unless you call main() recursively and try to use the
result), and it doesn't make hair grow on the palms of your hands.
If it doesn't invoke undefined behaviour and it doesn't require a
diagnostic, it is OK from the standard's point of view. OK?
It was perfectly clear that that was what I meant.
The original statement was made in the *explicit* context of a C standard.
You had no business to *implicitly* ignore that context in your reply.
Not every program is supposed to return a meaningful value to the host
environment. If I end all my toy programs with a return statement it is
to get a clean compile from gcc -Wall, not because the program termination
status has any meaning to anyone (which is always the case with programs
that only return one exit status: it contains as much information as no
exit status at all).
My environment is configured to complain if I run a program that
returns a failure status.
By this silly logic, it is not OK to return EXIT_FAILURE, because your
environment will complain. Yet, a hello world program that doesn't
check the return value of the output call has no a priori reason to
return 0 any more than EXIT_FAILURE.
<OT>I use tcsh with the $printexitvalue
variable set.</OT> If you don't care about the status returned by a
toy program, that's fine, but I do care about it.
This is not a valid argument when deciding whether a certain programming
construct is OK or not. The OP wasn't asking for personal opinions, but
for facts, and the fact is that the C89 standard explicitly allows it.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
On 6 Feb 2004 19:45:31 GMT Da*****@cern.ch (Dan Pop) wrote: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
[...] >It's not illegal, and it doesn't invoke undefined behavior (since
>there's no "caller"), but I'd say that returning an undefined
>termination status to the host environment doesn't qualify as "OK".
The question is what the standard says, not what you or anyone else does.
The C89 standard *explicitly* allows this programming construct, therefore
it is OK from the standard's point of view.
Please cite the section of the standard that defines its use of the
term "OK".
In the absence of such a definition, I will feel free to use the term
in its colloquial sense, based on my own opinion.
It is perfectly possible and sensible to use the colloquial sense when
deciding whether it is OK or not from the standard's point of view. So,
I fail to see your point about OK not being defined by the standard...
Failing to return a
value from main() is not "OK". What I mean by that is that it's a bad
idea. It doesn't violate the standard, it doesn't invoke undefined
behavior (unless you call main() recursively and try to use the
result), and it doesn't make hair grow on the palms of your hands.
If it doesn't invoke undefined behaviour and it doesn't require a
diagnostic, it is OK from the standard's point of view. OK?
It was perfectly clear that that was what I meant.
The original statement was made in the *explicit* context of a C standard.
You had no business to *implicitly* ignore that context in your reply.
Not every program is supposed to return a meaningful value to the host
environment. If I end all my toy programs with a return statement it is
to get a clean compile from gcc -Wall, not because the program termination
status has any meaning to anyone (which is always the case with programs
that only return one exit status: it contains as much information as no
exit status at all).
My environment is configured to complain if I run a program that
returns a failure status.
By this silly logic, it is not OK to return EXIT_FAILURE, because your
environment will complain. Yet, a hello world program that doesn't
check the return value of the output call has no a priori reason to
return 0 any more than EXIT_FAILURE.
<OT>I use tcsh with the $printexitvalue
variable set.</OT> If you don't care about the status returned by a
toy program, that's fine, but I do care about it.
This is not a valid argument when deciding whether a certain programming
construct is OK or not. The OP wasn't asking for personal opinions, but
for facts, and the fact is that the C89 standard explicitly allows it.
I think that the problem is that dogma takes precedence over
the standard.
--
donLouis
[snips]
On Tue, 03 Feb 2004 14:52:36 -0800, E. Robert Tisdale wrote: Please just ignore Richard Heathfield.
If and when he's being a bonehead, sure, good advice. Thing is, he's so
rarely a bonehead (offhand, I can't recall his ever being so in the
several years I've been following c.l.c.) that I can't see the utility of
the advice.
Kelsey Bjarnason wrote: [snips]
E. Robert Tisdale wrote:
Richard Heathfield wrote: gabriel wrote:
void main() { puts("hello world"); }
Any questions?
Just one. How did you manage to get a one-line C program *wrong*?
Please just ignore Richard Heathfield.
If and when he's being a bonehead, sure, good advice.
Thing is, he's so rarely a bonehead
(offhand, I can't recall his ever being so
in the several years I've been following c.l.c.)
that I can't see the utility of the advice.
I guess this was just one of those "rare" instances. ra*********@vit.ac.in (Raghavendra R A V, CSS India) wrote in message news:<5a**************************@posting.google. com>... hie..
Do any one knows how to write a C program without using the
conditional statements if, for, while, do, switch, goto and even
condotional statements ? It would be a great help for me if someone
helps me...
Urgent - Please reply soon !
Thanks, Raghu
You should use funcs with params as choice, possible arrays
and (multiple?) return(smth) with recursion - see previous answers in
conf:
recursion could be used instead 'anything', not only loops.
There are langs with purely funcs-recursion style. But it's almost
just theory -
implementation requires new thinking - you should change conf for it
(I donno whether there are groups for such a languages or not).
Remember that practically
recursion is stack insafe (system stack overflow). If you wanna see
example loop
-optimizes-recursion-could-simply-does, e-mail (Sorry for my bad
English)
Melnikov Oleg, ki**********@mail.ru
Oleg Melnikov <ki**********@mail.ru> scribbled the following: ra*********@vit.ac.in (Raghavendra R A V, CSS India) wrote in message news:<5a**************************@posting.google. com>... hie..
Do any one knows how to write a C program without using the
conditional statements if, for, while, do, switch, goto and even
condotional statements ? It would be a great help for me if someone
helps me...
Urgent - Please reply soon !
You should use funcs with params as choice, possible arrays
and (multiple?) return(smth) with recursion - see previous answers in
conf:
recursion could be used instead 'anything', not only loops.
There are langs with purely funcs-recursion style. But it's almost
just theory -
implementation requires new thinking - you should change conf for it
(I donno whether there are groups for such a languages or not).
Remember that practically
recursion is stack insafe (system stack overflow). If you wanna see
example loop
-optimizes-recursion-could-simply-does, e-mail (Sorry for my bad
English)
Why are you doing everything so difficult? All the OP asked for was
programs that did not use conditional statements, loop statements or
conditional operators. He did not say what the programs should do.
So this program qualifies:
int main(void) {
return 0;
}
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"'I' is the most beautiful word in the world."
- John Nordberg
On 3 Feb 2004 12:22:57 -0800, the right honourable ra*********@vit.ac.in (Raghavendra R A V, CSS India) wrote: hie..
Do any one knows how to write a C program without using the
conditional statements if, for, while, do, switch, goto and even
condotional statements ? It would be a great help for me if someone
helps me...
Urgent - Please reply soon !
Thanks, Raghu
25 years ago, I started work for a company. As I had written a program
in Fortran before, I was immediately labelled as King OneEye in that
country of blinds.
They had a "computer" to run a program for the calculation of certain
standard constructions.
I looked into the program and saw that the programmer did not
understand and use the idea of a loop counter.
He wrote a routine 10 times to process 10 similar parts of the
construction.
I introduced looping then, and brought the size of the program back to
3, instead of 9 magnetic cards (the machine was a Canon Canola
programmable tabletop machine).
Man, was I **KING** in the eyes of management !
As for conditionals, I suspect you cannot write a sensible program
without it, because taking decisions is the very raison d'etre of the
computer, is it not ?
Would even "hello World" have no looping or conditionals, if looked at
at the underlying machine code level ? C hides those , true...
But that is off-topic.
Anyway, I have the uneasy feeling, the OP is teasing his readers.
The answer being so obvious, and the kind of program resulting so ....
weird, useless, not done ?
frgr
Erik
Why are you doing everything so difficult? All the OP asked for was
programs that did not use conditional statements, loop statements or
conditional operators. He did not say what the programs should do.
So this program qualifies:
int main(void) {
return 0;
}
yes.
Astounding, how people can drift off into the blue yonder, here on
Usenet ...
I can think of no parallel in the Real World where this happens.
Why, oh why ?
frgr
Erik
Erik <et57 at correos calor dot com> wrote: Why are you doing everything so difficult? All the OP asked for was
programs that did not use conditional statements, loop statements or
conditional operators. He did not say what the programs should do.
So this program qualifies:
int main(void) {
return 0;
}
yes.
Astounding, how people can drift off into the blue yonder, here on
Usenet ...
Hey, the OP asked a stupid question, he gets stupid answers! Nothing new
there.
Richard
Erik <et57 at correos calor dot com> wrote: Anyway, I have the uneasy feeling, the OP is teasing his readers.
Actually, the OP is probably trying to get us to do his homework.
Richard This thread has been closed and replies have been disabled. Please start a new discussion. |
