By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,316 Members | 2,356 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,316 IT Pros & Developers. It's quick & easy.

portability and return

P: n/a
I have heard that return -1 is not portable. So what would be the answer
to portability in this case? What about exit(0) and exit (-1) or exit (1)?
Or would it be best to stick with C's macros, hence:

exit(EXIT_FAILURE)
exit (EXIT_SUCCESS)

Bill
Jun 27 '08 #1
Share this Question
Share on Google+
46 Replies


P: n/a
In article <2YnWj.20544$5b3.14006@trnddc05>,
Bill Cunningham <no****@nspam.comwrote:
I have heard that return -1 is not portable. So what would be the answer
to portability in this case? What about exit(0) and exit (-1) or exit (1)?
Or would it be best to stick with C's macros, hence:
>exit(EXIT_FAILURE)
exit (EXIT_SUCCESS)
It would be best to stick with C's macros. The results are implementation
defined if you use any value other than 0 or one of the macros.
In particular, exit(1) is *not* something that C assigns any meaning to.
--
"What is important, then, is not that the critic should possess a
correct abstract definition of beauty for the intellect, but a
certain kind of temperament, the power of being deeply moved by
the presence of beautiful objects." -- Walter Pater
Jun 27 '08 #2

P: n/a
Bill Cunningham wrote:
I have heard that return -1 is not portable.
Presumably you're talking about the return value from main()?
So what would be the answer to portability in this case?
What about exit(0) and exit (-1) or exit (1)?
exit(0) is fine.
Or would it be best to stick with C's macros, hence:

exit(EXIT_FAILURE)
exit (EXIT_SUCCESS)
Those are good too.

--
Peter
Jun 27 '08 #3

P: n/a

"Peter Nilsson" <ai***@acay.com.auwrote in message
news:32**********************************@v26g2000 prm.googlegroups.com...
Bill Cunningham wrote:
>I have heard that return -1 is not portable.

Presumably you're talking about the return value from main()?
Yes. Would return -1 from a function other than main be ok? I'm guessing
no but I thought I'd ask.

Bill
Jun 27 '08 #4

P: n/a
On 13 May, 22:57, "Bill Cunningham" <nos...@nspam.comwrote:
"Peter Nilsson" <ai...@acay.com.auwrote in message

news:32**********************************@v26g2000 prm.googlegroups.com...
Bill Cunningham wrote:
I have heard that return -1 is not portable.
Presumably you're talking about the return value from main()?

Yes. Would return -1 from a function other than main be ok? I'm guessing
no but I thought I'd ask.
exit(-1) is not portable no matter which function
calls it.
Jun 27 '08 #5

P: n/a
On Tue, 13 May 2008 21:57:23 +0000, Bill Cunningham wrote:
Yes. Would return -1 from a function other than main be ok? I'm
guessing
no but I thought I'd ask.
Are you asking if it's okay to return -1 in such cases as calling
add(2, -3), defined as

int add(int a, int b) {
return a + b;
}

? What else would you want to make this function return?
Jun 27 '08 #6

P: n/a
In article <79oWj.7860$Uz2.2677@trnddc06>,
Bill Cunningham <no****@nspam.comwrote:
Yes. Would return -1 from a function other than main be ok? I'm guessing
no but I thought I'd ask.
For any function other than main, it is fine to return to its
caller any value that lies within the range of the type of the return
value.

But, just in case you meant something different: if you are calling
exit() from *anywhere* in the program, you should restrict the
exit value to 0 or one of the two status macros.
--
"Whenever there is a hard job to be done I assign it to a lazy
man; he is sure to find an easy way of doing it."
-- Walter Chrysler
Jun 27 '08 #7

P: n/a

"Harald van D?k" <tr*****@gmail.comwrote in Are you asking if it's okay
to return -1 in such cases as calling
add(2, -3), defined as

int add(int a, int b) {
return a + b;
}

? What else would you want to make this function return?
No no. Not in this case. Of course return as you specified is correct I
understand. I mean to simply exit with say and error.

if ( argc != 5)
{ fprintf(stderr,"error\n");
return -1; /* exit(-1) is wrong I guess the proper return would be */
exit(EXIT_FAILURE);
}
Bill
Jun 27 '08 #8

P: n/a
Bill Cunningham wrote:
"Peter Nilsson" <ai***@acay.com.auwrote in message
news:32**********************************@v26g2000 prm.googlegroups.com...
>Bill Cunningham wrote:
>>I have heard that return -1 is not portable.
Presumably you're talking about the return value from main()?

Yes. Would return -1 from a function other than main be ok? I'm guessing
no but I thought I'd ask.

Bill

Obviously returning -1 from ANY function (including main)
is portable and well defined by the language.

Now, returning -1 from main could be interpreted by the OS
(when there is one) in different ways and could be non
portable in the sense that it could mean different things in
different OSes.

But this is after main returns, so it is no longer a C problem.

By the way, I find all this discussion completely stupid sorry.

What do you have against -1???

It is just as good a number as 1, or 4477665 for that matter.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jun 27 '08 #9

