Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #3855 > unrolled thread

Non-constant initializers

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-12 22:59 +0000
    Re: Non-constant initializers Ian Collins <ian-news@hotmail.com> - 2011-05-13 11:07 +1200
      Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-12 23:17 +0000
        Re: Non-constant initializers Ian Collins <ian-news@hotmail.com> - 2011-05-13 11:20 +1200
          Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-12 23:30 +0000
            Re: Non-constant initializers Ian Collins <ian-news@hotmail.com> - 2011-05-13 11:34 +1200
              Re: Non-constant initializers Keith Thompson <kst-u@mib.org> - 2011-05-12 16:52 -0700
                Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-14 00:13 +0000
                  Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-14 01:28 +0000
                    Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 13:52 -0400
                  Re: Non-constant initializers kym@kymhorsell.com - 2011-05-14 01:54 +0000
                    Re: Non-constant initializers Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-14 01:07 -0700
                      Re: Non-constant initializers kym@kymhorsell.com - 2011-05-14 09:22 +0000
                        Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-14 17:14 +0000
              Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-14 00:11 +0000
    Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-12 18:08 -0500
      Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-12 19:22 -0400
        Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-12 18:53 -0500
          Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 13:59 -0400
            Re: Non-constant initializers Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-14 14:19 -0400
              Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-14 15:04 -0500
              Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 15:10 -0400
                Re: Non-constant initializers James Kuyper <jameskuyper@verizon.net> - 2011-05-14 16:01 -0400
                  Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 16:57 -0400
            Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-14 14:30 -0500
              Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 15:25 -0400
                Re: Non-constant initializers Keith Thompson <kst-u@mib.org> - 2011-05-14 13:05 -0700
                  Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 17:00 -0400
                Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-14 16:14 -0500
                  Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-14 16:49 -0500
                  Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 18:21 -0400
                    Re: Non-constant initializers Shao Miller <sha0.miller@gmail.com> - 2011-05-14 21:26 -0500
                      Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-15 14:01 -0400
                Re: Non-constant initializers Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-14 17:45 -0400
                  Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-14 18:09 -0400
                    Re: Non-constant initializers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-15 04:01 +0100
                      Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-15 13:26 -0400
                        Re: Non-constant initializers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 02:32 +0100
                Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-15 03:59 +0000
                  Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-16 04:49 -0400
                    Re: Non-constant initializers pete <pfiland@mindspring.com> - 2011-05-16 07:27 -0400
                      Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-16 09:24 -0400
                        Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-16 19:10 +0000
                          Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-16 21:23 -0400
                    Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-16 19:10 +0000
                      Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-16 21:16 -0400
                        Re: Non-constant initializers James Kuyper <jameskuyper@verizon.net> - 2011-05-16 21:37 -0400
                          Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-16 22:42 -0400
                        Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-17 02:40 +0000
                          Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-16 22:50 -0400
                            Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-17 04:14 +0000
                              Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-17 17:37 -0400
                                Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-17 22:22 +0000
                                  Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-17 18:33 -0400
                                    Re: Non-constant initializers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-18 01:58 -0700
                                      Re: Non-constant initializers Uncle Steve <stevet810@gmail.com> - 2011-05-18 12:45 -0400
                                    Re: Non-constant initializers "io_x" <a@b.c.invalid> - 2011-05-18 19:30 +0200
                                      Re: Non-constant initializers Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-18 20:01 +0100
                                    Re: bug-free C code (was: Non-constant initializers) Seebs <usenet-nospam@seebs.net> - 2011-05-19 02:21 +0000
                                      Re: bug-free C code (was: Non-constant initializers) Keith Thompson <kst-u@mib.org> - 2011-05-18 20:00 -0700
                                        Re: bug-free C code (was: Non-constant initializers) Seebs <usenet-nospam@seebs.net> - 2011-05-19 03:14 +0000
                                          Re: bug-free C code (was: Non-constant initializers) Keith Thompson <kst-u@mib.org> - 2011-05-19 07:49 -0700
                                            Re: bug-free C code (was: Non-constant initializers) Seebs <usenet-nospam@seebs.net> - 2011-05-19 15:16 +0000
                                    Re: bug-free C code Ben Pfaff <blp@cs.stanford.edu> - 2011-05-18 20:02 -0700
                                      Re: bug-free C code Keith Thompson <kst-u@mib.org> - 2011-05-18 20:09 -0700
                                        Re: bug-free C code Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-18 23:24 -0400
                                          Re: bug-free C code Angel <angel+news@spamcop.net> - 2011-05-19 06:39 +0000
                                            Re: bug-free C code Keith Thompson <kst-u@mib.org> - 2011-05-19 08:05 -0700
                                              Re: bug-free C code Angel <angel+news@spamcop.net> - 2011-05-19 16:22 +0000
                                                Re: bug-free C code Keith Thompson <kst-u@mib.org> - 2011-05-19 11:36 -0700
                                                  Re: bug-free C code Ben Pfaff <blp@cs.stanford.edu> - 2011-05-19 12:21 -0700
                                                    Re: bug-free C code Keith Thompson <kst-u@mib.org> - 2011-05-19 13:12 -0700
                                                      Re: bug-free C code gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-19 21:52 +0000
                                                        Re: bug-free C code Angel <angel+news@spamcop.net> - 2011-05-19 22:16 +0000
                                                          Re: bug-free C code Shao Miller <sha0.miller@gmail.com> - 2011-05-19 17:25 -0500
                                                          Re: bug-free C code Kenneth Brody <kenbrody@spamcop.net> - 2011-05-20 13:32 -0400
                                                  Re: bug-free C code gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-19 21:51 +0000
                                                    Re: bug-free C code Kenneth Brody <kenbrody@spamcop.net> - 2011-05-20 13:30 -0400
                                    Re: bug-free C code "Joel C. Salomon" <joelcsalomon@gmail.com> - 2011-05-18 23:13 -0400
                                      Re: bug-free C code Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-19 08:23 +0100
        Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-13 00:15 +0000
        Re: Non-constant initializers "io_x" <a@b.c.invalid> - 2011-05-13 11:01 +0200
      Re: Non-constant initializers Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-12 16:30 -0700
    Re: Non-constant initializers Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-12 16:15 -0700
      Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-12 23:28 +0000
    Re: Non-constant initializers Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-12 18:01 -0600
      Re: Non-constant initializers Keith Thompson <kst-u@mib.org> - 2011-05-12 18:15 -0700
        Re: Non-constant initializers Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-12 22:56 -0600
          Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-13 05:18 +0000
            Re: Non-constant initializers Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-13 09:10 -0600
              Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-13 20:56 +0000
        Re: Non-constant initializers Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-18 23:47 -0700
          Re: Non-constant initializers Keith Thompson <kst-u@mib.org> - 2011-05-19 08:15 -0700
      Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-13 23:57 +0000

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#4285 — Re: bug-free C code (was: Non-constant initializers)

