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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#4065

Uncle Steve wrote:
 
> What this is becoming, however, is a
> pedantic disagreement over the validity of function calls in the
> outermost scope of a C program.  It seems a little arbitrary that
> function calls are only valid in the main() scope, or at least this is
> what I perceive as being what the standard says from your replies.

External objects are initialized before program startup.
The initial values can be embedded in the opcode.

-- 
pete

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

#4068

On Mon, May 16, 2011 at 07:27:31AM -0400, pete wrote:
> Uncle Steve wrote:
>  
> > What this is becoming, however, is a
> > pedantic disagreement over the validity of function calls in the
> > outermost scope of a C program.  It seems a little arbitrary that
> > function calls are only valid in the main() scope, or at least this is
> > what I perceive as being what the standard says from your replies.
> 
> External objects are initialized before program startup.
> The initial values can be embedded in the opcode.

Sure, I know that, and it even makes sense.  That's not my issue at
this point.  What bugs me now about all this is that a C source file
contains two sections:  One in which variable declarations and
program statements are valid, and one in which variable declarations
(and assignments) are valid, but where scalar quantities must be
resolved at compile time.

I realize that in practice, variables may be declared out of function
scope, and that the language must offer a facility to initialize them
to a known value (for practical reasons).  But when you're looking at
the code in an editor the only thing distinguishing these two "zones"
is the presence of an open/close brace pair from a function call.  It
seems arbitrary, and I guess there's lots of reasons why it was done
this way -- which I won't speculate about here to avoid flames.

I suppose the real thing here to note is that languages like Perl or
Python are insulated from the processor architecture to a much
greater degree than C, and so some things are easier/harder than
others in these languages from the programmer standpoint.  I'm not
going to switch to C++, so for my purposes, I'll be implementing some
other solution.  Possibly, I many end up without any global variables
at all.



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

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

#4102

On 2011-05-16, Uncle Steve <stevet810@gmail.com> wrote:
> Sure, I know that, and it even makes sense.  That's not my issue at
> this point.  What bugs me now about all this is that a C source file
> contains two sections:  One in which variable declarations and
> program statements are valid, and one in which variable declarations
> (and assignments) are valid, but where scalar quantities must be
> resolved at compile time.

Yup.

> I realize that in practice, variables may be declared out of function
> scope, and that the language must offer a facility to initialize them
> to a known value (for practical reasons).  But when you're looking at
> the code in an editor the only thing distinguishing these two "zones"
> is the presence of an open/close brace pair from a function call.  It
> seems arbitrary, and I guess there's lots of reasons why it was done
> this way -- which I won't speculate about here to avoid flames.

Calling it arbitrary will get you a lot more "flames" than thinking about
the reasons would.

Looking at things in an editor is uninformative.  Think about them compiling.

> I suppose the real thing here to note is that languages like Perl or
> Python are insulated from the processor architecture to a much
> greater degree than C, and so some things are easier/harder than
> others in these languages from the programmer standpoint.

This hasn't got a thing to do with processor architecture.  It has to do
with the order in which things happen.

In perl, Python, Ruby, and the like, everything is being logically executed
when you hit it.  Except BEGIN sections and the like... and even those are
logically "executed" as you hit them, except that executing them consists of
putting them on the list of things to do before running anything else...
which list is executed in the order they were hit.

In C, though, things aren't being "executed" when the compiler sees them.
They're being translated, stored up, and then shuffled together.

Imagine two modules of perl:
	foo.pl:
	sub bar() { return 3; }
	$x = foo();
	1;

	bar.pl:
	sub foo() { return 3; }
	$y = bar();
	1;

Now require these both from another module.  You'll get an error.  Which
error?  The one that comes from the one you require first.  But...  Put
the functions in one, the assignments in the other, require the functions
first, and it works.

This is because the evaluation of these things is *well ordered*.  There
is a strict, unambiguous, definition of the order in which things occur.

Now consider two modules of C:
	foo.c:
	int bar(void) { return 3; }
	int x;
	void init_x(void) { x = foo(); }

	bar.c:
	int foo(void) { return 3; }
	int y;
	void init_y(void) { y = bar(); }

	main.c:
	extern int foo(), bar(), x, y;
	extern void init_x(), init_y();

	int
	main(void) {
		init_x();
		init_y();
	}

Now try any combo you like:
	$ cc -o t foo.c bar.c main.c
	$ cc -o t main.c bar.c foo.c

It'll always work.  Why?  Because things aren't being "executed" in the order
that the compiler sees them.  Things are being compiled, which doesn't involve
any ordering of anything, then linked, which doesn't involve any ordering
of anything (except that some linkers are sorta dumb), and then at runtime,
everything has already been resolved, adjusted, and figured out...

But that's because the language can provide an unambiguous definition of
the order in which it runs code, and that ordering doesn't depend on when
you compile things, or in which order, or anything like that.

The C solution is, arguably, less flexible in terms of what you write, but
it provides much greater confidence in what your code will do when executed.

This distinction isn't arbitrary.  Yes, some implementations allow some kind
of initialization hooks, which may or may not have well-defined interactions
with each other, or with the library.  But...  In perl, if you need one
initializer to run before another, you execute it first.  In C, you don't
really have that option for file-scope things, because there's no "first".