P: n/a
In article <79oWj.7860$Uz2.2677@trnddc06>,
Bill Cunningham <no****@nspam.comwrote:
Yes. Would return -1 from a function other than main be ok?
Yes of course. You can return any int from a function declared as
returning an int.

There's no problem returning -1 from main() either, as far as the C
program is concerned. All that's undefined is how the "host
environment" - the shell or operating system or parent program -
interprets it. 0 (or EXIT_SUCCESS) indicates success. EXIT_FAILURE
indicates failure. What anything else means depends on your system.

Most of my programs return 0, 1, or sometimes a larger value, which
can be interpreted reasonably in the unix environments I intend them
for. But you can perfectly well run them in other environments; you
just have to ensure that you run them in such a way that the return
value is not misinterpreted. I suppose it's possible that somewhere
there's an operating system that always shuts down completely if any
C program calls exit(1), but the solution to that is to get a different
operating system.

-- Richard
--
:wq
Jun 27 '08 #10

P: n/a

"Richard Tobin" <ri*****@cogsci.ed.ac.ukwrote in message
news:g0***********@pc-news.cogsci.ed.ac.uk...
There's no problem returning -1 from main() either, as far as the C
program is concerned. All that's undefined is how the "host
environment" - the shell or operating system or parent program -
interprets it. 0 (or EXIT_SUCCESS) indicates success. EXIT_FAILURE
indicates failure. What anything else means depends on your system.
[snip]

That's what I am concerned with. How the host system will react. What I
am really concerned with is what the standard says would run best on any
environment. I write small C programs in linux and I want to be able to take
the same source code to my windows system and compile it there and get the
same results. I am trying to get into the habit of treating all code as
development code so it would work in all host environments.

Bill
Jun 27 '08 #11

P: n/a
Bill Cunningham wrote:
"Peter Nilsson" <ai***@acay.com.auwrote in message
news:32**********************************@v26g2000 prm.googlegroups.com...
>Bill Cunningham wrote:
>>I have heard that return -1 is not portable.
Presumably you're talking about the return value from main()?

Yes. Would return -1 from a function other than main be ok?
I'm guessing no but I thought I'd ask.
You can write another function that returns -1 if you want to.
There's no problem with that.
A lot of functions return EOF.
Any negative int, is an allowable value
for an implementation to use to define EOF.

The 3 portable return values from main are:
0
EXIT_SUCCESS
EXIT_FAILURE

--
pete
Jun 27 '08 #12

P: n/a
jacob navia <ja***@nospam.orgwrote:
Bill Cunningham wrote:
"Peter Nilsson" <ai***@acay.com.auwrote in message
news:32**********************************@v26g2000 prm.googlegroups.com...
Bill Cunningham wrote:
I have heard that return -1 is not portable.
Presumably you're talking about the return value from main()?
Yes. Would return -1 from a function other than main be ok? I'm guessing
no but I thought I'd ask.

Bill
Obviously returning -1 from ANY function (including main)
is portable and well defined by the language.
Now, returning -1 from main could be interpreted by the OS
(when there is one) in different ways and could be non
portable in the sense that it could mean different things in
different OSes.
But this is after main returns, so it is no longer a C problem.
By the way, I find all this discussion completely stupid sorry.
What do you have against -1???
It is just as good a number as 1, or 4477665 for that matter.
Jacob, I am rather sure you know better, so just for the OP. If
you want to return a value from main() that indicates success
to the system that invoked the program (and that holds for all
systems) then return either 0 or EXIT_SUCCESS. If you want to
return a value that indicates failure return EXIT_FAILURE.
That's what the C standard requires. It even might mean that
when you return 0 (or EXIT_SUCCESS) the calling system will
receive a value of 42 if it expects 42 to mean success (and
-53 if you return EXIT_FAILURE and on that system -53 indi-
cates failure).

With everything else you don't have such a guarantee. That
makes it not wrong per se to return something else but it
restricts the usability of the return value to those systems
that you know what return value they expect (and e.g. 4477665
won't be anything useful for UNIX systems where the return
value has to fit into 8 bits).

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
Jun 27 '08 #13

P: n/a
jacob navia wrote:
Bill Cunningham wrote:
>"Peter Nilsson" <ai***@acay.com.auwrote in message
news:32**********************************@v26g200 0prm.googlegroups.com...
>>Bill Cunningham wrote:
I have heard that return -1 is not portable.
Presumably you're talking about the return value from main()?

Yes. Would return -1 from a function other than main be ok? I'm
guessing no but I thought I'd ask.

Bill


Obviously returning -1 from ANY function (including main)
is portable and well defined by the language.

Now, returning -1 from main could be interpreted by the OS
(when there is one) in different ways and could be non
portable in the sense that it could mean different things in
different OSes.

But this is after main returns, so it is no longer a C problem.

By the way, I find all this discussion completely stupid sorry.

What do you have against -1???

It is just as good a number as 1, or 4477665 for that matter.
A few years ago somebody asked about systems where a
termination status of -1 would survive its journey to the
environment and be meaningful when it got there. As far
as I can recall, nobody could name such a system. The
somewhat bemused question, of course, was: If there aren't
any systems where -1 makes sense (or if they're so rare
that nobody can think of any), why is -1 so often used
as a termination status?

