Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #120928 > unrolled thread
| Started by | wij <wyniijj5@gmail.com> |
|---|---|
| First post | 2024-11-20 11:02 +0800 |
| Last post | 2025-02-15 16:21 -0800 |
| Articles | 20 on this page of 92 — 19 participants |
Back to article view | Back to comp.lang.c++
Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-20 11:02 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-20 09:22 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-20 08:27 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 13:47 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-20 15:05 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 15:45 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-20 16:41 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 13:37 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 22:11 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 14:33 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 23:03 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 15:57 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 15:58 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:43 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-21 16:07 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 17:55 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? David Brown <david.brown@hesbynett.no> - 2024-11-22 09:30 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-22 11:10 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@dastardlyhq.com - 2024-11-23 11:36 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-22 12:26 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-22 12:49 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-22 23:26 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? David Brown <david.brown@hesbynett.no> - 2024-11-23 13:07 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 13:55 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-01 20:57 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-22 09:55 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-26 04:21 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-22 11:57 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-22 11:31 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-22 12:36 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-22 16:53 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-24 12:57 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 14:03 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-26 12:21 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-27 16:23 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-27 08:26 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-27 18:48 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-27 15:39 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-27 13:54 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-27 17:24 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-27 16:12 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Richard Damon <richard@damon-family.org> - 2024-11-27 13:00 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 08:23 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 15:06 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Richard Damon <richard@damon-family.org> - 2024-11-28 08:08 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:58 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-27 19:46 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 08:26 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-28 13:03 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ralf Fassel <ralfixx@gmx.de> - 2024-11-28 12:15 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-28 13:36 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ralf Fassel <ralfixx@gmx.de> - 2024-11-28 14:12 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Richard Damon <richard@damon-family.org> - 2024-11-28 07:50 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 15:19 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 15:12 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 17:36 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? David Brown <david.brown@hesbynett.no> - 2024-11-28 16:43 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 15:59 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-28 10:19 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-28 22:41 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-29 00:21 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-29 00:59 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-29 01:20 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-28 17:18 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-27 19:01 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 08:22 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-27 11:00 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:57 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-27 13:52 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:54 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 15:27 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-27 15:30 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-28 18:32 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 14:00 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-25 14:15 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-01 21:00 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-26 04:26 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-20 23:20 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-20 17:32 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? red floyd <no.spam.here@its.invalid> - 2024-11-20 22:56 -0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:52 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:51 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 13:44 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-20 22:57 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-20 17:23 +0200
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-20 23:09 -0500
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:52 +0000
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-21 22:45 +0800
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Rosario19 <Ros@invalid.invalid> - 2024-11-25 22:20 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-11-26 10:20 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Rosario19 <Ros@invalid.invalid> - 2024-11-30 16:52 +0100
Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Andrey Tarasevich <noone@noone.net> - 2025-02-15 16:21 -0800
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-11-20 11:02 +0800 |
| Subject | Is EXIT_SUCCESS/EXIT_FAILURE necessary? |
| Message-ID | <8463694f3a751b287c857fca181451f36eeee982.camel@gmail.com> |
EXIT_SUCCESS/EXIT_FAILURE are for communication between different programs. But, is it necessary? E.g. can it be put into shell script? I think the macro EXIT_SUCCESS/EXIT_FAILURE may be good within a group of programs for some reason, but generally, exit code of program is a numerical value. Why EXIT_SUCCESS?
[toc] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-11-20 09:22 +0200 |
| Message-ID | <vhk2mv$2aq09$1@dont-email.me> |
| In reply to | #120928 |
On 20.11.2024 05:02, wij wrote: > EXIT_SUCCESS/EXIT_FAILURE are for communication between different programs. > But, is it necessary? E.g. can it be put into shell script? > I think the macro EXIT_SUCCESS/EXIT_FAILURE may be good within a group of > programs for some reason, but generally, exit code of program is a numerical > value. Why EXIT_SUCCESS? > > EXIT_SUCCESS is an attempt to provide an abstraction which was attempted to cover more different platforms than POSIX style exit codes. The idea was that one can use EXIT_SUCCESS and EXIT_FAILURE regardless whether the program is compiled to run on some Unix, on some weird mainframe with weird exit code values, or in some free-standing implementation where there is no OS, not to speak about shell scripts. Even on Linux or Windows, note that the exit code numeric values contradict the conventions of C and C++ where 1 is normally converted to true and 0 to false. So to reduce confusion it might be a good idea to use the macros even here. Note that nowadays there are many programmers (esp. on Windows) who have no idea about program exit code conventions or shell scripts.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastartdlyHQ.org |
|---|---|
| Date | 2024-11-20 08:27 +0000 |
| Message-ID | <vhk6gv$pkc$1@dont-email.me> |
| In reply to | #120931 |
On Wed, 20 Nov 2024 09:22:07 +0200 Paavo Helde <eesnimi@osa.pri.ee> boring babbled: >On 20.11.2024 05:02, wij wrote: >> EXIT_SUCCESS/EXIT_FAILURE are for communication between different programs. >> But, is it necessary? E.g. can it be put into shell script? >> I think the macro EXIT_SUCCESS/EXIT_FAILURE may be good within a group of >> programs for some reason, but generally, exit code of program is a numerical >> value. Why EXIT_SUCCESS? >> >> > >EXIT_SUCCESS is an attempt to provide an abstraction which was attempted >to cover more different platforms than POSIX style exit codes. The idea >was that one can use EXIT_SUCCESS and EXIT_FAILURE regardless whether >the program is compiled to run on some Unix, on some weird mainframe >with weird exit code values, or in some free-standing implementation >where there is no OS, not to speak about shell scripts. > >Even on Linux or Windows, note that the exit code numeric values >contradict the conventions of C and C++ where 1 is normally converted to >true and 0 to false. So to reduce confusion it might be a good idea to >use the macros even here. Note that nowadays there are many programmers >(esp. on Windows) who have no idea about program exit code conventions >or shell scripts. Even within Posix return values are inconsistent. Most posix functions return -1 for failure, >= 0 for success and set errno, not so the pthread_*() functions which return the errno directly on failure and zero for success. A poor decision IMO.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-11-20 13:47 +0000 |
| Message-ID | <dMl%O.42746$LlWc.32358@fx42.iad> |
| In reply to | #120933 |
Muttley@DastartdlyHQ.org writes: >On Wed, 20 Nov 2024 09:22:07 +0200 >Paavo Helde <eesnimi@osa.pri.ee> boring babbled: >>On 20.11.2024 05:02, wij wrote: >>> EXIT_SUCCESS/EXIT_FAILURE are for communication between different programs. >>> But, is it necessary? E.g. can it be put into shell script? >>> I think the macro EXIT_SUCCESS/EXIT_FAILURE may be good within a group of >>> programs for some reason, but generally, exit code of program is a numerical >>> value. Why EXIT_SUCCESS? >>> >>> >> >>EXIT_SUCCESS is an attempt to provide an abstraction which was attempted >>to cover more different platforms than POSIX style exit codes. The idea >>was that one can use EXIT_SUCCESS and EXIT_FAILURE regardless whether >>the program is compiled to run on some Unix, on some weird mainframe >>with weird exit code values, or in some free-standing implementation >>where there is no OS, not to speak about shell scripts. >> >>Even on Linux or Windows, note that the exit code numeric values >>contradict the conventions of C and C++ where 1 is normally converted to >>true and 0 to false. So to reduce confusion it might be a good idea to >>use the macros even here. Note that nowadays there are many programmers >>(esp. on Windows) who have no idea about program exit code conventions >>or shell scripts. > >Even within Posix return values are inconsistent. Most posix functions >return -1 for failure, >= 0 for success and set errno, not so the pthread_*() >functions which return the errno directly on failure and zero for success. >A poor decision IMO. Before POSIX.4 was introducted (pthreads), the convention was return -1 for failure with ERRNO set. With the introduction of multi-threaded programs by POSIX.4, the convention -for new posix functions- is to return ERRNO directly to avoid using the global (or in modern systems thread-specific) errno. This was a deliberate choice by the POSIX.4 working group.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastartdlyHQ.org |
|---|---|
| Date | 2024-11-20 15:05 +0000 |
| Message-ID | <vhktsg$55qc$1@dont-email.me> |
| In reply to | #120936 |
On Wed, 20 Nov 2024 13:47:53 GMT scott@slp53.sl.home (Scott Lurndal) boring babbled: >Muttley@DastartdlyHQ.org writes: >>Even within Posix return values are inconsistent. Most posix functions >>return -1 for failure, >= 0 for success and set errno, not so the pthread_*() > >>functions which return the errno directly on failure and zero for success. >>A poor decision IMO. > >Before POSIX.4 was introducted (pthreads), the convention was return -1 >for failure with ERRNO set. > >With the introduction of multi-threaded programs by POSIX.4, the >convention -for new posix functions- is to return ERRNO directly >to avoid using the global (or in modern systems thread-specific) >errno. This was a deliberate choice by the POSIX.4 working group. Without changing every other posix function behaviour its a pointless gesture that just causes confusion as errno will still be used elsewhere.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-11-20 15:45 +0000 |
| Message-ID | <3un%O.4461$rXyb.2345@fx48.iad> |
| In reply to | #120938 |
Muttley@DastartdlyHQ.org writes: >On Wed, 20 Nov 2024 13:47:53 GMT >scott@slp53.sl.home (Scott Lurndal) boring babbled: >>Muttley@DastartdlyHQ.org writes: >>>Even within Posix return values are inconsistent. Most posix functions >>>return -1 for failure, >= 0 for success and set errno, not so the pthread_*() >> >>>functions which return the errno directly on failure and zero for success. >>>A poor decision IMO. >> >>Before POSIX.4 was introducted (pthreads), the convention was return -1 >>for failure with ERRNO set. >> >>With the introduction of multi-threaded programs by POSIX.4, the >>convention -for new posix functions- is to return ERRNO directly >>to avoid using the global (or in modern systems thread-specific) >>errno. This was a deliberate choice by the POSIX.4 working group. > >Without changing every other posix function behaviour its a pointless gesture >that just causes confusion as errno will still be used elsewhere. > That was clearly not the opinion of the POSIX working group. Anyone confused by the fact that the interface set is not completely uniform probably needs to look for a different job if they are unable to RTFM
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastartdlyHQ.org |
|---|---|
| Date | 2024-11-20 16:41 +0000 |
| Message-ID | <vhl3fa$6961$1@dont-email.me> |
| In reply to | #120942 |
On Wed, 20 Nov 2024 15:45:03 GMT scott@slp53.sl.home (Scott Lurndal) boring babbled: >Muttley@DastartdlyHQ.org writes: >>On Wed, 20 Nov 2024 13:47:53 GMT >>scott@slp53.sl.home (Scott Lurndal) boring babbled: >>>Muttley@DastartdlyHQ.org writes: >>>>Even within Posix return values are inconsistent. Most posix functions >>>>return -1 for failure, >= 0 for success and set errno, not so the >pthread_*() >>> >>>>functions which return the errno directly on failure and zero for success. >>>>A poor decision IMO. >>> >>>Before POSIX.4 was introducted (pthreads), the convention was return -1 >>>for failure with ERRNO set. >>> >>>With the introduction of multi-threaded programs by POSIX.4, the >>>convention -for new posix functions- is to return ERRNO directly >>>to avoid using the global (or in modern systems thread-specific) >>>errno. This was a deliberate choice by the POSIX.4 working group. >> >>Without changing every other posix function behaviour its a pointless gesture >>that just causes confusion as errno will still be used elsewhere. >> > >That was clearly not the opinion of the POSIX working group. Committees don't always make the best decision as the current state of C++ demonstrates. >Anyone confused by the fact that the interface set is not >completely uniform probably needs to look for a different >job if they are unable to RTFM If you think consistency within an API is unimportant then I suggest it might be you who belongs in another career.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-20 13:37 -0800 |
| Message-ID | <vhlkqd$9bih$3@dont-email.me> |
| In reply to | #120931 |
On 11/19/2024 11:22 PM, Paavo Helde wrote: > On 20.11.2024 05:02, wij wrote: >> EXIT_SUCCESS/EXIT_FAILURE are for communication between different >> programs. >> But, is it necessary? E.g. can it be put into shell script? >> I think the macro EXIT_SUCCESS/EXIT_FAILURE may be good within a group of >> programs for some reason, but generally, exit code of program is a >> numerical >> value. Why EXIT_SUCCESS? >> >> > > EXIT_SUCCESS is an attempt to provide an abstraction which was attempted > to cover more different platforms than POSIX style exit codes. The idea > was that one can use EXIT_SUCCESS and EXIT_FAILURE regardless whether > the program is compiled to run on some Unix, on some weird mainframe > with weird exit code values, or in some free-standing implementation > where there is no OS, not to speak about shell scripts. > > Even on Linux or Windows, note that the exit code numeric values > contradict the conventions of C and C++ where 1 is normally converted to > true and 0 to false. So to reduce confusion it might be a good idea to > use the macros even here. Note that nowadays there are many programmers > (esp. on Windows) who have no idea about program exit code conventions > or shell scripts. > > EXIT_SUCCESS can be 0xbeefbeef and EXIT_FAILURE can be 0xdeadbeef? Returning 0 on such a system would return EXIT_SUCCESS such that the system would say its success?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-11-20 22:11 +0000 |
| Message-ID | <C8t%O.3354$YSkc.1098@fx40.iad> |
| In reply to | #120949 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 11/19/2024 11:22 PM, Paavo Helde wrote: >> On 20.11.2024 05:02, wij wrote: >>> EXIT_SUCCESS/EXIT_FAILURE are for communication between different >>> programs. >>> But, is it necessary? E.g. can it be put into shell script? >>> I think the macro EXIT_SUCCESS/EXIT_FAILURE may be good within a group of >>> programs for some reason, but generally, exit code of program is a >>> numerical >>> value. Why EXIT_SUCCESS? >>> >>> >> >> EXIT_SUCCESS is an attempt to provide an abstraction which was attempted >> to cover more different platforms than POSIX style exit codes. The idea >> was that one can use EXIT_SUCCESS and EXIT_FAILURE regardless whether >> the program is compiled to run on some Unix, on some weird mainframe >> with weird exit code values, or in some free-standing implementation >> where there is no OS, not to speak about shell scripts. >> >> Even on Linux or Windows, note that the exit code numeric values >> contradict the conventions of C and C++ where 1 is normally converted to >> true and 0 to false. So to reduce confusion it might be a good idea to >> use the macros even here. Note that nowadays there are many programmers >> (esp. on Windows) who have no idea about program exit code conventions >> or shell scripts. >> >> > >EXIT_SUCCESS can be 0xbeefbeef and EXIT_FAILURE can be 0xdeadbeef? Not on any POSIX system. EXIT_SUCCESS must be zero. EXIT_FAILURE must be between 1 and 125 inclusive. https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/stdlib.h.html
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-20 14:33 -0800 |
| Message-ID | <vhlo4a$9ud2$1@dont-email.me> |
| In reply to | #120950 |
On 11/20/2024 2:11 PM, Scott Lurndal wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> On 11/19/2024 11:22 PM, Paavo Helde wrote: >>> On 20.11.2024 05:02, wij wrote: >>>> EXIT_SUCCESS/EXIT_FAILURE are for communication between different >>>> programs. >>>> But, is it necessary? E.g. can it be put into shell script? >>>> I think the macro EXIT_SUCCESS/EXIT_FAILURE may be good within a group of >>>> programs for some reason, but generally, exit code of program is a >>>> numerical >>>> value. Why EXIT_SUCCESS? >>>> >>>> >>> >>> EXIT_SUCCESS is an attempt to provide an abstraction which was attempted >>> to cover more different platforms than POSIX style exit codes. The idea >>> was that one can use EXIT_SUCCESS and EXIT_FAILURE regardless whether >>> the program is compiled to run on some Unix, on some weird mainframe >>> with weird exit code values, or in some free-standing implementation >>> where there is no OS, not to speak about shell scripts. >>> >>> Even on Linux or Windows, note that the exit code numeric values >>> contradict the conventions of C and C++ where 1 is normally converted to >>> true and 0 to false. So to reduce confusion it might be a good idea to >>> use the macros even here. Note that nowadays there are many programmers >>> (esp. on Windows) who have no idea about program exit code conventions >>> or shell scripts. >>> >>> >> >> EXIT_SUCCESS can be 0xbeefbeef and EXIT_FAILURE can be 0xdeadbeef? > > > Not on any POSIX system. EXIT_SUCCESS must be zero. EXIT_FAILURE > must be between 1 and 125 inclusive. > > https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/stdlib.h.html > What about the strict C std, posix aside for a moment?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-11-20 23:03 +0000 |
| Message-ID | <lVt%O.3424$mjY3.1813@fx01.iad> |
| In reply to | #120951 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 11/20/2024 2:11 PM, Scott Lurndal wrote: >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>> On 11/19/2024 11:22 PM, Paavo Helde wrote: >>>> On 20.11.2024 05:02, wij wrote: >>>>> EXIT_SUCCESS/EXIT_FAILURE are for communication between different >>>>> programs. >>>>> But, is it necessary? E.g. can it be put into shell script? >>>>> I think the macro EXIT_SUCCESS/EXIT_FAILURE may be good within a group of >>>>> programs for some reason, but generally, exit code of program is a >>>>> numerical >>>>> value. Why EXIT_SUCCESS? >>>>> >>>>> >>>> >>>> EXIT_SUCCESS is an attempt to provide an abstraction which was attempted >>>> to cover more different platforms than POSIX style exit codes. The idea >>>> was that one can use EXIT_SUCCESS and EXIT_FAILURE regardless whether >>>> the program is compiled to run on some Unix, on some weird mainframe >>>> with weird exit code values, or in some free-standing implementation >>>> where there is no OS, not to speak about shell scripts. >>>> >>>> Even on Linux or Windows, note that the exit code numeric values >>>> contradict the conventions of C and C++ where 1 is normally converted to >>>> true and 0 to false. So to reduce confusion it might be a good idea to >>>> use the macros even here. Note that nowadays there are many programmers >>>> (esp. on Windows) who have no idea about program exit code conventions >>>> or shell scripts. >>>> >>>> >>> >>> EXIT_SUCCESS can be 0xbeefbeef and EXIT_FAILURE can be 0xdeadbeef? >> >> >> Not on any POSIX system. EXIT_SUCCESS must be zero. EXIT_FAILURE >> must be between 1 and 125 inclusive. >> >> https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/stdlib.h.html >> > >What about the strict C std, posix aside for a moment? I would assume that is entirely up to the implementation. So long as the value defined in stdlib.h agrees with the value that the rest of the implementation (e.g. powershell/cmd.exe) expects.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-20 15:57 -0800 |
| Message-ID | <vhlt16$aq3g$1@dont-email.me> |
| In reply to | #120952 |
On 11/20/2024 3:03 PM, Scott Lurndal wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> On 11/20/2024 2:11 PM, Scott Lurndal wrote: >>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>>> On 11/19/2024 11:22 PM, Paavo Helde wrote: >>>>> On 20.11.2024 05:02, wij wrote: >>>>>> EXIT_SUCCESS/EXIT_FAILURE are for communication between different >>>>>> programs. >>>>>> But, is it necessary? E.g. can it be put into shell script? >>>>>> I think the macro EXIT_SUCCESS/EXIT_FAILURE may be good within a group of >>>>>> programs for some reason, but generally, exit code of program is a >>>>>> numerical >>>>>> value. Why EXIT_SUCCESS? >>>>>> >>>>>> >>>>> >>>>> EXIT_SUCCESS is an attempt to provide an abstraction which was attempted >>>>> to cover more different platforms than POSIX style exit codes. The idea >>>>> was that one can use EXIT_SUCCESS and EXIT_FAILURE regardless whether >>>>> the program is compiled to run on some Unix, on some weird mainframe >>>>> with weird exit code values, or in some free-standing implementation >>>>> where there is no OS, not to speak about shell scripts. >>>>> >>>>> Even on Linux or Windows, note that the exit code numeric values >>>>> contradict the conventions of C and C++ where 1 is normally converted to >>>>> true and 0 to false. So to reduce confusion it might be a good idea to >>>>> use the macros even here. Note that nowadays there are many programmers >>>>> (esp. on Windows) who have no idea about program exit code conventions >>>>> or shell scripts. >>>>> >>>>> >>>> >>>> EXIT_SUCCESS can be 0xbeefbeef and EXIT_FAILURE can be 0xdeadbeef? >>> >>> >>> Not on any POSIX system. EXIT_SUCCESS must be zero. EXIT_FAILURE >>> must be between 1 and 125 inclusive. >>> >>> https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/stdlib.h.html >>> >> >> What about the strict C std, posix aside for a moment? > > I would assume that is entirely up to the implementation. So > long as the value defined in stdlib.h agrees with the value that > the rest of the implementation (e.g. powershell/cmd.exe) > expects. Agreed!
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-11-20 15:58 -0800 |
| Message-ID | <vhlt2v$aq3g$2@dont-email.me> |
| In reply to | #120951 |
On 11/20/2024 2:33 PM, Chris M. Thomasson wrote: > On 11/20/2024 2:11 PM, Scott Lurndal wrote: >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>> On 11/19/2024 11:22 PM, Paavo Helde wrote: >>>> On 20.11.2024 05:02, wij wrote: >>>>> EXIT_SUCCESS/EXIT_FAILURE are for communication between different >>>>> programs. >>>>> But, is it necessary? E.g. can it be put into shell script? >>>>> I think the macro EXIT_SUCCESS/EXIT_FAILURE may be good within a >>>>> group of >>>>> programs for some reason, but generally, exit code of program is a >>>>> numerical >>>>> value. Why EXIT_SUCCESS? >>>>> >>>>> >>>> >>>> EXIT_SUCCESS is an attempt to provide an abstraction which was >>>> attempted >>>> to cover more different platforms than POSIX style exit codes. The idea >>>> was that one can use EXIT_SUCCESS and EXIT_FAILURE regardless whether >>>> the program is compiled to run on some Unix, on some weird mainframe >>>> with weird exit code values, or in some free-standing implementation >>>> where there is no OS, not to speak about shell scripts. >>>> >>>> Even on Linux or Windows, note that the exit code numeric values >>>> contradict the conventions of C and C++ where 1 is normally >>>> converted to >>>> true and 0 to false. So to reduce confusion it might be a good idea to >>>> use the macros even here. Note that nowadays there are many programmers >>>> (esp. on Windows) who have no idea about program exit code conventions >>>> or shell scripts. >>>> >>>> >>> >>> EXIT_SUCCESS can be 0xbeefbeef and EXIT_FAILURE can be 0xdeadbeef? >> >> >> Not on any POSIX system. EXIT_SUCCESS must be zero. EXIT_FAILURE >> must be between 1 and 125 inclusive. >> >> https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/stdlib.h.html >> > > What about the strict C std, posix aside for a moment? Actually, for some reason, this makes me think of nullptr = 0 = NULL wrt NULL can be 0xdeadbeefbeefdead?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-11-21 13:43 +0000 |
| Message-ID | <6OG%O.12794$vGnb.894@fx46.iad> |
| In reply to | #120954 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 11/20/2024 2:33 PM, Chris M. Thomasson wrote: >> On 11/20/2024 2:11 PM, Scott Lurndal wrote: > >Actually, for some reason, this makes me think of nullptr = 0 = NULL wrt >NULL can be 0xdeadbeefbeefdead? > I've worked with systems where the NULL pointer value was not zero. That's why C has a symbolic constant for NULL.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastartdlyHQ.org |
|---|---|
| Date | 2024-11-21 16:07 +0000 |
| Message-ID | <vhnlsi$n457$1@dont-email.me> |
| In reply to | #120959 |
On Thu, 21 Nov 2024 13:43:30 GMT scott@slp53.sl.home (Scott Lurndal) boring babbled: >"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>On 11/20/2024 2:33 PM, Chris M. Thomasson wrote: >>> On 11/20/2024 2:11 PM, Scott Lurndal wrote: > >> >>Actually, for some reason, this makes me think of nullptr = 0 = NULL wrt >>NULL can be 0xdeadbeefbeefdead? >> > >I've worked with systems where the NULL pointer value was not zero. > >That's why C has a symbolic constant for NULL. Thats a bit iffy given the number of devs - and I include myself - who often use !<whatever> in place of <whatever> == NULL and similarly <whatever> instead of <whatever> != NULL.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-11-21 17:55 +0000 |
| Message-ID | <FuK%O.36887$IFic.14310@fx12.iad> |
| In reply to | #120965 |
Muttley@DastartdlyHQ.org writes: >On Thu, 21 Nov 2024 13:43:30 GMT >scott@slp53.sl.home (Scott Lurndal) boring babbled: >>"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>>On 11/20/2024 2:33 PM, Chris M. Thomasson wrote: >>>> On 11/20/2024 2:11 PM, Scott Lurndal wrote: >> >>> >>>Actually, for some reason, this makes me think of nullptr = 0 = NULL wrt >>>NULL can be 0xdeadbeefbeefdead? >>> >> >>I've worked with systems where the NULL pointer value was not zero. >> >>That's why C has a symbolic constant for NULL. > >Thats a bit iffy given the number of devs - and I include myself - who often use >!<whatever> in place of <whatever> == NULL and similarly <whatever> instead >of <whatever> != NULL. No, it's not iffy, that's just bad coding practice on your part.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-11-22 09:30 +0100 |
| Message-ID | <vhpffm$13p8k$1@dont-email.me> |
| In reply to | #120969 |
On 21/11/2024 18:55, Scott Lurndal wrote: > Muttley@DastartdlyHQ.org writes: >> On Thu, 21 Nov 2024 13:43:30 GMT >> scott@slp53.sl.home (Scott Lurndal) boring babbled: >>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>>> On 11/20/2024 2:33 PM, Chris M. Thomasson wrote: >>>>> On 11/20/2024 2:11 PM, Scott Lurndal wrote: >>> >>>> >>>> Actually, for some reason, this makes me think of nullptr = 0 = NULL wrt >>>> NULL can be 0xdeadbeefbeefdead? >>>> >>> >>> I've worked with systems where the NULL pointer value was not zero. >>> >>> That's why C has a symbolic constant for NULL. >> >> Thats a bit iffy given the number of devs - and I include myself - who often use >> !<whatever> in place of <whatever> == NULL and similarly <whatever> instead >> of <whatever> != NULL. > > No, it's not iffy, that's just bad coding practice on your part. If you are talking about testing a normal pointer to check for a null pointer, it is not "iffy" at all in C++. If you have "int * p;", then "if (p)" is a conversion of "p" to bool, which is defined as false if and only if p is a null pointer. "if (!p)" first converts "p" to bool, and then negates it, so it is also entirely well defined. For C, "(!p)" is defined as "(0 == p)", which will be true if and only if "p" is a null pointer. (An integer constant expression with value 0, when converted to a pointer type, is a null pointer constant - regardless of representation.) All of this applies - AFAICS - regardless of whether the implementation uses a bit representation of 0 for a null pointer, or anything else. It still applies even if there can be many different representations of null pointers, as they must all compare equal. However, I can't see a justification for claiming that "if (p)" works as expected for any C implementation. I might be missing something, and of course real C implementations will support it as you would expect. In C++, "if (p)" converts "p" to bool, but in C, it converts it to "int". And while you are guaranteed that converting an integer constant expression of value 0 to a pointer type will give you a null pointer, you are not guaranteed that a null pointer, converted to an int, will give 0. (And int variables and other expressions of int type which happen to contain the value 0, are not guaranteed to give null pointers when converting to a pointer type - only /constant/ expressions get that treatment.) So for C, "if (p)" appears to be "iffy" in theory, but fine in practice. "if (!p)" is fine, as is "if (!!p)" and "if ((bool) p)". For C++, "if (p)" is solid. (If anyone can point to what I am missing that makes "if (p)" safe in C, I'd be glad to hear about it.) What counts as "bad coding practice" is a much more subjective matter.
[toc] | [prev] | [next] | [standalone]
| From | Ross Finlayson <ross.a.finlayson@gmail.com> |
|---|---|
| Date | 2024-11-22 11:10 -0800 |
| Message-ID | <mKydnSm_QrqgSt36nZ2dnZfqnPudnZ2d@giganews.com> |
| In reply to | #120971 |
On 11/22/2024 12:30 AM, David Brown wrote: > On 21/11/2024 18:55, Scott Lurndal wrote: >> Muttley@DastartdlyHQ.org writes: >>> On Thu, 21 Nov 2024 13:43:30 GMT >>> scott@slp53.sl.home (Scott Lurndal) boring babbled: >>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>>>> On 11/20/2024 2:33 PM, Chris M. Thomasson wrote: >>>>>> On 11/20/2024 2:11 PM, Scott Lurndal wrote: >>>> >>>>> >>>>> Actually, for some reason, this makes me think of nullptr = 0 = >>>>> NULL wrt >>>>> NULL can be 0xdeadbeefbeefdead? >>>>> >>>> >>>> I've worked with systems where the NULL pointer value was not zero. >>>> >>>> That's why C has a symbolic constant for NULL. >>> >>> Thats a bit iffy given the number of devs - and I include myself - >>> who often use >>> !<whatever> in place of <whatever> == NULL and similarly <whatever> >>> instead >>> of <whatever> != NULL. >> >> No, it's not iffy, that's just bad coding practice on your part. > > If you are talking about testing a normal pointer to check for a null > pointer, it is not "iffy" at all in C++. If you have "int * p;", then > "if (p)" is a conversion of "p" to bool, which is defined as false if > and only if p is a null pointer. "if (!p)" first converts "p" to bool, > and then negates it, so it is also entirely well defined. > > For C, "(!p)" is defined as "(0 == p)", which will be true if and only > if "p" is a null pointer. (An integer constant expression with value 0, > when converted to a pointer type, is a null pointer constant - > regardless of representation.) > > All of this applies - AFAICS - regardless of whether the implementation > uses a bit representation of 0 for a null pointer, or anything else. It > still applies even if there can be many different representations of > null pointers, as they must all compare equal. > > However, I can't see a justification for claiming that "if (p)" works as > expected for any C implementation. I might be missing something, and of > course real C implementations will support it as you would expect. In > C++, "if (p)" converts "p" to bool, but in C, it converts it to "int". > And while you are guaranteed that converting an integer constant > expression of value 0 to a pointer type will give you a null pointer, > you are not guaranteed that a null pointer, converted to an int, will > give 0. (And int variables and other expressions of int type which > happen to contain the value 0, are not guaranteed to give null pointers > when converting to a pointer type - only /constant/ expressions get that > treatment.) > > So for C, "if (p)" appears to be "iffy" in theory, but fine in practice. > "if (!p)" is fine, as is "if (!!p)" and "if ((bool) p)". For C++, "if > (p)" is solid. > > (If anyone can point to what I am missing that makes "if (p)" safe in C, > I'd be glad to hear about it.) > > > What counts as "bad coding practice" is a much more subjective matter. > > > (Reminds of "if (!!p)" Otherwise that NULL is usually declared (void*)0 so that it's sort of a usual thing makes for though that testing against null is for no other reference getting in and evaluating boolean.)
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-11-23 11:36 +0000 |
| Message-ID | <vhseod$1mih5$1@dont-email.me> |
| In reply to | #120980 |
On Fri, 22 Nov 2024 11:10:57 -0800 Ross Finlayson <ross.a.finlayson@gmail.com> gabbled: >(Reminds of "if (!!p)" Otherwise that NULL is usually declared (void*)0 Thats actually a very convenient way to convert any -N -> 0 -> N value into 0 or 1. I've used it myself a couple of times.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-11-22 12:26 -0800 |
| Message-ID | <875xofnhf8.fsf@nosuchdomain.example.com> |
| In reply to | #120971 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> However, I can't see a justification for claiming that "if (p)" works
> as expected for any C implementation. I might be missing something,
> and of course real C implementations will support it as you would
> expect. In C++, "if (p)" converts "p" to bool, but in C, it converts
> it to "int". And while you are guaranteed that converting an integer
> constant expression of value 0 to a pointer type will give you a null
> pointer, you are not guaranteed that a null pointer, converted to an
> int, will give 0. (And int variables and other expressions of int
> type which happen to contain the value 0, are not guaranteed to give
> null pointers when converting to a pointer type - only /constant/
> expressions get that treatment.)
Yes, you're missing something.
some_type *p;
if (p) do_something();
N1570 6.8.4: `do_something();` is executed if p "compares unequal to 0",
so `if (p)` is equivalent to `if (p != 0)`.
N1570 6.5.10: "If one operand is a pointer and the other is a null
pointer constant, the null pointer constant is converted to the type of
the pointer." 0 is a null pointer constant, so it's converted to type
`some_type*`, yielding a null pointer value of that type.
In `if (p)`, p is not converted to int. It's compared for inequality to
0, and the result of that comparison is of type int.
> So for C, "if (p)" appears to be "iffy" in theory, but fine in
> practice. "if (!p)" is fine, as is "if (!!p)" and "if ((bool) p)".
> For C++, "if (p)" is solid.
>
> (If anyone can point to what I am missing that makes "if (p)" safe in
> C, I'd be glad to hear about it.)
>
> What counts as "bad coding practice" is a much more subjective matter.
Indeed. I would write `if (foo)` only if foo is of type bool/_Bool (or
is "logically Boolean", such as a C int value with no meaninful
distinction among non-zero values). I would write:
- `if (foo != NULL)` or `if (foo != nullptr)` for a pointer;
- `if (foo != '\0')` for a character (or '\0L');
- `if (foo != 0)` for an integer that doesn't denote a character or
boolean value (or possibly `0L` et al);
- `if (foo != 0.0)` for a floating-point value (or possibly
0.0f or 0.0L).
But that's my own preference, and I don't have any problem reading code
written by people with different preferences. I recognize that more
agressive use of `if (foo)` is a common idiom, one I'll follow myself if
I'm subjected to a coding standard that requires it.
(C tends to use int for character and Boolean values. C++ tends not to
do that as much, though you can still write C-style code in C++, and C++
includes (most of) the C standard library.)
I didn't cross-post this to comp.lang.c, but we might consider doing so
if the discussion continues into C-specific content.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web