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

Groups > comp.lang.c > #4138

Re: Non-constant initializers

Show key headers only | View raw

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?

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web