(Open)VMS was a near-miss, though, since the value would
make it unscathed all the way out to the invoker. However,
VMS' "condition codes" contain various sub-fields in their
32 bits, and the value -1 would set the "severity" sub-field
to a reserved-to-HP value, would set a bit that inhibits the
display of a termination message, and would set three "must
be zero" bits non-zero. So: survivable, but not meaningful.

--
Er*********@sun.com
Jun 27 '08 #14

P: n/a

"Jens Thoms Toerring" <jt@toerring.dewrote in message
news:68*************@mid.uni-berlin.de...
Jacob, I am rather sure you know better, so just for the OP. If
you want to return a value from main() that indicates success
to the system that invoked the program (and that holds for all
systems) then return either 0 or EXIT_SUCCESS. If you want to
return a value that indicates failure return EXIT_FAILURE.
That's what the C standard requires. It even might mean that
when you return 0 (or EXIT_SUCCESS) the calling system will
receive a value of 42 if it expects 42 to mean success (and
-53 if you return EXIT_FAILURE and on that system -53 indi-
cates failure).

With everything else you don't have such a guarantee. That
makes it not wrong per se to return something else but it
restricts the usability of the return value to those systems
that you know what return value they expect (and e.g. 4477665
won't be anything useful for UNIX systems where the return
value has to fit into 8 bits).

Regards, Jens
Thanks very much. That answers my question completely.

Bill
Jun 27 '08 #15

P: n/a
"Bill Cunningham" <no****@nspam.comwrites:
"Peter Nilsson" <ai***@acay.com.auwrote in message
news:32**********************************@v26g2000 prm.googlegroups.com...
>Bill Cunningham wrote:
>>I have heard that return -1 is not portable.

Presumably you're talking about the return value from main()?

Yes. Would return -1 from a function other than main be ok? I'm guessing
no but I thought I'd ask.

Bill
You are for sure trolling. Please stop.
Jun 27 '08 #16

P: n/a
Eligiusz Narutowicz wrote:
"Bill Cunningham" <no****@nspam.comwrites:
>(stufff)
You are for sure trolling. Please stop.
No, in fact Bill has some learning difficulty as far as we can discern.
--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Jun 27 '08 #17

P: n/a
Mark McIntyre <ma**********@spamcop.netwrites:
Eligiusz Narutowicz wrote:
>"Bill Cunningham" <no****@nspam.comwrites:
>>(stufff)

>You are for sure trolling. Please stop.

No, in fact Bill has some learning difficulty as far as we can
discern.
This is impossible. How can anyone at this stage ask if a normal "int"
function can return -1 and then guess that it can not?
Jun 27 '08 #18

P: n/a
Eligiusz Narutowicz wrote:
Mark McIntyre <ma**********@spamcop.netwrites:
>Eligiusz Narutowicz wrote:
>>"Bill Cunningham" <no****@nspam.comwrites:
(stufff)
>>You are for sure trolling. Please stop.
No, in fact Bill has some learning difficulty as far as we can
discern.

This is impossible. How can anyone at this stage ask if a normal "int"
function can return -1 and then guess that it can not?
Suggest you find out what "learning difficulties" means.

Jun 27 '08 #19

P: n/a
Mark McIntyre <ma**********@spamcop.netwrites:
Eligiusz Narutowicz wrote:
>Mark McIntyre <ma**********@spamcop.netwrites:
>>Eligiusz Narutowicz wrote:
"Bill Cunningham" <no****@nspam.comwrites:
(stufff)

You are for sure trolling. Please stop.
No, in fact Bill has some learning difficulty as far as we can
discern.

This is impossible. How can anyone at this stage ask if a normal "int"
function can return -1 and then guess that it can not?

Suggest you find out what "learning difficulties" means.
I know what learning difficulties means. Please do not be so rude. But I
refuse to believe that someone who can get on usenet and post such
questions does not know what a signed int is for returning from a
function. It seems incredible. If he really is slow then he needs to be
elsewhere than this group and perform a proper tutorial or course.

Jun 27 '08 #20

P: n/a
In article <g0**********@registered.motzarella.org>,
Eligiusz Narutowicz <el*************@hotmail.comwrote:
>This is impossible. How can anyone at this stage ask if a normal "int"
function can return -1 and then guess that it can not?
If you look at the rest of the thread you will see that this is not
what he meant: he just expressed himself badly. He really wanted to
know if calling exit(-1) from functions other than main was just
as unportable as returning -1 from main.

-- Richard

--
:wq
Jun 27 '08 #21

P: n/a
Eligiusz Narutowicz wrote:
Mark McIntyre <ma**********@spamcop.netwrites:
>Eligiusz Narutowicz wrote:
>>Mark McIntyre <ma**********@spamcop.netwrites:

No, in fact Bill has some learning difficulty as far as we can
discern.
....
>>This is impossible.
....
>Suggest you find out what "learning difficulties" means.