> I'm not
> going to switch to C++, so for my purposes, I'll be implementing some
> other solution.  Possibly, I many end up without any global variables
> at all.

This is nearly always the right choice.  :)

-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]

#4140

On Mon, May 16, 2011 at 07:10:23PM +0000, Seebs wrote:
> On 2011-05-16, Uncle Steve <stevet810@gmail.com> wrote:
> > Sure, I know that, and it even makes sense.  That's not my issue at
> > this point.  What bugs me now about all this is that a C source file
> > contains two sections:  One in which variable declarations and
> > program statements are valid, and one in which variable declarations
> > (and assignments) are valid, but where scalar quantities must be
> > resolved at compile time.
> 
> Yup.
> 
> > I realize that in practice, variables may be declared out of function
> > scope, and that the language must offer a facility to initialize them
> > to a known value (for practical reasons).  But when you're looking at
> > the code in an editor the only thing distinguishing these two "zones"
> > is the presence of an open/close brace pair from a function call.  It
> > seems arbitrary, and I guess there's lots of reasons why it was done
> > this way -- which I won't speculate about here to avoid flames.
> 
> Calling it arbitrary will get you a lot more "flames" than thinking about
> the reasons would.
> 
> Looking at things in an editor is uninformative.  Think about them compiling.
> 
> > I suppose the real thing here to note is that languages like Perl or
> > Python are insulated from the processor architecture to a much
> > greater degree than C, and so some things are easier/harder than
> > others in these languages from the programmer standpoint.
> 
> This hasn't got a thing to do with processor architecture.  It has to do
> with the order in which things happen.
> 
> In perl, Python, Ruby, and the like, everything is being logically executed
> when you hit it.  Except BEGIN sections and the like... and even those are
> logically "executed" as you hit them, except that executing them consists of
> putting them on the list of things to do before running anything else...
> which list is executed in the order they were hit.
> 
> In C, though, things aren't being "executed" when the compiler sees them.
> They're being translated, stored up, and then shuffled together.
> 
> Imagine two modules of perl:
> 	foo.pl:
> 	sub bar() { return 3; }
> 	$x = foo();
> 	1;
> 
> 	bar.pl:
> 	sub foo() { return 3; }
> 	$y = bar();
> 	1;
> 
> Now require these both from another module.  You'll get an error.  Which
> error?  The one that comes from the one you require first.  But...  Put
> the functions in one, the assignments in the other, require the functions
> first, and it works.
> 
> This is because the evaluation of these things is *well ordered*.  There
> is a strict, unambiguous, definition of the order in which things occur.
> 
> Now consider two modules of C:
> 	foo.c:
> 	int bar(void) { return 3; }
> 	int x;
> 	void init_x(void) { x = foo(); }
> 
> 	bar.c:
> 	int foo(void) { return 3; }
> 	int y;
> 	void init_y(void) { y = bar(); }
> 
> 	main.c:
> 	extern int foo(), bar(), x, y;
> 	extern void init_x(), init_y();
> 
> 	int
> 	main(void) {
> 		init_x();
> 		init_y();
> 	}
> 
> Now try any combo you like:
> 	$ cc -o t foo.c bar.c main.c
> 	$ cc -o t main.c bar.c foo.c
> 
> It'll always work.  Why?  Because things aren't being "executed" in the order
> that the compiler sees them.  Things are being compiled, which doesn't involve
> any ordering of anything, then linked, which doesn't involve any ordering
> of anything (except that some linkers are sorta dumb), and then at runtime,
> everything has already been resolved, adjusted, and figured out...
> 
> But that's because the language can provide an unambiguous definition of
> the order in which it runs code, and that ordering doesn't depend on when
> you compile things, or in which order, or anything like that.
> 
> The C solution is, arguably, less flexible in terms of what you write, but
> it provides much greater confidence in what your code will do when executed.
> s
> This distinction isn't arbitrary.  Yes, some implementations allow some kind
> of initialization hooks, which may or may not have well-defined interactions
> with each other, or with the library.  But...  In perl, if you need one
> initializer to run before another, you execute it first.  In C, you don't
> really have that option for file-scope things, because there's no "first".

I have no argument to this, I am in full agreement with your summary.
Since you've arranged the execution order in the code, the compiler
just does what you want.
 
> > I'm not
> > going to switch to C++, so for my purposes, I'll be implementing some
> > other solution.  Possibly, I many end up without any global variables
> > at all.
> 
> This is nearly always the right choice.  :)

It's a bloody lot of work though!



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

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

#4101

On 2011-05-16, Uncle Steve <stevet810@gmail.com> wrote:
> Sorry, skipped your message this morning by accident.  

No worries.

> Well, it's fairly difficult to approach this without making reference
> to a specific implementation.  main() is supposed to be the defined
> entrypoint for C programs, and anything that happens before that is
> supposed (I assume) to set up the execution environment defined by the
> standard, and is implementation specific.  OK.  I get it.  Sorry for
> my confusion over what the gcc info doc said.

It's implementation-specific, and there's also no obvious reason to imagine
it not to be subject to change-at-whim, since it's not part of a spec.

When my initializer runs, is stderr available?  Heck if I know.