On 2011-05-19, Keith Thompson <kst-u@mib.org> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
> [snip]
>>                                          Also, by SHEER COINCIDENCE,
>> it turns out that the host compiler is translating calls to printf with
>> no format specifiers into calls to puts, and that an unrelated optimization
>> for string literals used as function arguments is causing the puts
>> to generate an extra carriage return under some circumstances,
> [snip]

> Surely that would be a bug in your implementation, not in the program.

The user doesn't care whose fault it is; what matters is whether the program
runs correctly.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#4327 — Re: bug-free C code (was: Non-constant initializers)

Seebs <usenet-nospam@seebs.net> writes:
> On 2011-05-19, Keith Thompson <kst-u@mib.org> wrote:
>> Seebs <usenet-nospam@seebs.net> writes:
>> [snip]
>>>                                          Also, by SHEER COINCIDENCE,
>>> it turns out that the host compiler is translating calls to printf with
>>> no format specifiers into calls to puts, and that an unrelated optimization
>>> for string literals used as function arguments is causing the puts
>>> to generate an extra carriage return under some circumstances,
>> [snip]
>
>> Surely that would be a bug in your implementation, not in the program.
>
> The user doesn't care whose fault it is; what matters is whether the program
> runs correctly.

True, but irrelevant to the issue of "bug-free C code".  You might as
well cite an example where the program didn't work because the monitor
wasn't powered on.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#4330 — Re: bug-free C code (was: Non-constant initializers)

On 2011-05-19, Keith Thompson <kst-u@mib.org> wrote:
> True, but irrelevant to the issue of "bug-free C code".  You might as
> well cite an example where the program didn't work because the monitor
> wasn't powered on.

I'm not sure about that.  I think there's a sort of realm-of-responsibility
you face with code, and in general, I figure you're responsible up to the
edge of the software line when writing code.  Maybe even some kinds of
hardware errata.