I know what learning difficulties means.
Good. Then perhaps you could consider how on earth you can possibly know
what is possible and impossible for someone you've never met?
Please do not be so rude.
*shrug*. It wasn't rude, but if you want to consider it so that's your
prerogative.
But I
refuse to believe that someone who can get on usenet
I can't help what you believe. I'm posting the facts as we know them and
have observed from Bill's posts here over the last several years.

Enough, no more - tis not so sweet now as it was before.
Jun 27 '08 #22

P: n/a
Mark McIntyre <ma**********@spamcop.netwrites:
Eligiusz Narutowicz wrote:
>Mark McIntyre <ma**********@spamcop.netwrites:
>>Eligiusz Narutowicz wrote:
Mark McIntyre <ma**********@spamcop.netwrites:

No, in fact Bill has some learning difficulty as far as we can
discern.
...
>>>This is impossible.
...
>>Suggest you find out what "learning difficulties" means.

I know what learning difficulties means.

Good. Then perhaps you could consider how on earth you can possibly
know what is possible and impossible for someone you've never met?
>Please do not be so rude.

*shrug*. It wasn't rude, but if you want to consider it so that's your
prerogative.
>But I
refuse to believe that someone who can get on usenet

I can't help what you believe. I'm posting the facts as we know them
and have observed from Bill's posts here over the last several years.

Enough, no more - tis not so sweet now as it was before.
Sigh ok. But considering how you answer some not so slow people I am
astonished who think he is retarded as opposed to a troll. Someone who
is capable of posting to usnet surely understands brackets and scope in
C by now? I find it troubling that he can not. If he really is so slow
then maybe there are better places for him to learning C.
Jun 27 '08 #23

P: n/a


Last time I get into this thread, Bill say that he know enough about
the subject(by May 13, 6:47 pm). Something like "Thanks very much.
That answers my question completely".

Maybe one should create a new group called
comp.moderated.only.and.just.only.std.and.wiz.c

Regards
Rafael
Jun 27 '08 #24

P: n/a
Bill Cunningham wrote:
>
"Richard Tobin" <ri*****@cogsci.ed.ac.ukwrote in message
news:g0***********@pc-news.cogsci.ed.ac.uk...
>There's no problem returning -1 from main() either, as far as the C
program is concerned. All that's undefined is how the "host
environment" - the shell or operating system or parent program -
interprets it. 0 (or EXIT_SUCCESS) indicates success. EXIT_FAILURE
indicates failure. What anything else means depends on your system.

[snip]

That's what I am concerned with. How the host system will react.
What I
am really concerned with is what the standard says would run best on
any environment. I write small C programs in linux and I want to be
able to take the same source code to my windows system and compile it
there and get the same results. I am trying to get into the habit of
treating all code as development code so it would work in all host
environments.
In this case your best method (for now) is to use EXIT_SUCCESS and
EXIT_FAILURE as appropriate. This will work on all conforming
implementations. The only disadvantage is that there is only a single
abnormal termination status value. You probably won't need multiple
values for most programs, but if you do need them, then you may have to
place system specific code surrounded by #ifdefs.

Jun 27 '08 #25

P: n/a

"Eligiusz Narutowicz" <el*************@hotmail.comwrote in message
news:g0**********@registered.motzarella.org...
This is impossible. How can anyone at this stage ask if a normal "int"
function can return -1 and then guess that it can not?
I don't believe that is what I asked. My post reads "portability". Not
can an int type return an int. This is not so much about the return types of
C but portability of ending functions with success or failure on different
implementations. I have been told return -1 was "wrong" (not portable). I
wanted the voice of experience.

No tutorial has ever spoke to me about the reactions of different
implementations or this post would never have been made. I wanted to get
straight ending with success or failure with a function. I only post to clc
after I have
1) read a topic and am confused
2) and tried by trial and error and can't determine the straight answer by
trial and error.

I do have problems that are worsened by Klonopin. Read the side effects
of that. Confusion. But

I think you need to read the topic of a thread before guessing it's
about return types as per values other than the topic like success or
failure and its portability and the standard.
Jun 27 '08 #26

P: n/a

[snip]

"Eligiusz Narutowicz" <el*************@hotmail.comwrote in message
news:g0**********@registered.motzarella.org...
Sigh ok. But considering how you answer some not so slow people I am
astonished who think he is retarded as opposed to a troll. Someone who
is capable of posting to usnet surely understands brackets and scope in
C by now?
Brackets and scope? Yes I understand that. What does that have to do with
anything? It's "implmentations" and "portability" that was the question. And
I never expected this thread to become this large. I thought 2-4 responses
would be made. I am grateful to those who have answered my question(s).

[snip]

Jun 27 '08 #27

P: n/a
On May 14, 10:03*pm, "Bill Cunningham" <nos...@nspam.comwrote:
"Eligiusz Narutowicz" <eligiuszdotn...@hotmail.comwrote in message

news:g0**********@registered.motzarella.org...
This is impossible. How can anyone at this stage ask if a normal "int"
function can return -1 and then guess that it can not?

* * No tutorial has ever spoke to me about the reactions of different
implementations or this post would never have been made. I wanted to get
straight ending with success or failure with a function. I only post to clc
after I have
1) read a topic and am confused
2) and tried by trial and error and can't determine the straight answer by
trial and error.
This my approach to return in main():