(And I say this as someone who is, in fact, using this feature...)

> I don't know anything about how the system libraries are initialized.
> Perhaps I should look; glibc, ulibc, bsd libc, etc. probably all do
> things differently (within reason), meaning I'd probably have to code
> a special case for every port of the app. if I was to use implementation-
> specific hooks.

Basically...

My advice would be, don't rely on such functionality unless you *have* to.
It's an extra source of things which could go wrong, and it's a source of
things which could go wrong in a not-well-specified state, using code paths
that are likely not to be getting tested as carefully as the rest of the
system, and which go wrong in a way that may be a nightmare for a debugger.

> I rely on a consistent heuristic:  develop efficient coding habits.

My experience has been that "efficient" should usually be a matter of
coder time, not speculative execution time.

> Which isn't to say that it can't be fun to find a clever way to shave
> cycles.  There are an endless number of programming tricks that one
> can experiment with, on critical paths, if you've got the time.

Yeah.  But...  It's harder to debug code than write it.  You should stay
very far away from the limits of what you can do when writing code, because
if you don't, you won't be able to debug it.

>> For the sorts of things it makes sense to try to use as initializers, you
>> can reasonably be confident that the value will be fully computed before
>> your code is done compiling.

> For many scalars and string constants this is true, and I have no
> argument about that fact.  What this is becoming, however, is a
> pedantic disagreement over the validity of function calls in the
> outermost scope of a C program.  It seems a little arbitrary that
> function calls are only valid in the main() scope, or at least this is
> what I perceive as being what the standard says from your replies.

I don't think it's arbitrary at all.  This isn't a question of scope.  It's
a question of lifetimes and execution sequence.

Starting with main(), we have a nice, robust, notion of what executes and
when, and what state the environment is in.

Before that, we have NO IDEA.  Consider stderr.  Imagine that the
implementation writes some "init" code which does stuff like:

	stderr = fdopen(2, "w");

now...  Where's the guarantee that their code runs before your code which
does
	fprintf(stderr, "help!\n");
?

Answer:  There isn't one and can't really be one.

> Don't worry, I'm not going to press the C2015 Committee[1] to revise
> the standard.  I simply don't care about it all that much, but it is
> worth noting.

Yes.  It's not "arbitrary", though, except in the sense that any specification
is a little bit arbitrary.

The decision of whether people drive on the left or right side of the road
is arbitrary, but this doesn't mean it's a bad idea to make such a decision
and impose it as a standard.

The C language offers you a well-defined execution environment.  For this to
be feasible, it has to say "starting *here*, you know the following will
work".  The obvious way to do this would be to say "execution starts here,
and then statements occur in order."  Initializers which have to be able
to execute code create all sorts of fun.  Do they execute in parallel?  In
series?  In a consistent series from one run to another, or one compile to
another?

Can of worms.  BIIIIG can of worms.

It was not a careless oversight that the language doesn't support this; it
was a carefully considered decision.

> Alas, you have penetrated my disguise.  I am not worthy to decide what
> code should or should not be in the instruction cache.

"Worthy" isn't at issue.

> I am sorry if
> I have offended your grace, or shamed the honored guild of instruction
> cachers with my unworthy considerations.  In the Future, I will
> endeavor to think about memory as a transparent medium of data storage.

It's not a question of worthy, or an "honored guild".  It's that you can
be reasonably confident that, if you try to think about this stuff, your
code will perform worse than it would have if you didn't.

Sound surprising?  It shouldn't be.  Code is, in general, run on multiple
targets.  Something that tries to optimize for one is likely to deepotimize
for others.

Time spent thinking about whether something which will actually have been
converted to a constant at compile time "fits in the instruction cache" is
time wasted, and if you'd spent it on something more useful, your code would
be better; more stable, faster, whatever else you'd have been working on.
In the real world, your code will be preempted, causing stuff to leave the
instruction cache anyway, it will be run virtualized, it will be translated
into hardware-specific microcode by a JIT compiler running on the CPU...

Do you seriously think that modern x86 CPUs actually *execute* x86
instructions as you would see them in an assembler?  They haven't for years.

Thinking about stuff like that is a distraction from focusing on the code at
a level where you can actually do stuff.  It will only make things worse, not
better.

> [1] Joke.  Not sure what the next revision of C will be called.  I
> can't see there being many changes at this point, C should be about
> ready to be carved in stone by now.

Nah, lots left to be done.

-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]

#4138

On Mon, May 16, 2011 at 07:10:23PM +0000, Seebs wrote:
> On 2011-05-16, Uncle Steve <stevet810@gmail.com> wrote:
> > Sorry, skipped your message this morning by accident.  
> 
> No worries.
> 
> > Well, it's fairly difficult to approach this without making reference
> > to a specific implementation.  main() is supposed to be the defined
> > entrypoint for C programs, and anything that happens before that is
> > supposed (I assume) to set up the execution environment defined by the
> > standard, and is implementation specific.  OK.  I get it.  Sorry for
> > my confusion over what the gcc info doc said.
> 
> It's implementation-specific, and there's also no obvious reason to imagine
> it not to be subject to change-at-whim, since it's not part of a spec.
> 
> When my initializer runs, is stderr available?  Heck if I know.
> 
> (And I say this as someone who is, in fact, using this feature...)