Consider the famous pentium F00F bug.  I think people would generally agree
that a kernel which didn't protect against it was "buggy".

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#4280 — Re: bug-free C code

ram@zedat.fu-berlin.de (Stefan Ram) writes:

>   Is the following program bug-free (untested)?
>
> #include <stdio.h>
> int main( void ){ printf( "Hello world!\n" ); }

It doesn't check for errors writing to stdout.

It isn't internationalized.
-- 
Ben Pfaff 
http://benpfaff.org

[toc] | [prev] | [next] | [standalone]

#4287 — Re: bug-free C code

Ben Pfaff <blp@cs.stanford.edu> writes:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>   Is the following program bug-free (untested)?
>>
>> #include <stdio.h>
>> int main( void ){ printf( "Hello world!\n" ); }
>
> It doesn't check for errors writing to stdout.
>
> It isn't internationalized.

Ok, how about this (also untested):

int main(void) { return 0; }

(Note: This program is intended only for conforming hosted
implementations.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#4288 — Re: bug-free C code

On 5/18/2011 11:09 PM, Keith Thompson wrote:
> Ben Pfaff<blp@cs.stanford.edu>  writes:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>    Is the following program bug-free (untested)?
>>>
>>> #include<stdio.h>
>>> int main( void ){ printf( "Hello world!\n" ); }
>>
>> It doesn't check for errors writing to stdout.
>>
>> It isn't internationalized.
>
> Ok, how about this (also untested):
>
> int main(void) { return 0; }
>
> (Note: This program is intended only for conforming hosted
> implementations.)

     This attempted reimplementation of /bin/false fails to
satisfy the requirements.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#4294 — Re: bug-free C code

On 2011-05-19, Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
> On 5/18/2011 11:09 PM, Keith Thompson wrote:
>>
>> Ok, how about this (also untested):
>>
>> int main(void) { return 0; }
>>
>> (Note: This program is intended only for conforming hosted
>> implementations.)
>
>      This attempted reimplementation of /bin/false fails to
> satisfy the requirements.

That is because it is actually a reimplementation of /bin/true. (0 ==
true in Unix world.)


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#4329 — Re: bug-free C code

Angel <angel+news@spamcop.net> writes:
> On 2011-05-19, Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
>> On 5/18/2011 11:09 PM, Keith Thompson wrote:
>>>
>>> Ok, how about this (also untested):
>>>
>>> int main(void) { return 0; }
>>>
>>> (Note: This program is intended only for conforming hosted
>>> implementations.)
>>
>>      This attempted reimplementation of /bin/false fails to
>> satisfy the requirements.
>
> That is because it is actually a reimplementation of /bin/true. (0 ==
> true in Unix world.)

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; }

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#4337 — Re: bug-free C code

On 2011-05-19, Keith Thompson <kst-u@mib.org> wrote:
> Angel <angel+news@spamcop.net> writes:
>> On 2011-05-19, Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
>>> On 5/18/2011 11:09 PM, Keith Thompson wrote:
>>>>
>>>> Ok, how about this (also untested):
>>>>
>>>> int main(void) { return 0; }
>>>>
>>>> (Note: This program is intended only for conforming hosted
>>>> implementations.)
>>>
>>>      This attempted reimplementation of /bin/false fails to
>>> satisfy the requirements.
>>
>> That is because it is actually a reimplementation of /bin/true. (0 ==
>> true in Unix world.)
>
> 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; }


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#4350 — Re: bug-free C code

Angel <angel+news@spamcop.net> writes:
> On 2011-05-19, Keith Thompson <kst-u@mib.org> wrote:
>> Angel <angel+news@spamcop.net> writes:
>>> On 2011-05-19, Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
>>>> On 5/18/2011 11:09 PM, Keith Thompson wrote:
>>>>>
>>>>> Ok, how about this (also untested):
>>>>>
>>>>> int main(void) { return 0; }
>>>>>
>>>>> (Note: This program is intended only for conforming hosted
>>>>> implementations.)
>>>>
>>>>      This attempted reimplementation of /bin/false fails to
>>>> satisfy the requirements.
>>>
>>> That is because it is actually a reimplementation of /bin/true. (0 ==
>>> true in Unix world.)
>>
>> 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; }

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.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#4359 — Re: bug-free C code

