[9fans] speaking of kenc - Plan9

This is a discussion on [9fans] speaking of kenc - Plan9 ; On Tue, May 01, 2007 at 10:56:34AM -0400, Devon H. O'Dell wrote: > > I've seen more than my fair share of tf = !!value; out there, which is > just awful to read. Yes it is, but in the ...

+ Reply to Thread
Page 3 of 7 FirstFirst 1 2 3 4 5 ... LastLast
Results 41 to 60 of 121

Thread: [9fans] speaking of kenc

  1. Re: [9fans] speaking of kenc

    On Tue, May 01, 2007 at 10:56:34AM -0400, Devon H. O'Dell wrote:
    >
    > I've seen more than my fair share of tf = !!value; out there, which is
    > just awful to read.


    Yes it is, but in the 25 years that I have been programming in C,
    I've seen many atrocities. What I haven't seen is a compelling
    need for a boolean type. As Brian and Dennis say in the preface
    to K&R, C is a small language. That smallness makes it possible
    for me to maintain a mental model of what machine code the
    compiler will generate for a given C statement and to keep
    essentially the whole language in my head. This, in turn, allows
    me to write better code. Notice how one can't make similar
    statements about, say, C++ (at least I can't). The last thing C
    needs is a bunch of cruft to satisfy language purists or to save
    the incompetent from themselves.

    jcs

    P.S. Sorry Russ. I'll stop now.

  2. Re: [9fans] speaking of kenc

    On Tue, May 01, 2007 at 10:56:34AM -0400, Devon H. O'Dell wrote:
    > I've seen more than my fair share of tf = !!value; out there, which is
    > just awful to read.


    eye of the beholder? Admittedly it is striking the first few times one reads it.

    But I see it as just another of those idioms which one gets used to.

    Inherently no worse than 'if (!ptr)' or 'if (ptr && ptr->field)'.

    I know some people who get really upset whenever they read the above
    two. Complaining that 'pointers are not booleans!', and demanding
    that comparisions with 'NULL' be added.

    DF

  3. Re: [9fans] speaking of kenc

    Anthony Sorace wrote:
    > i think that's the wrong question. i know plenty of people who believe
    > C suffers from its lack of a formal boolean type, but the correct
    > question for folks like standards bodies (and the peanut gallery here,
    > for whatever we matter) is whether adding it (in any particular form)
    > justifies the cost (in terms of added complexity, architectural
    > mismatch, monetary cost of implementation, or whatever criteria one
    > chooses) of adding it to the standard.


    How hard would it be to add the following to the directory where standard
    headers are kept?

    /* stdbool.h -- almost conforming implementation for pre-C99 environments */
    #ifndef __bool_true_false_are_defined
    #define __bool_true_false_are_defined 1
    /* program is allowed to contain its own definitions, so ... */
    #undef bool
    #undef true
    #undef false
    #define bool int
    #define true 1
    #define false 0
    #endif /* !defined(__bool_true_false_are_defined) */

    This provides 99% of the Boolean functionality that is actually used by
    C99-based applications without having to implement _Bool at all.

  4. Re: [9fans] speaking of kenc

    Jon Snader wrote:
    > Indeed. This (_Bool) does seem to be a solution in search of a
    > problem. Is there anyone (other than a few refugees from Pascal)
    > who believes that C suffers from its lack of a formal boolean
    > type?


    Obviously there were.

    Numerous C programmers have created their own Boolean support,
    e.g.:
    typedef int bool;
    #define false 0
    #define true 1
    The fact that so many have done so argued that there was value
    in a standardardized facility along those lines.

    As to why the programmers thought it was worth doing, perhaps
    they like for data types to match their function, so the source
    code becomes more self-documenting and easier to understand;
    "int" conveys nothing about a Boolean nature, and actually
    suggests some sort of integral measurement of some property.

  5. Re: [9fans] speaking of kenc

    "erik quanstrom" wrote...
    > this is different from how c has traditionally done types.
    > c types mapped to what the hardware provides. unless
    > you're working on a hc6508 or similar, you probablly don't
    > have bit-wide memory access.
    > [bool]'s more in the spirit of oberon, or pascal which have
    > had more formally defined and machine independent
    > types.


    C has a long tradition of not mapping precisely into the
    native types, not even on the PDP-11, where "long"
    was word-swapped from the native format. bool can
    easily be implemented in one of the native integer types.
    Its properties are appropriate for its use.

  6. Re: [9fans] speaking of kenc

    > Inherently no worse than 'if (!ptr)' or 'if (ptr && ptr->field)'.

    to tug this back to plan 9, and to encourage new code to resemble old:
    typically plan 9 code would have
    if(ptr == nil)
    if(ptr != nil && ptr->field)
    [depending on what `field' was, there might even be a != 0].

    we're far too stupid for clever tricks like !!x. we'd probably just write
    tf = (x != 0);
    assuming that's the correct translation (it's pre-espresso here), but it is hardly ever needed anyway.
    !! was probably introduced by people determined to show their perfect grasp
    of the language (if not the science). in fact, in the linux kernel !! seems to
    be used as an operator much less than it is used in excited comments and exciting messages for the console.
    DBG_PRINT(ERR_DBG,"%sont know, can't say!!\n"
    to my surprise there are several instances of that in the plan 9 kernel!! but fortunately
    none of them is serious, and all were added later!!!

  7. Re: [9fans] speaking of kenc

    Ok,

    As we are on the perenial subject of standards, my biggest gripe
    when porting C (which is the problem we are trying to solve
    here right?) is Configure/autoconf, rather than the C language itself.

    How we can sidestep autohell?

    I once had the idea that we (plan9) could parse the autoconf
    definition files from which autoconf generates its Configure script,
    (apologies if my terminology is a bit off, I am no expert), and
    generate a makefile from that.

    It gets a bit nasty as these definition files can contain snippets
    of shell script to test unusal features of your OS/compile environment
    but I guess those could be passed to ape/sh.

    Anyone thought about this, have any ideas, etc? or are we still stuck
    with "unpack the tar on linux, run Configure, copy the hierarchy to
    Plan9, edit the makefile" ☹.

    -Steve

  8. Re: [9fans] speaking of kenc

    On Wed, May 02, 2007 at 08:33:08AM +0000, Douglas A. Gwyn wrote:
    >
    > Obviously there were.
    >
    > Numerous C programmers have created their own Boolean support,
    > e.g.:
    > typedef int bool;
    > #define false 0
    > #define true 1


    Which is exactly why a formal boolean type is *not* needed.
    To paraphrase Dennis, ``If you want Pascal, you know where to
    find it.''

    jcs

  9. Re: [9fans] speaking of kenc

    > "erik quanstrom" wrote...
    > > this is different from how c has traditionally done types.
    > > c types mapped to what the hardware provides. unless
    > > you're working on a hc6508 or similar, you probablly don't
    > > have bit-wide memory access.
    > > [bool]'s more in the spirit of oberon, or pascal which have
    > > had more formally defined and machine independent
    > > types.

    >
    > C has a long tradition of not mapping precisely into the
    > native types, not even on the PDP-11, where "long"
    > was word-swapped from the native format. bool can
    > easily be implemented in one of the native integer types.
    > Its properties are appropriate for its use.


    i assume you mean that the word order was different than
    what the dec compilers generated, not that the unix c compiler
    generated code to word swap longs after the operation. if that's
    true, this case isn't analogous.

    in the case of _Bool assignment the compiler needs to generate
    magic fixup code on each assignment to overcome the machine.

    i would assume (since i don't have the code), the pdp-11 compiler
    needed to do the same dance we do these days for vlong. (or
    one does for short on an 8-bit machine). while this isn't pretty,
    a bigger integer than the hardware provides can be needed and
    difficult to manufacture efficiently in c without access to the
    carry bit or extended MUL result.

    - erik

  10. Re: [9fans] speaking of kenc

    -->"Steve" == Steve Simon writes:

    Steve> How we can sidestep autohell?

    autohell is now a 3-headed beast: automake, autoconf and libtool, where
    some of those are actually multiple components.

    automake is PERL thing that takes a "simplified" Makefile.am, and emits
    a Makefile.in. its added value is understanding how to drive libtool,
    and the creation of Makefiles with standard targets.

    autoconf is a Bourne-ish Shell script and a suite of m4 macros. it
    processes various m4 *.in files to produce (at minimum) a Bourne Shell
    configure script, and a set of Makefiles. its added value is two-fold:
    a series of HAVE_FOO macros used to compile different code fragments,
    and various other variables substituted into the Makefiles to actually
    compile and link different files.

    libtool is another Bourne-ish Shell script that encodes knowledge of how
    shared libraries are built using different linker and runtime-linker
    variants.

    i suspect that they probably require bash, GNU m4 and GNU sed. automake
    needs PERL.


    those porting Python, etc, must have dealt with this somehow?




    d

  11. Re: [9fans] speaking of kenc

    David Arnold writes:

    > -->"Steve" == Steve Simon writes:
    >
    > Steve> How we can sidestep autohell?
    >
    > autohell is now a 3-headed beast: automake, autoconf and libtool,
    > where some of those are actually multiple components.


    Does any of this really *help* with the business of getting arbitrary
    software to compile? The few times I've ever looked into the mess of
    (what seems to me) endlessly circular dependencies of tools and scripts
    and configuration files it seems that most of the config. stuff is busy
    fighting *against* auto-blah and trying to simply tell a Makefile where
    to find something.

    > automake is PERL thing that takes a "simplified" Makefile.am, and
    > emits a Makefile.in. its added value is understanding how to drive
    > libtool, and the creation of Makefiles with standard targets.
    >
    > autoconf is a Bourne-ish Shell script and a suite of m4 macros. it
    > processes various m4 *.in files to produce (at minimum) a Bourne Shell
    > configure script, and a set of Makefiles. its added value is
    > two-fold: a series of HAVE_FOO macros used to compile different code
    > fragments, and various other variables substituted into the Makefiles
    > to actually compile and link different files.
    >
    > libtool is another Bourne-ish Shell script that encodes knowledge of
    > how shared libraries are built using different linker and
    > runtime-linker variants.
    >
    > i suspect that they probably require bash, GNU m4 and GNU sed.
    > automake needs PERL.


    ....each one of which probably needs autoconf, automake and libtool to
    build.

    > those porting Python, etc, must have dealt with this somehow?


    Whiskey?

    > d

    Adrian

  12. Re: [9fans] speaking of kenc

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Autohell is caused by an underlying, much more dangerous problem that
    needs to be addressed: the belief that the myriad POSIX derivatives
    are somehow "different" systems. The superficial incompatibilities
    between the lot of them are addressed by auto*, but simple text
    substitution is insufficient to get around the deeper semantic
    differences when using non-POSIX. And until a case is made for
    supporting non-POSIX systems, autohell will continue to thrive, one
    kludge at a time.

    I used to be a fan of POSIX standardization, but now see the error of
    my ways.

    I know of no way evangelism can succeed against such a firmly
    entrenched standard, no matter how flawed. The best I think we can
    do as a community is to keep looking for the killer ap; sadly, I
    don't think it's in the user space.

    OBP9: Cell mmu.c is nearly done. IBM's systemsim is a godsend. I'm
    glad I don't have to implement mmap ;-)

    Paul


    On 2-May-07, at 8:39 PM, Adrian Tritschler wrote:

    > David Arnold writes:
    >
    >> -->"Steve" == Steve Simon writes:
    >>
    >> Steve> How we can sidestep autohell?
    >>
    >> autohell is now a 3-headed beast: automake, autoconf and libtool,
    >> where some of those are actually multiple components.

    >
    > Does any of this really *help* with the business of getting arbitrary
    > software to compile? The few times I've ever looked into the mess of
    > (what seems to me) endlessly circular dependencies of tools and
    > scripts
    > and configuration files it seems that most of the config. stuff is
    > busy
    > fighting *against* auto-blah and trying to simply tell a Makefile
    > where
    > to find something.
    >
    >> automake is PERL thing that takes a "simplified" Makefile.am, and
    >> emits a Makefile.in. its added value is understanding how to drive
    >> libtool, and the creation of Makefiles with standard targets.
    >>
    >> autoconf is a Bourne-ish Shell script and a suite of m4 macros. it
    >> processes various m4 *.in files to produce (at minimum) a Bourne
    >> Shell
    >> configure script, and a set of Makefiles. its added value is
    >> two-fold: a series of HAVE_FOO macros used to compile different code
    >> fragments, and various other variables substituted into the Makefiles
    >> to actually compile and link different files.
    >>
    >> libtool is another Bourne-ish Shell script that encodes knowledge of
    >> how shared libraries are built using different linker and
    >> runtime-linker variants.
    >>
    >> i suspect that they probably require bash, GNU m4 and GNU sed.
    >> automake needs PERL.

    >
    > ...each one of which probably needs autoconf, automake and libtool to
    > build.
    >
    >> those porting Python, etc, must have dealt with this somehow?

    >
    > Whiskey?
    >
    >> d

    > Adrian


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (Darwin)

    iD8DBQFGOV23pJeHo/Fbu1wRAn0mAJ9V3dOplh1hy3KwDXS6O3nP9LRfHgCdFzhQ
    ekwfjc8+XSHmTRy/AaHSEOQ=
    =NaA3
    -----END PGP SIGNATURE-----

  13. Re: [9fans] speaking of kenc

    hola,

    atohell is crap, we all know it. You'll find how I bypass it in my other post.
    but the bigest problem is the lack of the gcc family.

    "You are not using a supported compiler. We do not have the time to make sure
    everything works with compilers other than the ones we use. Use either the
    same compiler as we do, or use --disable-gcc-check but DO *NOT* REPORT BUGS
    unless you can reproduce them after recompiling with a 2.95.x or 3/4.x version!"

    that's the msg I got when running MPlayer's configure.

    enough ranting

    > OBP9: Cell mmu.c is nearly done. IBM's systemsim is a godsend. I'm
    > glad I don't have to implement mmap ;-)
    >


    congrats!

    --
    Federico G. Benavento

  14. Re: [9fans] speaking of kenc

    On 5/3/07, Federico Benavento wrote:

    > "You are not using a supported compiler. We do not have the time to make sure
    > everything works with compilers other than the ones we use. Use either the
    > same compiler as we do, or use --disable-gcc-check but DO *NOT* REPORT BUGS
    > unless you can reproduce them after recompiling with a 2.95.x or 3/4.x version!"


    note the best part here: the implicit assumption that there is only
    one compiler. by "same compiler as we [use]", they mean the same
    *version*. using an actual different compiler (we needn't even get as
    "exotic" as kencc; lcc will do nicely) is so far outside the realm of
    possibility they don't even need to tell you not to do it.

  15. Re: [9fans] speaking of kenc

    I'm a unix admin at work, and was building a copy of php for a dev. I'd sure
    hate to miss one of those libraries to include; luckily libtool finally
    gave:
    -lcrypt -lcrypt -liconv -liconv -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lxml2
    -lz -lm -lcrypt -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -o
    sapi/cli/php
    Now if I could only write the Department of Redundancy Department at FSF
    we'll be all set...

    On 5/3/07, Federico Benavento wrote:
    >
    > hola,
    >
    > atohell is crap, we all know it. You'll find how I bypass it in my other
    > post.
    > but the bigest problem is the lack of the gcc family.
    >
    > "You are not using a supported compiler. We do not have the time to make
    > sure
    > everything works with compilers other than the ones we use. Use either
    > the
    > same compiler as we do, or use --disable-gcc-check but DO *NOT* REPORT
    > BUGS
    > unless you can reproduce them after recompiling with a 2.95.x or 3/4.x
    > version!"
    >
    > that's the msg I got when running MPlayer's configure.
    >
    > enough ranting
    >
    > > OBP9: Cell mmu.c is nearly done. IBM's systemsim is a godsend. I'm
    > > glad I don't have to implement mmap ;-)
    > >

    >
    > congrats!
    >
    > --
    > Federico G. Benavento
    >




    --
    "No stranger to me is this wanderer: many years ago passed he by.
    Zarathustra he was called; but he hath altered.
    Then thou carriedst thine ashes into the mountains: wilt thou now
    carry thy fire into the valleys? Fearest thou not the incendiary's
    doom?
    Yea, I recognize Zarathustra. Pure is his eye, and no loathing
    lurketh about his mouth. Goeth he not along like a dancer?"
    -- The Saint, Also Sprach Zarathustra


  16. Re: [9fans] speaking of kenc

    On Thu, 2007-05-03 at 06:11 +0200, Federico Benavento wrote:
    > hola,
    >
    > atohell is crap, we all know it. You'll find how I bypass it in my other post.
    > but the bigest problem is the lack of the gcc family.
    >
    > "You are not using a supported compiler. We do not have the time to make sure
    > everything works with compilers other than the ones we use. Use either the
    > same compiler as we do, or use --disable-gcc-check but DO *NOT* REPORT BUGS
    > unless you can reproduce them after recompiling with a 2.95.x or 3/4.x version!"
    >
    > that's the msg I got when running MPlayer's configure.


    To be completely honest -- that's not their fault actually. Its just
    that GCC is so broken when it comes to compatibility that you wouldn't
    believe it.

    Thanks,
    Roman.

    P.S. Here at Sun I've been putting some of the GCC extensions
    into Sun Studio, and even though I usually feel disgusted about most
    of them -- things like asm inlines are actually quite useful. And
    that's what kenc has no way of providing.


  17. Re: [9fans] speaking of kenc

    > P.S. Here at Sun I've been putting some of the GCC extensions
    > into Sun Studio, and even though I usually feel disgusted about most
    > of them


    Oh God please NO! I've been using the Sun Studio compiler as a reference
    compiler to weed out all this GNU bull****. You guys already ship gcc in
    /usr/sfw. Please don't **** the rest of the world up with this nonsense.


    --lyndon

    I have challenged the entire quality assurance team to a Bat-Leth
    contest. They will not concern us again.

  18. Re: [9fans] speaking of kenc

    > of them -- things like asm inlines are actually quite useful. And
    > that's what kenc has no way of providing.


    the more you see, the more you come to love ken's compiler
    for the features it does not have.

    - erik

  19. Re: [9fans] speaking of kenc

    On Thu, 2007-05-03 at 22:00 -0400, erik quanstrom wrote:
    > > of them -- things like asm inlines are actually quite useful. And
    > > that's what kenc has no way of providing.

    >
    > the more you see, the more you come to love ken's compiler
    > for the features it does not have.


    As far as I can tell C (as in language) has always been a sort of
    a cross-paltform assembler. Its just sometimes you need hooks
    to the native one. You might disagree -- but I still do code in
    assembly. May be its a bad habit dating back to ZX80 times, dunno.

    Thanks,
    Roman.


  20. Re: [9fans] speaking of kenc

    > As far as I can tell C (as in language) has always been a sort of
    > a cross-paltform assembler. Its just sometimes you need hooks
    > to the native one. You might disagree -- but I still do code in
    > assembly.


    That's called as(1).


    --lyndon

    I think 3B2 code deserves its own place in hell. Poring over the
    ESS#5 code, someone found that there were lots of strcmp(p, "f(")
    == 0 checks (I may have gotten the exact string wrong but it's
    close). It took us a while to figure out why. Apparently, location
    0 on the 3b had the 3 bytes 'f' '(' '\0', someone noticed that when
    programs blew up they were pointing to "f(", and the worlds most
    amazing kludge for detecting nil pointers was born.

    -- Dave Presotto

+ Reply to Thread
Page 3 of 7 FirstFirst 1 2 3 4 5 ... LastLast