> > I don't know anything about how the system libraries are initialized.
> > Perhaps I should look; glibc, ulibc, bsd libc, etc. probably all do
> > things differently (within reason), meaning I'd probably have to code
> > a special case for every port of the app. if I was to use implementation-
> > specific hooks.
> 
> Basically...
> 
> My advice would be, don't rely on such functionality unless you *have* to.
> It's an extra source of things which could go wrong, and it's a source of
> things which could go wrong in a not-well-specified state, using code paths
> that are likely not to be getting tested as carefully as the rest of the
> system, and which go wrong in a way that may be a nightmare for a debugger.

You're preaching to the converted here.  I've got an irrational
aversion to #ifdefs surrounding platform specific code.  Like, no shit
POSIX was invented.  Sure I could deal with it if I *had to*, but who
would willingly subject themselves to that horror?
 
> > I rely on a consistent heuristic:  develop efficient coding habits.
> 
> My experience has been that "efficient" should usually be a matter of
> coder time, not speculative execution time.

That depends.  Every function has it's own ranking of relative hotness
within the application.  If you've got money to burn, you can afford
to throw as many programmers as you want at the problem.  Maybe you
have so much money you don't care that they're optimizing the
documentation tools.  All I know is that I have programming
proclivities that lead to Cycle Conservation, and who could argue
against that?
 
> > Which isn't to say that it can't be fun to find a clever way to shave
> > cycles.  There are an endless number of programming tricks that one
> > can experiment with, on critical paths, if you've got the time.
> 
> Yeah.  But...  It's harder to debug code than write it.  You should stay
> very far away from the limits of what you can do when writing code, because
> if you don't, you won't be able to debug it.

I've heard that before, and what I say is that the same skill that is
used to write the code is also used in debugging the code.  I really
don't see how I'm going to write myself into a situation where I cannot
debug any system that I wrote.
 
> >> For the sorts of things it makes sense to try to use as initializers, you
> >> can reasonably be confident that the value will be fully computed before
> >> your code is done compiling.
> 
> > For many scalars and string constants this is true, and I have no
> > argument about that fact.  What this is becoming, however, is a
> > pedantic disagreement over the validity of function calls in the
> > outermost scope of a C program.  It seems a little arbitrary that
> > function calls are only valid in the main() scope, or at least this is
> > what I perceive as being what the standard says from your replies.
> 
> I don't think it's arbitrary at all.  This isn't a question of scope.  It's
> a question of lifetimes and execution sequence.
> 
> Starting with main(), we have a nice, robust, notion of what executes and
> when, and what state the environment is in.
> 
> Before that, we have NO IDEA.  Consider stderr.  Imagine that the
> implementation writes some "init" code which does stuff like:
> 
> 	stderr = fdopen(2, "w");
> 
> now...  Where's the guarantee that their code runs before your code which
> does
> 	fprintf(stderr, "help!\n");
> ?
> 
> Answer:  There isn't one and can't really be one.

Sure there can, but it must rely on implementation specific
documentation.
 
> > Don't worry, I'm not going to press the C2015 Committee[1] to revise
> > the standard.  I simply don't care about it all that much, but it is
> > worth noting.
> 
> Yes.  It's not "arbitrary", though, except in the sense that any specification
> is a little bit arbitrary.
> 
> The decision of whether people drive on the left or right side of the road
> is arbitrary, but this doesn't mean it's a bad idea to make such a decision
> and impose it as a standard.
> 
> The C language offers you a well-defined execution environment.  For this to
> be feasible, it has to say "starting *here*, you know the following will
> work".  The obvious way to do this would be to say "execution starts here,
> and then statements occur in order."  Initializers which have to be able
> to execute code create all sorts of fun.  Do they execute in parallel?  In
> series?  In a consistent series from one run to another, or one compile to
> another?
> 
> Can of worms.  BIIIIG can of worms.
> 
> It was not a careless oversight that the language doesn't support this; it
> was a carefully considered decision.

I realize the C standard was not designed arbitrarily, as I understand
the definition of "arbitrary".  Look.  I'm not really worried about
this issue; my program will get written with code that conforms to the
existing standards applicable to the problem domain, and everything
will be just fine.  
 
> > Alas, you have penetrated my disguise.  I am not worthy to decide what
> > code should or should not be in the instruction cache.
> 
> "Worthy" isn't at issue.
> 
> > I am sorry if
> > I have offended your grace, or shamed the honored guild of instruction
> > cachers with my unworthy considerations.  In the Future, I will
> > endeavor to think about memory as a transparent medium of data storage.
> 
> It's not a question of worthy, or an "honored guild".  It's that you can
> be reasonably confident that, if you try to think about this stuff, your
> code will perform worse than it would have if you didn't.

> Sound surprising?  It shouldn't be.  Code is, in general, run on multiple
> targets.  Something that tries to optimize for one is likely to deepotimize
> for others.

Maybe, but I think you presume too much when you assume that the
compiler should be the arbiter of optimization.  Possibly some far-in-
the-future compiler will have strong-AI capabilities wrt code
generation, but until that time the human programmer will probably be
able to do a better job than the compiler.  All things being equal.
 