(1) Completely ignore it
(2) If you /have/ to return a value, return anything (really, mostly
it doesn't matter)
(3) If someone/something complains, or it /does/ matter, return one of
EXIT_SUCCESS or EXIT_FAILURE, but those stick out like a sore thumb,
ruining the lines of my code (I don't like capitals much)

Your tutorial is taking the attitude that it's of little practical
importance to someone learning the language, which sounds right. There
are many more interesting things to worry about!

--
Bartc
Jun 27 '08 #28

P: n/a
"Bill Cunningham" <no****@nspam.comwrites:
"Eligiusz Narutowicz" <el*************@hotmail.comwrote in message
news:g0**********@registered.motzarella.org...
>This is impossible. How can anyone at this stage ask if a normal "int"
function can return -1 and then guess that it can not?

I don't believe that is what I asked. My post reads "portability". Not
can an int type return an int. This is not so much about the return types of
C but portability of ending functions with success or failure on different
implementations. I have been told return -1 was "wrong" (not portable). I
wanted the voice of experience.
[...]

I think your question was already answered, but I'll summarize.

A program can return a status code (of type int) to the host
environment (as it terminates) either by calling exit() with the
desired status as an argument, or by executing a return statement
within main(), returning the desired status. These two are
essentially equivalent. exit() can be called from anywhere, not just
from main().

The only portable status codes are 0, EXIT_SUCCESS, and EXIT_FAILURE.
Other values can be useful, but only in code intended for a particular
system.

Results returned by functions other than main() generally have
*nothing* to do with program status codes, so the advice to use 0,
EXIT_SUCCESS, or EXIT_FAILURE does not apply. The value you should
return from main() (or, equivalently, the value you should pass to
exit() is constrained by the host environment. The value you should
return from any other function is constrained by the requirements for
that function, something internal to your program.

Please feel free to ignore the following paragraph.

Returning a value from main and calling exit() with that same value
are *almost* equivalent. They can differ in an obscure and unlikely
scenario involving the atexit() function. They can also differ if you
call main() recursively, something that there's practically never a
good reason to do.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
Jun 27 '08 #29

P: n/a
Bart <bc@freeuk.comwrites:
[...]
This my approach to return in main():

(1) Completely ignore it
(2) If you /have/ to return a value, return anything (really, mostly
it doesn't matter)
(3) If someone/something complains, or it /does/ matter, return one of
EXIT_SUCCESS or EXIT_FAILURE, but those stick out like a sore thumb,
ruining the lines of my code (I don't like capitals much)
Here's a better approach.

(1) Add ``return 0;'' immediately before the closing brace of your
main() function. Just think of it as part of the syntax.
(2) If you need to indicate failure, use EXIT_FAILURE. That's what
it's for. If you don't like capital letters, get over it.
(3) Consider using other values only if you need system-specific
status information.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
Jun 27 '08 #30

P: n/a
Eligiusz Narutowicz wrote:
Mark McIntyre <ma**********@spamcop.netwrites:
>Eligiusz Narutowicz wrote:
>>Mark McIntyre <ma**********@spamcop.netwrites:

Eligiusz Narutowicz wrote:
"Bill Cunningham" <no****@nspam.comwrites:
>(stufff)
You are for sure trolling. Please stop.
No, in fact Bill has some learning difficulty as far as we can
discern.
This is impossible. How can anyone at this stage ask if a normal "int"
function can return -1 and then guess that it can not?
Suggest you find out what "learning difficulties" means.

I know what learning difficulties means.
You know what "English comprehension difficulties" means,
first hand.
Please do not be so rude.
Why not?
But I
refuse to believe that someone who can get on usenet and post such
questions does not know what a signed int is for returning from a
function. It seems incredible. If he really is slow then he needs to be
elsewhere than this group and perform a proper tutorial or course.
That won't help.

Bill is always on topic and never haughty.
I have my own priorities and that's good enough for me.

--
pete
Jun 27 '08 #31

P: n/a
Bart wrote:
(3) If someone/something complains, or it /does/ matter, return one of
EXIT_SUCCESS or EXIT_FAILURE, but those stick out like a sore thumb,
ruining the lines of my code (I don't like capitals much)
#ifdef bart_source
#define exit_failure EXIT_FAILURE
#define exit_success EXIT_SUCCESS
#endif

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jun 27 '08 #32

P: n/a

"jacob navia" <ja***@nospam.orgwrote in message
news:48*********************@news.orange.fr...
Bart wrote:
>(3) If someone/something complains, or it /does/ matter, return one of
EXIT_SUCCESS or EXIT_FAILURE, but those stick out like a sore thumb,
ruining the lines of my code (I don't like capitals much)

#ifdef bart_source
#define exit_failure EXIT_FAILURE
#define exit_success EXIT_SUCCESS
#endif
I don't like caps either. I think I would use the preprocessor
directives like this.

#define FIL exit(EXIT_FAILURE);

On that exit macro.

Bill
Jun 27 '08 #33

P: n/a
On May 15, 12:15*am, jacob navia <ja...@nospam.orgwrote:
Bart wrote:
(3) If someone/something complains, or it /does/ matter, return one of
EXIT_SUCCESS or EXIT_FAILURE, but those stick out like a sore thumb,
ruining the lines of my code (I don't like capitals much)

#ifdef bart_source
#define exit_failure EXIT_FAILURE
#define exit_success EXIT_SUCCESS
#endif
Yes, I know, there's all sorts of little things I can add to enhance
my C programming experience.

But in the end this is just creating my own slightly different (or
possibly very different) version of the language. Which is great,
until I have to post code to this group for example.

--
Bartc
Jun 27 '08 #34

P: n/a
"Bill Cunningham" <no****@nspam.comwrites:
"jacob navia" <ja***@nospam.orgwrote in message
news:48*********************@news.orange.fr...
>Bart wrote:
>>(3) If someone/something complains, or it /does/ matter, return one of
EXIT_SUCCESS or EXIT_FAILURE, but those stick out like a sore thumb,
ruining the lines of my code (I don't like capitals much)

#ifdef bart_source
#define exit_failure EXIT_FAILURE
#define exit_success EXIT_SUCCESS
#endif

I don't like caps either. I think I would use the preprocessor
directives like this.

#define FIL exit(EXIT_FAILURE);

On that exit macro.
That's not nearly as good an idea as it might aeppar to be.

Everybody knows what ``exit(EXIT_FAILURE);'' means. Nobody but you
knows what ``FIL'' means. Think about the people who are going to be
reading your code.

To quote Henry Spencer's Ten Commandments for C Programmers, "... thy
creativity is better used in solving problems than in creating
beautiful new impediments to understanding".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
Jun 27 '08 #35

P: n/a
Bill Cunningham wrote:
"jacob navia" <ja***@nospam.orgwrote in message
news:48*********************@news.orange.fr...
>Bart wrote:
>>(3) If someone/something complains, or it /does/ matter, return one of
EXIT_SUCCESS or EXIT_FAILURE, but those stick out like a sore thumb,
ruining the lines of my code (I don't like capitals much)
#ifdef bart_source
#define exit_failure EXIT_FAILURE
#define exit_success EXIT_SUCCESS
#endif

I don't like caps either. I think I would use the preprocessor
directives like this.

#define FIL exit(EXIT_FAILURE);

On that exit macro.
Oh god No, please no, don't do that!!!
I hate code like that.

http://groups.google.com/group/comp....1fa1c247b8c4e5

--
pete
Jun 27 '08 #36

P: n/a
On 14 May, 20:07, "sos...@terra.com.br" <sos...@terra.com.brwrote:

<snip>
>
Maybe one should create a new group called
comp.moderated.only.and.just.only.std.and.wiz.c
why don't you create it if you think there is a demand?
Presumably you'd be willing to moderate it.

--
Nick Keighley
Jun 27 '08 #37

P: n/a
On 15 May, 00:57, Bart <b...@freeuk.comwrote:
On May 15, 12:15*am, jacob navia <ja...@nospam.orgwrote:
Bart wrote:
(3) If someone/something complains, or it /does/ matter, return one of
EXIT_SUCCESS or EXIT_FAILURE, but those stick out like a sore thumb,
ruining the lines of my code (I don't like capitals much)
#ifdef bart_source
#define exit_failure EXIT_FAILURE
#define exit_success EXIT_SUCCESS
#endif

Yes, I know, there's all sorts of little things I can add to enhance
my C programming experience.

But in the end this is just creating my own slightly different (or
possibly very different) version of the language. Which is great,
until I have to post code to this group for example.
so why recomend non-standard programming practices like
"return anything you like it doesn't matter"?

--
Nick Keighley

Jun 27 '08 #38

P: n/a
On May 15, 9:49*am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 15 May, 00:57, Bart <b...@freeuk.comwrote:

On May 15, 12:15*am, jacob navia <ja...@nospam.orgwrote:
Bart wrote:
(3) If someone/something complains, or it /does/ matter, return one of
EXIT_SUCCESS or EXIT_FAILURE, but those stick out like a sore thumb,
ruining the lines of my code (I don't like capitals much)
#define exit_failure EXIT_FAILURE
#define exit_success EXIT_SUCCESS
But in the end this is just creating my own slightly different (or
possibly very different) version of the language. Which is great,
until I have to post code to this group for example.

so why recomend non-standard programming practices like
"return anything you like it doesn't matter"?
Because it doesn't change the syntax so that it won't compile? And I
have posted such code myself (missing main returns and the like) and
it's rarely picked up.

Anyway maybe I should have said 'return 0'. Zero is a good choice.
--
Bartc
Jun 27 '08 #39

P: n/a
On May 15, 8:18*am, Keith Thompson <ks...@mib.orgwrote:
"Bill Cunningham" <nos...@nspam.comwrites:
"jacobnavia" <ja...@nospam.orgwrote in message
news:48*********************@news.orange.fr...
Bart wrote:
(3) If someone/something complains, or it /does/ matter, return one of
EXIT_SUCCESS or EXIT_FAILURE, but those stick out like a sore thumb,
ruining the lines of my code (I don't like capitals much)
#ifdef bart_source
#define exit_failure EXIT_FAILURE
#define exit_success EXIT_SUCCESS
#endif
* * I don't like caps either. I think I would use the preprocessor
directives like this.
#define FIL exit(EXIT_FAILURE);
On that exit macro.

That's not nearly as good an idea as it might aeppar to be.

Everybody knows what ``exit(EXIT_FAILURE);'' means. *Nobody but you
knows what ``FIL'' means. *Think about the people who are going to be
reading your code.

To quote Henry Spencer's Ten Commandments for C Programmers, "... thy
creativity is better used in solving problems than in creating
beautiful new impediments to understanding".
Wow, Ten Commandments. Myth becomes Enlightenment, and Enlightenment,
Myth.

Man subordinates man to Enlightenment and before you know it:

(1) Nobody gets laid
(2) Fear-filled people pass along commandments and saws
(3) Objectivity becomes subjectivity and vice versa
(4) Power Point walks the earth

These discussions have no exit. Some programmers at some time need
everything written out. But then you get Cobol, and suddenly,
everybunny wants the code they read to be written gnomically in a
small and orthogonal set of runes.

Leave the cave and walk in the sunlight.
>
--
Keith Thompson (The_Other_Keith) ks...@mib.org *<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"- Hide quoted text -

- Show quoted text -
Jun 27 '08 #40

P: n/a
On May 15, 8:18*am, pete <pfil...@mindspring.comwrote:
Bill Cunningham wrote:
"jacobnavia" <ja...@nospam.orgwrote in message
news:48*********************@news.orange.fr...
Bart wrote:
(3) If someone/something complains, or it /does/ matter, return one of
EXIT_SUCCESS or EXIT_FAILURE, but those stick out like a sore thumb,
ruining the lines of my code (I don't like capitals much)
#ifdef bart_source
#define exit_failure EXIT_FAILURE
#define exit_success EXIT_SUCCESS
#endif
* * I don't like caps either. I think I would use the preprocessor
directives like this.
#define FIL exit(EXIT_FAILURE);
On that exit macro.

Oh god No, please no, don't do that!!!
I hate code like that.

http://groups.google.com/group/comp....1fa1c247b8c4e5

--
pete- Hide quoted text -

- Show quoted text -
Another part of the myth and enlightenment dialectic is the death of
delight. We hate code: we love code. The popular song becomes
something people can't stand, like Jim Morrison's The End, which is a
real stinkbomb on the jukebox.

C's #define statement is a joke. It means that real programs in C
simply cannot be trusted in a modern environment.
Jun 27 '08 #41

P: n/a
spinoza1111 said:

<snip>
C's #define statement is a joke. It means that real programs in C
simply cannot be trusted in a modern environment.
Can you justify that claim with an example?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #42

P: n/a
Bart <bc@freeuk.comwrites:
>... I
have posted such code myself (missing main returns and the like) and
it's rarely picked up.
Maybe because it is not wrong in the formal sense? It is not
maximally portable, nor is it the best style, but it is permitted in
C99.
Anyway maybe I should have said 'return 0'. Zero is a good choice.
Much better. However, as someone brought up on *nix systems, the
returned value from main seems far too important to loose. Even if
all your programs end up as big GUI things that are never co-opted into
scripts or other bigger systems, it is so easy to return the right
thing it seems a shame not to.

--
Ben.
Jun 27 '08 #43

P: n/a
Bart wrote:
On May 15, 12:15 am, jacob navia <ja...@nospam.orgwrote:
>Bart wrote:
>>(3) If someone/something complains, or it /does/ matter, return one of
EXIT_SUCCESS or EXIT_FAILURE, but those stick out like a sore thumb,
ruining the lines of my code (I don't like capitals much)
#ifdef bart_source
#define exit_failure EXIT_FAILURE
#define exit_success EXIT_SUCCESS
#endif

Yes, I know, there's all sorts of little things I can add to enhance
my C programming experience.

But in the end this is just creating my own slightly different (or
possibly very different) version of the language. Which is great,
until I have to post code to this group for example.
More generally: Until you try to get someone other than
yourself to read it.

When I was young and dumb, I thought the do...while loop
was silly so I habitually wrote

#define until(x) while(!(x))

do { whatever(); } until(done);

.... and thought I was being Terribly Clever by finding a way
to write clearer-than-normal C. What I'd failed to realize
was that *everybody* could read do...while(!done) without any
pause to wonder what was going on, but that my "clearer"
construct forced a reader to interrupt his reading and go
hunt for the definition of `until' and convince himself that
I'd written it correctly (not as `while(!x)', for example).
My Terribly Clever definition was just the sort of thing
already mentioned in this thread: a beautiful new impediment
to understanding.

There's an Eleventh Commandment floating around somewhere,
to the effect that "Thou shalt not use the preprocessor to mess
with the syntax." This apocryphal pseudo-commandment is not
among the canonical Ten, and in my opinion it doesn't belong
there: Sometimes, messing with the syntax is exactly the right
thing to do. But it's usually a poor idea, and the non-commandment
has merit as a guideline to be breached only after careful
consideration, and not for trivial decorative purposes.

--
Er*********@sun.com
Jun 27 '08 #44

P: n/a
On May 15, 9:02*pm, Richard Heathfield <r...@see.sig.invalidwrote:
spinoza1111said:

<snip>
C's #define statement is a joke. It means that real programs in C
simply cannot be trusted in a modern environment.

Can you justify that claim with an example?
That's like making a movie about what it is to be an oppressed member
of the proletariat (cf Kracauer): the movie would be so sordid and
tedious, reflecting as it would have to the sordidness and tedium of
working-class life, as to drive the audience away. The brilliant
Terence Malick, on the other hand, conveyed the actual "feel" of
military "work" in his film the Thin Red Line, with its focus on the
mechanics of an offensive and the constant frustration of the audience
when (for example) the troops land on an undefended beach.

I mean, of course, that you completely misapprehend, as we've come to
expect, the meaning of code examples.

Not only do you attack people frivolously based on your
interpretations of polysemic examples (examples capable of radically
different meanings either technically as with #define, or socially, as
in terms of the "user's" expectations), you invalidly reason from them
and expect people to construct working large systems from examples you
provide, without integration.

However, there's the classic example:

#define MACRO(a, b) a*b

where, of course, unexpected results occur when the formal parameters
a and b are replaced by actual parameters with operators of lower
precedence.

If a "new" C program uses #include to #include some old horse puckey
that doesn't religiously follow the workaround to this problem (which
is well-known but not enough: parenthesize all formal parameters in
the macro body), then it needs to be audited line by line.

What can't be re-presented of course is the proletarianizing effect of
such tasking, in which one has to waste hours because some clown
either didn't know the rule, or else, or worse, used "code examples"
blindly given to him in the kingdom of the blind.

What can't be re-presented is the fact that "best practice" vis a vis
#defines, especially with formal parameters, is not to use the
feature. That is, the "expert C programmer" eventually is one defined
by his innocence, his ignorance of the unsafe features.
>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #45

P: n/a
spinoza1111 said:
On May 15, 9:02 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>spinoza1111said:

<snip>
C's #define statement is a joke. It means that real programs in C
simply cannot be trusted in a modern environment.

Can you justify that claim with an example?

That's like making a movie about what it is to be an oppressed member
of the proletariat (cf Kracauer):
If you want to talk C, fine - drop the pretentious pseud-speak and we can
talk C. If you want to talk pretentious pseud-speak, don't imagine for a
second that anyone in comp.lang.c is even remotely interested.

On this one occasion only, I will filter through the pseud-speak and look
for the C. In future, drop the pseud-speak and stick to the C, because I
don't see why anyone should have to wade through your drivel just to find
out whether you have anything worthwhile to say about C.

<pretentious pseud-speak snipped>
However, there's the classic example:

#define MACRO(a, b) a*b

where, of course, unexpected results occur
If you write stupid code, stupid things might happen. So what? You can
write stupid code in any language. And the dangers of stupid macros are
well known. Even Herbert Schildt knows of the above danger - see CTCR2e,
pp264-265.
If a "new" C program uses #include to #include some old horse puckey
that doesn't religiously follow the workaround to this problem (which
is well-known but not enough: parenthesize all formal parameters in
the macro body), then it needs to be audited line by line.
So what you're saying is that, if you try to use broken code, it might not
work properly. Well, that is trivially true and utterly uninteresting.

<snip>
What can't be re-presented is the fact that "best practice" vis a vis
#defines, especially with formal parameters, is not to use the
feature.
Like chainsaws, #defines have their dangers. But, again like chainsaws,
#defines have their uses.
That is, the "expert C programmer" eventually is one defined
by his innocence, his ignorance of the unsafe features.
That's just stupid. It's like claiming that an expert pilot is someone who
doesn't know where the sandbanks are.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #46

P: n/a
Richard Heathfield <rj*@see.sig.invalidwrites:
spinoza1111 said:
>On May 15, 9:02 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>>spinoza1111said:

<snip>

C's #define statement is a joke. It means that real programs in C
simply cannot be trusted in a modern environment.

Can you justify that claim with an example?

That's like making a movie about what it is to be an oppressed member
of the proletariat (cf Kracauer):

If you want to talk C, fine - drop the pretentious pseud-speak and we can
talk C. If you want to talk pretentious pseud-speak, don't imagine for a
second that anyone in comp.lang.c is even remotely interested.

On this one occasion only, I will filter through the pseud-speak and look
for the C. In future, drop the pseud-speak and stick to the C, because I
don't see why anyone should have to wade through your drivel just to find
out whether you have anything worthwhile to say about C.
[...]

Richard, it must be clear by now that he *doesn't* want to talk about
C, and that he will *never* drop the pretentious pseud-speak. By
replying to him, you merely provoke him into inflicting more of his
meaningless crud on the rest of us. I encourage you to ignore him as
you would ignore any troll or spammer, at least here in comp.lang.c.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
Jun 27 '08 #47

This discussion thread is closed

Replies have been disabled for this discussion.