Keith Thompson <kst-u@mib.org> writes:

> Angel <angel+news@spamcop.net> writes:
>> #include <stdlib.h>
>>
>> int main(void) { return EXIT_SUCCESS; }
>
> 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).
-- 
Ben Pfaff 
http://benpfaff.org

[toc] | [prev] | [next] | [standalone]

#4364 — Re: bug-free C code

Ben Pfaff <blp@cs.stanford.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Angel <angel+news@spamcop.net> writes:
>>> #include <stdlib.h>
>>>
>>> int main(void) { return EXIT_SUCCESS; }
>>
>> 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).

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.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#4382 — Re: bug-free C code

In article <lny6221mc3.fsf@nuthaus.mib.org>,
Kiki Thompson  <kst-u@mib.org> flitted:
...
>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)

[toc] | [prev] | [next] | [standalone]

#4391 — Re: bug-free C code

On 2011-05-19, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <lny6221mc3.fsf@nuthaus.mib.org>,
> Kiki Thompson  <kst-u@mib.org> flitted:
> ...
>>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?

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


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#4392 — Re: bug-free C code

On 5/19/2011 5:16 PM, Angel wrote:
> On 2011-05-19, Kenny McCormack<gazelle@shell.xmission.com>  wrote:
>> In article<lny6221mc3.fsf@nuthaus.mib.org>,
>> Kiki Thompson<kst-u@mib.org>  flitted:
>> ...
>>> 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?
>
> I'm afraid that sizeof (struct _angel) is undefined.... :-)
>
>

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

[toc] | [prev] | [next] | [standalone]

#4443 — Re: bug-free C code

On 5/19/2011 6:16 PM, Angel wrote:
> On 2011-05-19, Kenny McCormack<gazelle@shell.xmission.com>  wrote:
[...]
>> Remind me again: Just exactly how many angels fit on the head of a pin?
>
> I'm afraid that sizeof (struct _angel) is undefined.... :-)

You forgot to read the docs.  You need to #include <deity/messengers.h> first.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#4381 — Re: bug-free C code

In article <ln7h9m35bs.fsf@nuthaus.mib.org>,
Kiki Thompson  <kst-u@mib.org> flitted:
...
>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.

[toc] | [prev] | [next] | [standalone]

#4442 — Re: bug-free C code

On 5/19/2011 5:51 PM, Kenny McCormack wrote:
> In article<ln7h9m35bs.fsf@nuthaus.mib.org>,
> Kiki Thompson<kst-u@mib.org>  flitted:
[...]
>> Context is important.
>
> Remind me again: Just exactly how many angels fit on the head of a pin?

Sewing or bowling?

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#4284 — Re: bug-free C code

On 05/18/2011 09:50 PM, Stefan Ram wrote:
> Uncle Steve <stevet810@gmail.com> writes:
>> Obviously, the existence of a bug-free program would be a matter of
>> some significance to the computer science community.
> 
>   How would one know it's bug-free?
> 
>   Is the following program bug-free (untested)?
> 
> #include <stdio.h>
> int main( void ){ printf( "Hello world!\n" ); }

Ignores value returned from printf().  What happens if there's a problem
with stdout?

(I don't remember where I saw this, but I read an article some time ago
comparing the error-checking version of "hello world" in several
languages.  The simple C++ one, for instance, might throw an unhandled
exception.)

--Joel

[toc] | [prev] | [next] | [standalone]

#4301 — Re: bug-free C code

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> "Joel C. Salomon" <joelcsalomon@gmail.com> writes:
>>>#include <stdio.h>
>>>int main( void ){ printf( "Hello world!\n" ); }
>>Ignores value returned from printf().  What happens if there's a problem
>>with stdout?
>
> #include <stdio.h>
> int main( void ){ while( printf( "Hello world!\n" )!= 13 ); }

Doesn't qualify if the requirement is that it is guaranteed to terminate.

>
> #include <stdio.h>
> int main( void )
> { if( printf( "Hello world!\n" )!= 13 )
>   fprintf( stderr, "Please repair your stdout!\n" ); }

And if stderr is just as faulty?

>
> #include <stdio.h>
> #include <stdlib.h>
> int main( void )
> { return printf( "Hello world!\n" )== 13 ? EXIT_SUCCESS : EXIT_FAILURE; }

I think this is getting closer.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web