> Time spent thinking about whether something which will actually have been
> converted to a constant at compile time "fits in the instruction cache" is
> time wasted, and if you'd spent it on something more useful, your code would
> be better; more stable, faster, whatever else you'd have been working on.
> In the real world, your code will be preempted, causing stuff to leave the
> instruction cache anyway, it will be run virtualized, it will be translated
> into hardware-specific microcode by a JIT compiler running on the CPU...
> 
> Do you seriously think that modern x86 CPUs actually *execute* x86
> instructions as you would see them in an assembler?  They haven't for years.
> 
> Thinking about stuff like that is a distraction from focusing on the code at
> a level where you can actually do stuff.  It will only make things worse, not
> better.

We'll see.

> > [1] Joke.  Not sure what the next revision of C will be called.  I
> > can't see there being many changes at this point, C should be about
> > ready to be carved in stone by now.
> 
> Nah, lots left to be done.

Are you saying that there are major changes to the C standard in the
offing?  I don't see how that could be without changing fundamentals,
and we all know that that is about as likely as porcine avians.



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

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

#4142

On 05/16/2011 09:16 PM, Uncle Steve wrote:
...
> Maybe, but I think you presume too much when you assume that the
> compiler should be the arbiter of optimization.  Possibly some far-in-
> the-future compiler will have strong-AI capabilities wrt code
> generation, but until that time the human programmer will probably be
> able to do a better job than the compiler.  All things being equal.

Average C programmers fell behind compilers in their ability to perform
optimization at least a decade ago; probably more. An expert assembly
language programmer can still produce code that is better optimized than
a compiler can produce, But it would take that expert days to optimize
code that the compiler can optimize in seconds. It is, in most cases, a
horrible waste of time (==money) to let humans do something that
computers are so much better at. Algorithm development is a much more
profitable use of expensive human expertise than routine optimization.

>>> [1] Joke.  Not sure what the next revision of C will be called.  I
>>> can't see there being many changes at this point, C should be about
>>> ready to be carved in stone by now.
>>
>> Nah, lots left to be done.
> 
> Are you saying that there are major changes to the C standard in the
> offing?  I don't see how that could be without changing fundamentals,
> and we all know that that is about as likely as porcine avians.

The latest draft is dated 2010-12-02, and can be found at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf>
It summarizes the differences from C99 as follows:

> — conditional (optional) features (including some that were previously mandatory)
> — support for multiple threads of execution including an improved memory sequencing
> model, atomic objects, and thread-local storage (<stdatomic.h> and
> <threads.h>)
> — additional floating-point characteristic macros (<float.h>)
> — querying and specifying alignment of objects (<stdalign.h>, <stdlib.h>)
> — Unicode characters and strings (<uchar.h>) (originally specified in
> ISO/IEC TR 19769:2004)
> — type-generic expressions
> — static assertions
> — anonymous structures and unions
> — no-return functions
> — macros to create complex numbers (<complex.h>)
> — support for opening files for exclusive access
> — removed the gets function (<stdio.h>)
> — added the aligned_alloc, at_quick_exit, and quick_exit functions
> (<stdlib.h>)
> — (conditional) support for bounds-checking interfaces (originally specified in
> ISO/IEC TR 24731−1:2007)
> — (conditional) support for analyzability

-- 
James Kuyper

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

#4145

On Mon, May 16, 2011 at 09:37:57PM -0400, James Kuyper wrote:
> On 05/16/2011 09:16 PM, Uncle Steve wrote:
> ...
> > Maybe, but I think you presume too much when you assume that the
> > compiler should be the arbiter of optimization.  Possibly some far-in-
> > the-future compiler will have strong-AI capabilities wrt code
> > generation, but until that time the human programmer will probably be
> > able to do a better job than the compiler.  All things being equal.
> 
> Average C programmers fell behind compilers in their ability to perform
> optimization at least a decade ago; probably more. An expert assembly
> language programmer can still produce code that is better optimized than
> a compiler can produce, But it would take that expert days to optimize
> code that the compiler can optimize in seconds. It is, in most cases, a
> horrible waste of time (==money) to let humans do something that
> computers are so much better at. Algorithm development is a much more
> profitable use of expensive human expertise than routine optimization.

Yeah, well algorithm development isn't all that sexy these days.  It's
all about the Next! Great! Platform! like Java or whatever.  Ruby
looks good, and just as soon as I free up some CFT, I'm really going
to check it out.
 
> >>> [1] Joke.  Not sure what the next revision of C will be called.  I
> >>> can't see there being many changes at this point, C should be about
> >>> ready to be carved in stone by now.
> >>
> >> Nah, lots left to be done.
> > 
> > Are you saying that there are major changes to the C standard in the
> > offing?  I don't see how that could be without changing fundamentals,
> > and we all know that that is about as likely as porcine avians.
> 
> The latest draft is dated 2010-12-02, and can be found at
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf>
> It summarizes the differences from C99 as follows:
> 
> > — conditional (optional) features (including some that were previously mandatory)
> > — support for multiple threads of execution including an improved memory sequencing
> > model, atomic objects, and thread-local storage (<stdatomic.h> and
> > <threads.h>)
> > — additional floating-point characteristic macros (<float.h>)
> > — querying and specifying alignment of objects (<stdalign.h>, <stdlib.h>)
> > — Unicode characters and strings (<uchar.h>) (originally specified in
> > ISO/IEC TR 19769:2004)
> > — type-generic expressions
> > — static assertions
> > — anonymous structures and unions
> > — no-return functions
> > — macros to create complex numbers (<complex.h>)
> > — support for opening files for exclusive access
> > — removed the gets function (<stdio.h>)
> > — added the aligned_alloc, at_quick_exit, and quick_exit functions
> > (<stdlib.h>)
> > — (conditional) support for bounds-checking interfaces (originally specified in
> > ISO/IEC TR 24731−1:2007) 
> > — (conditional) support for analyzability

