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?
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.
On Wed, 20 Nov 2024 09:22:07 +0200
Paavo Helde <[email protected]> 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.
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 numerica= >l
value. Why EXIT_SUCCESS?
[email protected] 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.
On Wed, 20 Nov 2024 13:47:53 GMT
[email protected] (Scott Lurndal) boring babbled:
[email protected] 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.
On Wed, 2024-11-20 at 13:44 +0000, Scott Lurndal wrote:
wij <[email protected]> writes:
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 numerica= l
value. Why EXIT_SUCCESS?
The unix shell interprets the exit code. A script can determine
whether a command succeeded or failed and take the appropriate
action based on the exit code. A zero return indicates the
command was successful, a non-zero return indicates failure.
That is my point. Scripts see number not C/C++ symbol EXIT_SUCCESS.
Programs can be written in various languages. How to make these
programs read the C/C++ macro "EXIT_SUCCESS"? And, as it is 'POSIX',
that means All kind of OS should recognize "EXIT_SUCCESS" to be
portable. I doubt this. IMO, 0 is more portable than EXIT_SUCCESS.
But, there should be some details I don't know. Besides, defining EXIT_SUCCESS has a draw back that programs will have problem to use a
range of numbers as exit code. Not allowed? As said I don't know the rationale.
[email protected] writes:
On Wed, 20 Nov 2024 13:47:53 GMT
[email protected] (Scott Lurndal) boring babbled: >>>[email protected] 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
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?
On 11/20/2024 2:11 PM, Scott Lurndal wrote:
"Chris M. Thomasson" <[email protected]> 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?
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?
On 11/20/2024 2:11 PM, Scott Lurndal wrote:...
"Chris M. Thomasson" <[email protected]> writes:
On 11/19/2024 11:22 PM, Paavo Helde wrote:
On 20.11.2024 05:02, wij wrote:
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?
Thanks that's interesting as sometimes one sees 255.
On 11/20/2024 02:11 PM, Scott Lurndal wrote:
"Chris M. Thomasson" <[email protected]> writes:
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
Thanks that's interesting as sometimes one sees 255.
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?
Because which numeric values qualify as successful and failure codes
varies from one operating system to another. My own experience includes
VMS, where even exit codes indicate errors, whereas odd value indicate >success.
On 11/20/2024 5:32 PM, Ross Finlayson wrote:
Thanks that's interesting as sometimes one sees 255.I believe that in POSIX, exit codes between 128 to 128 + NSIG inclusive >indicate the termination was caused by a signal.
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?
"Chris M. Thomasson" <[email protected]> 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.
On Thu, 21 Nov 2024 13:43:30 GMT
[email protected] (Scott Lurndal) boring babbled:
"Chris M. Thomasson" <[email protected]> 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.
[email protected] writes:
On Thu, 21 Nov 2024 13:43:30 GMT
[email protected] (Scott Lurndal) boring babbled:
"Chris M. Thomasson" <[email protected]> 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.
[email protected] writes:
On Thu, 21 Nov 2024 13:43:30 GMT
[email protected] (Scott Lurndal) boring babbled:
"Chris M. Thomasson" <[email protected]> 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.
On Thu, 21 Nov 2024 13:43:30 GMT...
[email protected] (Scott Lurndal) boring babbled:
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.
"Chris M. Thomasson" <[email protected]> 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.
James Kuyper <[email protected]> writes:...
`(void*)0` is a null pointer constant in C but not in C++, because C++
has no implicit conversion from void* to other pointer types.
0 is a null pointer constant, and a valid expansion for NULL, in both C
and C++.
Note that `(void*)0` is a C null pointer constant, but not a valid
expansion for NULL. It needs to be `((void*)0)`. (A painfully literal reading of the C standard up to and including C17 suggests that a parenthesized null pointer constant is not a null pointer constant, but
C23 corrects that oversight.)
In my opinion, the main reason for NULL is that it lets the programmer explicitly state that it's a null pointer constant and not just zero.
(But NULL can still be of type int.) I find nullptr (in C++ and C23) an improvement over NULL.
David Brown <[email protected]> writes:
[...]
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.
(Reminds of "if (!!p)" Otherwise that NULL is usually declared (void*)0
David Brown <[email protected]> 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.
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?
On Wed, 20 Nov 2024 11:02:49 +0800, wij <[email protected]> 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?
because the success is one only case
and failure can happen for 10000000 of causes differents
the success has to be one number
and failure all the remain numbers
as example 0 success -inf .. +inf -{0} failure
[email protected] writes:
On Thu, 21 Nov 2024 13:43:30 GMT
[email protected] (Scott Lurndal) boring babbled:
"Chris M. Thomasson" <[email protected]> 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.
[...] The main reason for NULL is that some implementations
thought it would be better for type safety to use (void*)0.
On Tue, 2024-11-26 at 12:21 +0800, wij wrote:
looks bad, but it works fine. Any way, inventing nullptr for such rare? c= >ase
is IOM overkill.
I think now, inventing nullptr is a practical step of evolution. So, in the >future, expansion of NULL might be nullptr. ... NULL will still be valid fo= >r=C2=A0
a long time, both in C and C++.
A clue for you: What should be in a 'portabe' program if ::fopen(..) failed? NULL
or nullptr? What about "if(::fopen(..)"?
On Wed, 27 Nov 2024 16:23:55 +0800
wij <[email protected]> boring babbled:
On Tue, 2024-11-26 at 12:21 +0800, wij wrote:
looks bad, but it works fine. Any way, inventing nullptr for suchase
rare? c=
is IOM overkill.
I think now, inventing nullptr is a practical step of evolution. So,
in the future, expansion of NULL might be nullptr. ... NULL will
still be valid fo= r=C2=A0
a long time, both in C and C++.
Stop replying to your own nonsense with yet more nonsense. No one
cares.
On Wed, 2024-11-27 at 08:26 +0000, [email protected] wrote:
On Wed, 27 Nov 2024 16:23:55 +0800the
wij <[email protected]> boring babbled:
On Tue, 2024-11-26 at 12:21 +0800, wij wrote:
looks bad, but it works fine. Any way, inventing nullptr for such rar= >e? c=3Dase
is IOM overkill.=20
I think now, inventing nullptr is a practical step of evolution. So, in=
future, expansion of NULL might be nullptr. ... NULL will still be vali= >d fo=3D=20
r=3DC2=3DA0
a long time, both in C and C++.
Stop replying to your own nonsense with yet more nonsense. No one cares.
It was a correction of my previous post. Not every post is for you.
If you feel sth have to utter, utter sth on topic. We know you are not ther= >e, but
we won't laught.
A clue for you: What should be in a 'portabe' program if ::fopen(..) failed= >? NULL=C2=A0
or nullptr? What about "if(::fopen(..)"?
On 27.11.2024 12:48, wij wrote:
A clue for you: What should be in a 'portabe' program if ::fopen(..) failed? >NULL
or nullptr? What about "if(::fopen(..)"?
In a portable program one cannot just use fopen() as it does not work >reliably with Unicode characters in Windows paths. One needs to use some
kind of helper library for having portable code. In principle >std::filesystem::path ought to work, but I have no experience with it.
On Wed, 27 Nov 2024 15:39:51 +0200
Paavo Helde <[email protected]> wibbled:
On 27.11.2024 12:48, wij wrote:
NULL
A clue for you: What should be in a 'portabe' program if
::fopen(..) failed?
or nullptr? What about "if(::fopen(..)"?
In a portable program one cannot just use fopen() as it does not
work reliably with Unicode characters in Windows paths. One needs to
use some kind of helper library for having portable code. In
principle std::filesystem::path ought to work, but I have no
experience with it.
So how does file access work in plain C in Windows then? I'm pretty
sure fopen() works fine given its a core C API function.
On Wed, 27 Nov 2024 13:54:04 -0000 (UTC)
[email protected] wrote:
On Wed, 27 Nov 2024 15:39:51 +0200
Paavo Helde <[email protected]> wibbled:
On 27.11.2024 12:48, wij wrote:
NULL
A clue for you: What should be in a 'portabe' program if
::fopen(..) failed?
or nullptr? What about "if(::fopen(..)"?
In a portable program one cannot just use fopen() as it does not
work reliably with Unicode characters in Windows paths. One needs to
use some kind of helper library for having portable code. In
principle std::filesystem::path ought to work, but I have no
experience with it.
So how does file access work in plain C in Windows then? I'm pretty
sure fopen() works fine given its a core C API function.
It works, but badly rather than fine.
Specifically, it works only with ASCII paths. Which, on Windows, happen
to be 2nd class. The biggest problem with ASCII paths on Windows is
On Wed, 27 Nov 2024 15:39:51 +0200
Paavo Helde <[email protected]> wibbled:
On 27.11.2024 12:48, wij wrote:
NULL
A clue for you: What should be in a 'portabe' program if ::fopen(..) failed?
or nullptr? What about "if(::fopen(..)"?
In a portable program one cannot just use fopen() as it does not work
reliably with Unicode characters in Windows paths. One needs to use some
kind of helper library for having portable code. In principle
std::filesystem::path ought to work, but I have no experience with it.
So how does file access work in plain C in Windows then? I'm pretty sure fopen() works fine given its a core C API function.
On Wed, 27 Nov 2024 17:24:05 +0200
Michael S <[email protected]> wibbled:
On Wed, 27 Nov 2024 13:54:04 -0000 (UTC)
[email protected] wrote:
On Wed, 27 Nov 2024 15:39:51 +0200
Paavo Helde <[email protected]> wibbled:
On 27.11.2024 12:48, wij wrote:
NULL
A clue for you: What should be in a 'portabe' program if
::fopen(..) failed?
or nullptr? What about "if(::fopen(..)"?
In a portable program one cannot just use fopen() as it does not
work reliably with Unicode characters in Windows paths. One needs to
use some kind of helper library for having portable code. In
principle std::filesystem::path ought to work, but I have no
experience with it.
So how does file access work in plain C in Windows then? I'm pretty
sure fopen() works fine given its a core C API function.
It works, but badly rather than fine.
Specifically, it works only with ASCII paths. Which, on Windows, happen
to be 2nd class. The biggest problem with ASCII paths on Windows is
How can ascii paths be 2nd class (whatever that means) given that ascii
is a subset of utf-8?
About null pointers: in C++ it is spelled `nullptr`.
On Wed, 27 Nov 2024 18:48:13 +0800...
wij <[email protected]> wibbled:
If you feel sth have to utter, utter sth on topic. We know you are not ther= >> e, but
we won't laught.
You could translate that into comprehensible english?
On Wed, 27 Nov 2024 17:24:05 +0200...
Michael S <[email protected]> wibbled:
It works, but badly rather than fine.
Specifically, it works only with ASCII paths. Which, on Windows, happen
to be 2nd class. The biggest problem with ASCII paths on Windows is
How can ascii paths be 2nd class (whatever that means) given that ascii
is a subset of utf-8?
On 27.11.2024 15:54, [email protected] wrote:
On Wed, 27 Nov 2024 15:39:51 +0200
Paavo Helde <[email protected]> wibbled:
On 27.11.2024 12:48, wij wrote:
NULL
A clue for you: What should be in a 'portabe' program if ::fopen(..) >failed?
or nullptr? What about "if(::fopen(..)"?
In a portable program one cannot just use fopen() as it does not work
reliably with Unicode characters in Windows paths. One needs to use some >>> kind of helper library for having portable code. In principle
std::filesystem::path ought to work, but I have no experience with it.
So how does file access work in plain C in Windows then? I'm pretty sure
fopen() works fine given its a core C API function.
In C one can use _wfopen() or _wfopen_s() in Windows. As you can guess
these are pretty non-portable.
The libraries which provide their own file opening functions typically >provide the wide char variants as well, specifially for supporting
Windows. For example, libTIFF provides TIFFOpenW() and zlib provides >gzopen_w().
In a better world MS should implement full support for the UTF-8 locale
and deprecate all other locales, making all this wide char stuff
unneeded. Not sure how far they are on this (IMO unevitable) path. In an >ideal world they would have done that already 15 years ago.
On 11/27/24 11:12 AM, [email protected] wrote:
How can ascii paths be 2nd class (whatever that means) given that ascii
is a subset of utf-8?
Because the windows file system is based on UTF-16 file names?
On 11/27/24 11:12, [email protected] wrote:
On Wed, 27 Nov 2024 17:24:05 +0200....
Michael S <[email protected]> wibbled:
It works, but badly rather than fine.
Specifically, it works only with ASCII paths. Which, on Windows, happen
to be 2nd class. The biggest problem with ASCII paths on Windows is
How can ascii paths be 2nd class (whatever that means) given that ascii
is a subset of utf-8?
Because ascii is a subset of utf-8, any path name that contains a
character not in that subset cannot be represented, which is what makes
them 2nd class.
On Wed, 27 Nov 2024 14:58:18 -0500
James Kuyper <[email protected]> wibbled:
On 11/27/24 11:12, [email protected] wrote:
On Wed, 27 Nov 2024 17:24:05 +0200....
Michael S <[email protected]> wibbled:
It works, but badly rather than fine.
Specifically, it works only with ASCII paths. Which, on Windows, happen >>>> to be 2nd class. The biggest problem with ASCII paths on Windows is
How can ascii paths be 2nd class (whatever that means) given that ascii
is a subset of utf-8?
Because ascii is a subset of utf-8, any path name that contains a
character not in that subset cannot be represented, which is what makes
them 2nd class.
Huh? Any ascii text is valid in UTF-8, that doesn't make ascii 2nd class.
The only issue comes when some idiot tries to mix utf-8 with 8 bit ascii
code pages.
* Paavo Helde <[email protected]>
| On 28.11.2024 10:26, [email protected] wrote:
| > On Wed, 27 Nov 2024 14:58:18 -0500
| > James Kuyper <[email protected]> wibbled:
| >> On 11/27/24 11:12, [email protected] wrote:
| >>> On Wed, 27 Nov 2024 17:24:05 +0200
| >>> Michael S <[email protected]> wibbled:
| >> ....
| >>>> It works, but badly rather than fine.
| >>>> Specifically, it works only with ASCII paths. Which, on Windows, happen
| >>>> to be 2nd class. The biggest problem with ASCII paths on Windows is --<snip-snip>--
| Though this is changing now, I just ran a quick test and apparently
| calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with
| VS2022 on Windows 10 and I can pass UTF-8 filenames to narrow-string
| fopen() and they work properly. So there is progress!
Does fopen() also work with filenames where the UTF-8 is not part of
your et_EE.UTF-8 codepage (e.g. filenames containing japanese
characters)? I think that with these only the _wfopen() will work...
On Wed, 27 Nov 2024 13:00:17 -0500
Richard Damon <[email protected]> wrote:
On 11/27/24 11:12 AM, [email protected] wrote:
On Wed, 27 Nov 2024 17:24:05 +0200
Michael S <[email protected]> wibbled:
On Wed, 27 Nov 2024 13:54:04 -0000 (UTC)
[email protected] wrote:
On Wed, 27 Nov 2024 15:39:51 +0200
Paavo Helde <[email protected]> wibbled:
On 27.11.2024 12:48, wij wrote:
NULL
A clue for you: What should be in a 'portabe' program if
::fopen(..) failed?
or nullptr? What about "if(::fopen(..)"?
In a portable program one cannot just use fopen() as it does not
work reliably with Unicode characters in Windows paths. One
needs to use some kind of helper library for having portable
code. In principle std::filesystem::path ought to work, but I
have no experience with it.
So how does file access work in plain C in Windows then? I'm
pretty sure fopen() works fine given its a core C API function.
It works, but badly rather than fine.
Specifically, it works only with ASCII paths. Which, on Windows,
happen to be 2nd class. The biggest problem with ASCII paths on
Windows is
How can ascii paths be 2nd class (whatever that means) given that
ascii is a subset of utf-8?
Because the windows file system is based on UTF-16 file names?
The UTF-8 interface is just more limited.
Actually, I can not think about good reason for 260-char limit of
maximal path length in ASCII variant of Windows files APIs.
It's probably somehow related to compatibility with Wn16, but I don't
see how exactly.
I am also not sure that [for names started with "\\?\" prefix] the
limit still present in the newer editions of the OS. Up to date docs
are less clear about it than the older docs that I seems to recollect.
Most of the docs are written as if longer paths should work in ASCII.
But in one place there is the following line "Note that Unicode APIs
should be used to make sure the "\\?\" prefix allows you to exceed the MAX_PATH." https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
This line seems to contradict the following page: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea
Unfortunately, right now I have no time for deeper investigation.
On 28.11.2024 10:26, [email protected] wrote:
On Wed, 27 Nov 2024 14:58:18 -0500
James Kuyper <[email protected]> wibbled:
On 11/27/24 11:12, [email protected] wrote:
On Wed, 27 Nov 2024 17:24:05 +0200....
Michael S <[email protected]> wibbled:
It works, but badly rather than fine.
Specifically, it works only with ASCII paths. Which, on Windows,
happen
to be 2nd class. The biggest problem with ASCII paths on Windows is
How can ascii paths be 2nd class (whatever that means) given that ascii >>>> is a subset of utf-8?
Because ascii is a subset of utf-8, any path name that contains a
character not in that subset cannot be represented, which is what makes
them 2nd class.
Huh? Any ascii text is valid in UTF-8, that doesn't make ascii 2nd class.
The only issue comes when some idiot tries to mix utf-8 with 8 bit ascii
code pages.
You are right, ASCII is not 2nd class because it is part of UTF-8. It is
2nd class on Windows because MS have historically decided to not support UTF-8 properly on Windows, in an attempt of a futile vendor lock-in.
Though this is changing now, I just ran a quick test and apparently
calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with VS2022
on Windows 10 and I can pass UTF-8 filenames to narrow-string fopen()
and they work properly. So there is progress!
On 11/27/24 11:12 AM, [email protected] wrote:
On Wed, 27 Nov 2024 17:24:05 +0200
Michael S <[email protected]> wibbled:
On Wed, 27 Nov 2024 13:54:04 -0000 (UTC)
[email protected] wrote:
On Wed, 27 Nov 2024 15:39:51 +0200
Paavo Helde <[email protected]> wibbled:
On 27.11.2024 12:48, wij wrote:
NULL
A clue for you: What should be in a 'portabe' program if
::fopen(..) failed?
or nullptr? What about "if(::fopen(..)"?
In a portable program one cannot just use fopen() as it does not
work reliably with Unicode characters in Windows paths. One
needs to use some kind of helper library for having portable
code. In principle std::filesystem::path ought to work, but I
have no experience with it.
So how does file access work in plain C in Windows then? I'm
pretty sure fopen() works fine given its a core C API function.
It works, but badly rather than fine.
Specifically, it works only with ASCII paths. Which, on Windows,
happen to be 2nd class. The biggest problem with ASCII paths on
Windows is
How can ascii paths be 2nd class (whatever that means) given that
ascii is a subset of utf-8?
Because the windows file system is based on UTF-16 file names?
The UTF-8 interface is just more limited.
On 11/27/24 08:52, [email protected] wrote:
On Wed, 27 Nov 2024 18:48:13 +0800...
wij <[email protected]> wibbled:
If you feel sth have to utter, utter sth on topic. We know you are
not ther= e, but
we won't laught.
You could translate that into comprehensible english?
Of course he can't - he's wij. Comprehensibility is not an available
option for him.
On 28.11.2024 10:26, [email protected] wrote:
On Wed, 27 Nov 2024 14:58:18 -0500
James Kuyper <[email protected]> wibbled:
On 11/27/24 11:12, [email protected] wrote:
On Wed, 27 Nov 2024 17:24:05 +0200....
Michael S <[email protected]> wibbled:
It works, but badly rather than fine.
Specifically, it works only with ASCII paths. Which, on Windows,
happen to be 2nd class. The biggest problem with ASCII paths on
Windows is
How can ascii paths be 2nd class (whatever that means) given that
ascii is a subset of utf-8?
Because ascii is a subset of utf-8, any path name that contains a
character not in that subset cannot be represented, which is what
makes them 2nd class.
Huh? Any ascii text is valid in UTF-8, that doesn't make ascii 2nd
class. The only issue comes when some idiot tries to mix utf-8 with
8 bit ascii code pages.
You are right, ASCII is not 2nd class because it is part of UTF-8. It
is 2nd class on Windows because MS have historically decided to not
support UTF-8 properly on Windows, in an attempt of a futile vendor
lock-in.
Though this is changing now, I just ran a quick test and apparently
calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with
VS2022 on Windows 10 and I can pass UTF-8 filenames to narrow-string
fopen() and they work properly. So there is progress!
Not sure that it was about lock in. At time Win32 was conceived, UTF8
didn't exist. At time WinNt was shipped, it still was less than a
year old. Back then choosing UTF16 looked reasonable.
Up to ~15 years ago it was not clear that UTF8 not just won, but won >decisively, so siting on the fence, waiting for the outcome of the
battle and rooting for legacy was not totally unreasonable. For what
happened after that, you could not underestimated a factor of laziness.
Though this is changing now, I just ran a quick test and apparently
calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with
VS2022 on Windows 10 and I can pass UTF-8 filenames to narrow-string
fopen() and they work properly. So there is progress!
Can you try it with paths that are longer than 260 characters? Both
prefixed with "\\?\" and non-prefixed?
Of course if MS had simply treated filenames as a sequence of 8 bit
bytes regardless of what they did or didn't encode - as per *nix -
then all this nonsense could have been avoided. It would simply have
been left to the "dir" command or Explorer to decode it appropriately.
On 28/11/2024 16:12, [email protected] wrote:
handling systems. All this was perfectly reasonable for a small
single-user single-tasking OS on limited hardware, and more efficient on
the PC than the Unix system would have been.
On Thu, 28 Nov 2024 15:19:43 +0200
Michael S <[email protected]> wibbled:
Not sure that it was about lock in. At time Win32 was conceived, UTF8
didn't exist. At time WinNt was shipped, it still was less than a
year old. Back then choosing UTF16 looked reasonable.
Up to ~15 years ago it was not clear that UTF8 not just won, but won
decisively, so siting on the fence, waiting for the outcome of the
battle and rooting for legacy was not totally unreasonable. For what
happened after that, you could not underestimated a factor of laziness.
Though this is changing now, I just ran a quick test and apparently
calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with
VS2022 on Windows 10 and I can pass UTF-8 filenames to narrow-string
fopen() and they work properly. So there is progress!
Can you try it with paths that are longer than 260 characters? Both
prefixed with "\\?\" and non-prefixed?
Of course if MS had simply treated filenames as a sequence of 8 bit bytes regardless of what they did or didn't encode - as per *nix - then all this nonsense could have been avoided. It would simply have been left to the
"dir" command or Explorer to decode it appropriately.
On Wed, 27 Nov 2024 14:58:18 -0500...
James Kuyper <[email protected]> wibbled:
On 11/27/24 11:12, [email protected] wrote:
How can ascii paths be 2nd class (whatever that means) given that ascii
is a subset of utf-8?
Because ascii is a subset of utf-8, any path name that contains a
character not in that subset cannot be represented, which is what makes
them 2nd class.
Huh? Any ascii text is valid in UTF-8, that doesn't make ascii 2nd class
On 28.11.2024 15:19, Michael S wrote:�üää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüä
On Thu, 28 Nov 2024 13:03:20 +0200
Paavo Helde <[email protected]> wrote:
On 28.11.2024 10:26, [email protected] wrote:
On Wed, 27 Nov 2024 14:58:18 -0500
James Kuyper <[email protected]> wibbled:
On 11/27/24 11:12, [email protected] wrote:
On Wed, 27 Nov 2024 17:24:05 +0200....
Michael S <[email protected]> wibbled:
It works, but badly rather than fine.
Specifically, it works only with ASCII paths. Which, on
Windows, happen to be 2nd class. The biggest problem with
ASCII paths on Windows is
How can ascii paths be 2nd class (whatever that means) given
that ascii is a subset of utf-8?
Because ascii is a subset of utf-8, any path name that contains a
character not in that subset cannot be represented, which is what
makes them 2nd class.
Huh? Any ascii text is valid in UTF-8, that doesn't make ascii 2nd
class. The only issue comes when some idiot tries to mix utf-8
with 8 bit ascii code pages.
You are right, ASCII is not 2nd class because it is part of UTF-8.
It is 2nd class on Windows because MS have historically decided to
not support UTF-8 properly on Windows, in an attempt of a futile
vendor lock-in.
Not sure that it was about lock in. At time Win32 was conceived,
UTF8 didn't exist. At time WinNt was shipped, it still was less
than a year old. Back then choosing UTF16 looked reasonable.
Up to ~15 years ago it was not clear that UTF8 not just won, but won decisively, so siting on the fence, waiting for the outcome of the
battle and rooting for legacy was not totally unreasonable. For what happened after that, you could not underestimated a factor of
laziness.
Though this is changing now, I just ran a quick test and apparently
calling setlocale(LC_ALL, "et_EE.UTF-8") now works properly with
VS2022 on Windows 10 and I can pass UTF-8 filenames to
narrow-string fopen() and they work properly. So there is progress!
Can you try it with paths that are longer than 260 characters? Both prefixed with "\\?\" and non-prefixed?
Non-prefixed, _mkdir() succeeds with a path of 247 unicode characters
(406 bytes) and fails with 307 unicode chars (506 bytes).
Prefixed with "\\?\" _mkdir() and fopen() appeared to work fine,
tried up to 1275 unicode chars (2114 bytes), the largest path was:
\\?\C:\Tmp\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-est�
Alas, the File Explorer left-hand tree failed to descend into so deep directory tree (double-click in right-hand pane worked, but left-hand
tree was truncated at some point). When opened in Notepad or
Notepad++, the too long paths were changed into tilde-style "short
names", stripping the unicode chars:
C:\tmp\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1.TXT
On 29.11.2024 00:21, Michael S wrote:estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estü
On Thu, 28 Nov 2024 22:41:42 +0200
Paavo Helde <[email protected]> wrote:
On 28.11.2024 15:19, Michael S wrote:
On Thu, 28 Nov 2024 13:03:20 +0200
Paavo Helde <[email protected]> wrote:
On 28.11.2024 10:26, [email protected] wrote:
On Wed, 27 Nov 2024 14:58:18 -0500
James Kuyper <[email protected]> wibbled:
On 11/27/24 11:12, [email protected] wrote:
On Wed, 27 Nov 2024 17:24:05 +0200....
Michael S <[email protected]> wibbled:
It works, but badly rather than fine.
Specifically, it works only with ASCII paths. Which, on
Windows, happen to be 2nd class. The biggest problem with
ASCII paths on Windows is
How can ascii paths be 2nd class (whatever that means) given
that ascii is a subset of utf-8?
Because ascii is a subset of utf-8, any path name that
contains a character not in that subset cannot be represented,
which is what makes them 2nd class.
Huh? Any ascii text is valid in UTF-8, that doesn't make ascii
2nd class. The only issue comes when some idiot tries to mix
utf-8 with 8 bit ascii code pages.
You are right, ASCII is not 2nd class because it is part of
UTF-8. It is 2nd class on Windows because MS have historically
decided to not support UTF-8 properly on Windows, in an attempt
of a futile vendor lock-in.
Not sure that it was about lock in. At time Win32 was conceived,
UTF8 didn't exist. At time WinNt was shipped, it still was less
than a year old. Back then choosing UTF16 looked reasonable.
Up to ~15 years ago it was not clear that UTF8 not just won, but
won decisively, so siting on the fence, waiting for the outcome
of the battle and rooting for legacy was not totally
unreasonable. For what happened after that, you could not
underestimated a factor of laziness.
Though this is changing now, I just ran a quick test and
apparently calling setlocale(LC_ALL, "et_EE.UTF-8") now works
properly with VS2022 on Windows 10 and I can pass UTF-8
filenames to narrow-string fopen() and they work properly. So
there is progress!
Can you try it with paths that are longer than 260 characters?
Both prefixed with "\\?\" and non-prefixed?
Non-prefixed, _mkdir() succeeds with a path of 247 unicode
characters (406 bytes) and fails with 307 unicode chars (506
bytes).
Prefixed with "\\?\" _mkdir() and fopen() appeared to work fine,
tried up to 1275 unicode chars (2114 bytes), the largest path was:
\\?\C:\Tmp\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää\jap漢漢漢-estüüää-jap漢漢漢-
Alas, the File Explorer left-hand tree failed to descend into so
deep directory tree (double-click in right-hand pane worked, but
left-hand tree was truncated at some point). When opened in
Notepad or Notepad++, the too long paths were changed into
tilde-style "short names", stripping the unicode chars:
C:\tmp\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1\JAP-ES~1.TXT
Prefixed Unicode is expected to work fine. Documentation is clear
about it. I was wondering about behavior of prefixed ASCII. I.e.
fopen() with default locale.
With default locale it did not work on my machine (i.e. produced
gibberish filenames instead of expected Unicode characters), e.g. jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää-jap漢漢漢-estüüää
However, after
setlocale(LC_ALL, ".UTF-8");
the narrow character _mkdir() and fopen() started to work fine.
If you can set your Windows ACP to UTF-8, then the default locale
ought to work as well I guess. I think last time I tried this the
machine did not boot up any more. But this was many years ago.
Op 25.nov.2024 om 22:20 schreef Rosario19:
On Wed, 20 Nov 2024 11:02:49 +0800, wij <[email protected]> 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?
because the success is one only case
and failure can happen for 10000000 of causes differents
the success has to be one number
and failure all the remain numbers
as example 0 success -inf .. +inf -{0} failure
In some situations there can be different success cases, as well.
E.g. when searching for something, both finding something and finding
nothing is a valuable result and not a failure of the search operation.
It is worthwhile to indicate them with different success codes.
That can be done in VMS where odd codes are all success codes.
One could also think of a success code that includes the number of
results. (That is what many I/O functions do: A positive value indicates
a success with the number of bytes transferred, a negative number
indicates a failure.)
Failures are a different thing; they make the result of the operation >invalid. They should be indicated with an error code.
Keith Thompson <[email protected]> writes:
[...]
In my opinion, the main reason for NULL is that it lets the
programmer explicitly state that it's a null pointer constant and
not just zero. (But NULL can still be of type int.) I find
nullptr (in C++ and C23) an improvement over NULL.
To summarize, the purpose of using NULL rather than 0 is to
communicate information to the human reader, [...]
David Brown <[email protected]> writes:
[...]
I don't know if there are any real-world implementations (of C or
C++) with more than one representation for null pointers, but
null pointers are somewhat special. "if (x == y)" compares for
equality of two values, unless one of these is a pointer and the
other is a null pointer constant - then the comparison is more of
a classification, checking if the pointer is in the set of null
pointer values.
[...]
I'd say that a null pointer of a given type is a single *value*
that may or may not have multiple *representations*. [...]
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?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 13:33:17 |
| Calls: | 12,101 |
| Calls today: | 1 |
| Files: | 15,004 |
| Messages: | 6,518,008 |