Non-constant initializers

[Angel]

I'm sure beyond reasonable doubt that Eric knows that.

He raises an excellent point: we can't judge whether a program is
bug-free without knowing what requirements it's intended to satisfy.

So how about this implementation of IEFBR14 (intended only for
conforming hosted C implementations):

int main(void) { return 0; }

Mm, in that case I present my implementations of /bin/true and
/bin/false that do not depend on "magic" numbers.

#include <stdlib.h>

int main(void) { return EXIT_SUCCESS; }


#include <stdlib.h>

int main(void) { return EXIT_FAILURE; }

 

[Keith Thompson]

Mm, in that case I present my implementations of /bin/true and
/bin/false that do not depend on "magic" numbers.

#include <stdlib.h>

int main(void) { return EXIT_SUCCESS; }


#include <stdlib.h>

int main(void) { return EXIT_FAILURE; }

Your /bin/true implementation is ok, but the standard specifically says
that returning 0 from main returns "an implementation-defined form of
the status *successful termination*" to the environment (C99 7.20.4.3p5)
-- though it's not necessarily the *same* form of that status as
EXIT_SUCCESS.

Assuming a POSIX environment, your /bin/false implementation looks ok,
but I can imagine circumstances where it wouldn't be acceptable (e.g.,
if EXIT_SUCCESS != 1 and you have some externally imposed requirement
for /bin/false to return 1 specfiically).

Context is important.

 

[Ben Pfaff]

Your /bin/true implementation is ok, but the standard specifically says
that returning 0 from main returns "an implementation-defined form of
the status *successful termination*" to the environment (C99 7.20.4.3p5)
-- though it's not necessarily the *same* form of that status as
EXIT_SUCCESS.

POSIX requires EXIT_SUCCESS to be zero, so it's OK in a POSIX
environment (which is a somewhat reasonable assumption for
implementing a program specified by POSIX).

 

[Keith Thompson]

POSIX requires EXIT_SUCCESS to be zero, so it's OK in a POSIX
environment (which is a somewhat reasonable assumption for
implementing a program specified by POSIX).

Right (though /bin/true predates POSIX, so there *could* be some other
requirement).

My point wasn't that Angel's implementation wasn't ok; it was that my
own implementation:

int main(void) { return 0; }

is equally ok. (And I offered it as an implementation of IEFBR14, not
of /bin/true.)

 

[Kenny McCormack]

Your /bin/true implementation is ok, but the standard specifically says
that returning 0 from main returns "an implementation-defined form of
the status *successful termination*" to the environment (C99 7.20.4.3p5)
-- though it's not necessarily the *same* form of that status as
EXIT_SUCCESS.

Assuming a POSIX environment, your /bin/false implementation looks ok,
but I can imagine circumstances where it wouldn't be acceptable (e.g.,
if EXIT_SUCCESS != 1 and you have some externally imposed requirement
for /bin/false to return 1 specfiically).

Context is important.

Remind me again: Just exactly how many angels fit on the head of a pin?

--
Windows 95 n. (Win-doze): A 32 bit extension to a 16 bit user interface for
an 8 bit operating system based on a 4 bit architecture from a 2 bit company
that can't stand 1 bit of competition.

Modern day upgrade --> Windows XP Professional x64: Windows is now a 64 bit
tweak of a 32 bit extension to a 16 bit user interface for an 8 bit
operating system based on a 4 bit architecture from a 2 bit company that
can't stand 1 bit of competition.

 

[Kenny McCormack]

Right (though /bin/true predates POSIX, so there *could* be some other
requirement).

My point wasn't that Angel's implementation wasn't ok; it was that my
own implementation:

int main(void) { return 0; }

is equally ok. (And I offered it as an implementation of IEFBR14, not
of /bin/true.)

Remind me again: Just exactly how many angels fit on the head of a pin?

--
Religion is regarded by the common people as true,
by the wise as foolish,
and by the rulers as useful.

(Seneca the Younger, 65 AD)

 

[Angel]

Remind me again: Just exactly how many angels fit on the head of a pin?

I'm afraid that sizeof (struct _angel) is undefined....

 

[Shao Miller]

I'm afraid that sizeof (struct _angel) is undefined....

If only that was 'struct _Angel', perhaps it could be a documented
extension...