Yikes!  Well, I knew RDMA was going to make waves, but I haven't been
programming with threads long enough to really get a feel for how it
might affect the language.  And then there's all that math stuff.

I guess there really is a lot yet to do.



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

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

#4144

On 2011-05-17, Uncle Steve <stevet810@gmail.com> wrote:
> That depends.  Every function has it's own ranking of relative hotness
> within the application.  If you've got money to burn, you can afford
> to throw as many programmers as you want at the problem.  Maybe you
> have so much money you don't care that they're optimizing the
> documentation tools.  All I know is that I have programming
> proclivities that lead to Cycle Conservation, and who could argue
> against that?

Someone who has had to debug code that was written with "efficient" habits.

> I've heard that before, and what I say is that the same skill that is
> used to write the code is also used in debugging the code.  I really
> don't see how I'm going to write myself into a situation where I cannot
> debug any system that I wrote.

Very easily.  It is harder to understand how code is failing than to
understand how it's supposed to work.

> Sure there can, but it must rely on implementation specific
> documentation.

And even given that... Who says they'll not change it later?  Nothing
to keep them from doing so.  Who says the documentation is right?  Who
says they'll fix a "bug" in this stuff?

It's the kind of thing people tend to not care about.

> Maybe, but I think you presume too much when you assume that the
> compiler should be the arbiter of optimization.  Possibly some far-in-
> the-future compiler will have strong-AI capabilities wrt code
> generation, but until that time the human programmer will probably be
> able to do a better job than the compiler.  All things being equal.

Well, uhm.

No.

It's been at least a decade, probably longer, during which humans have
consistently lost to compilers at optimization.

> Are you saying that there are major changes to the C standard in the
> offing?  I don't see how that could be without changing fundamentals,
> and we all know that that is about as likely as porcine avians.

I don't know about "major", but certainly "significant".  Compound literals
were a major change, and I wouldn't be surprised to see comparably significant
changes in future revisions.

-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]

#4147

On Tue, May 17, 2011 at 02:40:15AM +0000, Seebs wrote:
> On 2011-05-17, Uncle Steve <stevet810@gmail.com> wrote:
> > That depends.  Every function has it's own ranking of relative hotness
> > within the application.  If you've got money to burn, you can afford
> > to throw as many programmers as you want at the problem.  Maybe you
> > have so much money you don't care that they're optimizing the
> > documentation tools.  All I know is that I have programming
> > proclivities that lead to Cycle Conservation, and who could argue
> > against that?
> 
> Someone who has had to debug code that was written with "efficient" habits.
> 
> > I've heard that before, and what I say is that the same skill that is
> > used to write the code is also used in debugging the code.  I really
> > don't see how I'm going to write myself into a situation where I cannot
> > debug any system that I wrote.
> 
> Very easily.  It is harder to understand how code is failing than to
> understand how it's supposed to work.

If you don't understand the machine.  Or if there's stuff going on
that's undocumented.  Otherwise, what's the big deal?
 
> > Sure there can, but it must rely on implementation specific
> > documentation.
> 
> And even given that... Who says they'll not change it later?  Nothing
> to keep them from doing so.  Who says the documentation is right?  Who
> says they'll fix a "bug" in this stuff?
> 
> It's the kind of thing people tend to not care about.
> 
> > Maybe, but I think you presume too much when you assume that the
> > compiler should be the arbiter of optimization.  Possibly some far-in-
> > the-future compiler will have strong-AI capabilities wrt code
> > generation, but until that time the human programmer will probably be
> > able to do a better job than the compiler.  All things being equal.
> 
> Well, uhm.
> 
> No.
> 
> It's been at least a decade, probably longer, during which humans have
> consistently lost to compilers at optimization.

What do you mean by "optimization"?
 
> > Are you saying that there are major changes to the C standard in the
> > offing?  I don't see how that could be without changing fundamentals,
> > and we all know that that is about as likely as porcine avians.
> 
> I don't know about "major", but certainly "significant".  Compound literals
> were a major change, and I wouldn't be surprised to see comparably significant
> changes in future revisions.

Yeah, well maybe I'll just become one of those wierd people who lock
in all their code to C99, no matter what developments arise.  I could
do that, you know.  I'm a wierdo.



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

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

#4150

On 2011-05-17, Uncle Steve <stevet810@gmail.com> wrote:
> On Tue, May 17, 2011 at 02:40:15AM +0000, Seebs wrote:
>> Very easily.  It is harder to understand how code is failing than to
>> understand how it's supposed to work.

> If you don't understand the machine.  Or if there's stuff going on
> that's undocumented.  Otherwise, what's the big deal?

Otherwise, the big deal is that if there's a bug, *by definition* you
don't quite understand how the code works.  Figuring it out necessarily
involves understanding something you didn't understand when writing it.

If something is near the limits of what I can design and code correctly,
it will be Too Hard to debug.  I might be able to muddle through, but in
general, it'll stump me.

So I carefully write stuff that's as simple as I can make it, to reduce
the risk.

>> It's been at least a decade, probably longer, during which humans have
>> consistently lost to compilers at optimization.

> What do you mean by "optimization"?

I mean "trying to make code faster by means other than algorithm design".
Stuff like, say, trying to hand-tune assembly, or trying to decide when
a loop should or shouldn't be unrolled, anything like that.  The kind of
thing that is implied by trying to decide whether something will fit in
an instruction cache.

-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]

#4192

On Tue, May 17, 2011 at 04:14:50AM +0000, Seebs wrote:
> On 2011-05-17, Uncle Steve <stevet810@gmail.com> wrote:
> > On Tue, May 17, 2011 at 02:40:15AM +0000, Seebs wrote:
> >> Very easily.  It is harder to understand how code is failing than to
> >> understand how it's supposed to work.
> 
> > If you don't understand the machine.  Or if there's stuff going on
> > that's undocumented.  Otherwise, what's the big deal?
> 
> Otherwise, the big deal is that if there's a bug, *by definition* you
> don't quite understand how the code works.  Figuring it out necessarily
> involves understanding something you didn't understand when writing it.

Your approach to the problem assumes bugs a priori.  It's fairly
difficult to argue against a position where someone has already
assumed the concluding point.
 
> If something is near the limits of what I can design and code correctly,
> it will be Too Hard to debug.  I might be able to muddle through, but in
> general, it'll stump me.
> 
> So I carefully write stuff that's as simple as I can make it, to reduce
> the risk.

Of course.  No programmers expose themselves to the risk of error
intentionally.  Slow and steady as she goes is the order of the day in
programming.
 
> >> It's been at least a decade, probably longer, during which humans have
> >> consistently lost to compilers at optimization.
> 
> > What do you mean by "optimization"?
> 
> I mean "trying to make code faster by means other than algorithm design".
> Stuff like, say, trying to hand-tune assembly, or trying to decide when
> a loop should or shouldn't be unrolled, anything like that.  The kind of
> thing that is implied by trying to decide whether something will fit in
> an instruction cache.

I suppose it depends on the application.  Some people go to lengths to
avoid cache-line thrashing, and all the rest.  Most applications don't
require that level of analytical detail, and so your point is valid
for the majority of cases.
 


Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

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

#4196

On 2011-05-17, Uncle Steve <stevet810@gmail.com> wrote:
> Your approach to the problem assumes bugs a priori.

Why, yes.

I am totally open to reconsidering this if I am ever exposed to an example
of a bug-free program.  And no, I haven't seen one yet.  And I'm including
things like "an assembly program which exists only to execute a single
instruction which takes no operands".

> I suppose it depends on the application.  Some people go to lengths to
> avoid cache-line thrashing, and all the rest.  Most applications don't
> require that level of analytical detail, and so your point is valid
> for the majority of cases.

And the people who are doing that are often wrong -- if not on the machine
they started on, on the machine their code goes live on.

There are a few people doing stuff on multi-billion dollar supercomputers
who might not be stupid to do that stuff.  Not many.  Mostly, it's better
to spend the time on things that will have higher payoffs.

-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]

#4198

On Tue, May 17, 2011 at 10:22:20PM +0000, Seebs wrote:
> On 2011-05-17, Uncle Steve <stevet810@gmail.com> wrote:
> > Your approach to the problem assumes bugs a priori.
> 
> Why, yes.
> 
> I am totally open to reconsidering this if I am ever exposed to an example
> of a bug-free program.  And no, I haven't seen one yet.  And I'm including
> things like "an assembly program which exists only to execute a single
> instruction which takes no operands".

Obviously, the existence of a bug-free program would be a matter of
some significance to the computer science community.  This might be a
fruitful research topic for a team of committed graduate students...
Surely there would be a paper in it *if* such a thing could be found.
 
> > I suppose it depends on the application.  Some people go to lengths to
> > avoid cache-line thrashing, and all the rest.  Most applications don't
> > require that level of analytical detail, and so your point is valid
> > for the majority of cases.
> 
> And the people who are doing that are often wrong -- if not on the machine
> they started on, on the machine their code goes live on.
> 
> There are a few people doing stuff on multi-billion dollar supercomputers
> who might not be stupid to do that stuff.  Not many.  Mostly, it's better
> to spend the time on things that will have higher payoffs.

Like.... better algorithms.  I with you here on this, Peter.



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

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

#4215

On May 18, 1:33 am, Uncle Steve <stevet...@gmail.com> wrote:
>
> > There are a few people doing stuff on multi-billion dollar supercomputers
> > who might not be stupid to do that stuff.  Not many.  Mostly, it's better
> > to spend the time on things that will have higher payoffs.
>
> Like.... better algorithms.  I with you here on this, Peter.
>
But, mainly, better error checking and integration of programs.

Most projects don't fail because the CPU is 50% too slow, or even
because the wrong big O algorithm was chosen, but because the program
doesn't talk properly to other programs, or because it contains a mass
of niggles if not actual bugs.

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

#4245

On Wed, May 18, 2011 at 01:58:39AM -0700, Malcolm McLean wrote:
> On May 18, 1:33 am, Uncle Steve <stevet...@gmail.com> wrote:
> >
> > > There are a few people doing stuff on multi-billion dollar supercomputers
> > > who might not be stupid to do that stuff.  Not many.  Mostly, it's better
> > > to spend the time on things that will have higher payoffs.
> >
> > Like.... better algorithms.  I with you here on this, Peter.
> >
> But, mainly, better error checking and integration of programs.
> 
> Most projects don't fail because the CPU is 50% too slow, or even
> because the wrong big O algorithm was chosen, but because the program
> doesn't talk properly to other programs, or because it contains a mass
> of niggles if not actual bugs.

I've got no previous experience with projects that died because of an
inability to fix bugs, or because of some other flaw.  I imagine even
corporate culture, in and of itself, might be a determining factor in
the success or failure of a project.  And then there's coding
standards and methodologies...

Since I'm the only developer working on my project, I have the freedom
to dictate my arbitrary coding standard, which is comfortable for me
but which might annoy the hell out of someone who does things
differently.  Parallel programming (more than one programmer working
on a program at once) is a logistics nightmare for non-trivial cases;
it's easy to see how some projects might never get off the ground.



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

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

#4232

"Uncle Steve" <stevet810@gmail.com> ha scritto nel messaggio
news:8428af69a40e6b6-f9d86@gmail.com...
> On Tue, May 17, 2011 at 10:22:20PM +0000, Seebs wrote:
>> On 2011-05-17, Uncle Steve <stevet810@gmail.com> wrote:
>> > Your approach to the problem assumes bugs a priori.
>>
>> Why, yes.
>>
>> I am totally open to reconsidering this if I am ever exposed to an example
>> of a bug-free program.  And no, I haven't seen one yet.  And I'm including
>> things like "an assembly program which exists only to execute a single
>> instruction which takes no operands".
>
> Obviously, the existence of a bug-free program would be a matter of
> some significance to the computer science community.  This might be a
> fruitful research topic for a team of committed graduate students...
> Surely there would be a paper in it *if* such a thing could be found.

easy
if a routine can have its input in some range example 1..1000
it is possible to show that for all valid input it return the right
answer; for invalid input it return always error

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

#4239

"io_x" <a@b.c.invalid> writes:

> "Uncle Steve" <stevet810@gmail.com> ha scritto nel messaggio
> news:8428af69a40e6b6-f9d86@gmail.com...
>> On Tue, May 17, 2011 at 10:22:20PM +0000, Seebs wrote:
>>> On 2011-05-17, Uncle Steve <stevet810@gmail.com> wrote:
>>> > Your approach to the problem assumes bugs a priori.
>>>
>>> Why, yes.
>>>
>>> I am totally open to reconsidering this if I am ever exposed to an example
>>> of a bug-free program.  And no, I haven't seen one yet.  And I'm including
>>> things like "an assembly program which exists only to execute a single
>>> instruction which takes no operands".
>>
>> Obviously, the existence of a bug-free program would be a matter of
>> some significance to the computer science community.  This might be a
>> fruitful research topic for a team of committed graduate students...
>> Surely there would be a paper in it *if* such a thing could be found.
>
> easy
> if a routine can have its input in some range example 1..1000
> it is possible to show that for all valid input it return the right
> answer; for invalid input it return always error

Not necessarily.  And of all the places to make that statement,
comp.lang.c is one of the worst.

Consider a C program that does this but reads or writes one off the end
of an array.  It may well work perfectly on testing, and in production
for months, until one day the machine is particularly busy and it gets a
non-zero'd chunk of memory and suddenly returns the wrong result - or
just crashes.  I've seen this happen (OK, confession time, I caused it).
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

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

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

On 2011-05-19, Stefan Ram <ram@zedat.fu-berlin.de> 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?

It'd be very hard to tell.

>   Is the following program bug-free (untested)?

> #include <stdio.h>
> int main( void ){ printf( "Hello world!\n" ); }

In C99, probably.  In C89, of course, it falls off the end of a
function with a return type, and its return status is... I think the standard
actually said "undefined" but I think it probably meant unspecified.  Of
course, that's not to say it's actually correct.  In particular, it turns
out that the terms of a recently-signed sales contract require us to fully
localize all code for .jp customers, and the layout doesn't comply with
the current corporate coding standards.  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, and of
course there's the missing comma in "Hello, world!", and our corporate
style guide requires that exclamation marks be used only for imperatives,
not utterances and interjections.

(Okay, maybe some of this doesn't apply.  Some of it might.  I wouldn't
approve it if it came to me for code review...)

-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]

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

Seebs <usenet-nospam@seebs.net> writes:
> On 2011-05-19, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
[...]
>>   Is the following program bug-free (untested)?
>
>> #include <stdio.h>
>> int main( void ){ printf( "Hello world!\n" ); }
>
[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.

[...]

-- 
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]

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

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

csiph-web