Language standard: the least common denominator vs. utility

Discussion in 'C Programming' started by David Mathog, Oct 19, 2006.

  1. David Mathog

    David Mathog Guest

    One thing that keeps coming up in this forum is that
    standard C lacks many functions which are required in
    a workstation or server but not possible in an embedded controller.
    This results in a plethora of "don't ask here,
    ask in comp.x.y instead", for queries on functions that from the
    documentation available to the programmer appear to be part
    of the C language. I think largely because of this "least common
    denominator" C language standard we have POSIX, XPG4, etc, which
    add these useful and in many instances necessary pieces. And this
    multiplicity of standards can be a real pain. I would really rather
    write code that complies with _ONE_ language standard than write code
    that has to comply with _MANY_ interrelated language standards.

    Just for the sake of argument, would it be so terribly wrong for the
    ISO/ANSI C standard to define capabilities relevant for computers
    other than dishwasher controllers? For instance, if the language
    required the compiler define for the target platform these constants as
    0 (not present) or 1 or higher (present, with number indicating various
    future revision levels):

    ISOC_CAPABILITY_MULTIUSER
    ISOC_CAPABILITY_NETWORK_IPV4
    ISOC_CAPABILITY_NETWORK_IPV6
    ISOC_CAPABILITY_FILELOCKING
    ISOC_CAPABILITY_INTERPROCESS
    etc.

    The code could test for these, and if present, utilize the relevant
    supported functions. For instance, if MULTIUSER was defined then
    some form of "getusername" would be supported.

    Note that this is more or less what compilers do now, except that the
    constants refer to POSIX, XPG4, etc, and it is not so much including by
    capability, but including by language extension, with the latter rarely
    clearly associated with the former. This results in insanely messy
    compiler provided include files in which it is often painful to trace
    through the logic to determine which combination of posix,xpg4,ansi etc
    must be set at compile time to obtain the desired functions.

    For those purists who work on embedded controllers the potential
    availability of these extra functions should pose no problem whatsoever.
    They are perfectly free NOT to use them. The cross compiler would
    negate these constants so that any code that accidentally tried to
    use a function not supported on the target platform would be flagged at
    compile time.

    Regards,

    David Mathog
     
    David Mathog, Oct 19, 2006
    #1
    1. Advertising

  2. David Mathog wrote:
    > One thing that keeps coming up in this forum is that
    > standard C lacks many functions which are required in
    > a workstation or server but not possible in an embedded controller. This
    > results in a plethora of "don't ask here,
    > ask in comp.x.y instead", for queries on functions that from the
    > documentation available to the programmer appear to be part
    > of the C language. I think largely because of this "least common
    > denominator" C language standard we have POSIX, XPG4, etc, which
    > add these useful and in many instances necessary pieces. And this
    > multiplicity of standards can be a real pain. I would really rather
    > write code that complies with _ONE_ language standard than write code
    > that has to comply with _MANY_ interrelated language standards.
    >
    > Just for the sake of argument, would it be so terribly wrong for the
    > ISO/ANSI C standard to define capabilities relevant for computers
    > other than dishwasher controllers? For instance, if the language
    > required the compiler define for the target platform these constants as
    > 0 (not present) or 1 or higher (present, with number indicating various
    > future revision levels):
    >

    [...]
    This exact discussion seems to pop up in reference to a great number of
    languages that are common in the embedded world. For example, when
    Forth was standardized there was a lot of discussion about the sorts of
    capabilities various platforms could provide, and how much of that would
    be included in the standard.

    They ended up defining a "core" standard with many specific optional
    capabilities. A conforming Forth implementation just has to satisfy the
    core requirements and state which of the optional capabilities it supports.

    So, this sort of thing has been adopted in other languages. I'm not
    familiar enough with the ISO C standard to comment on whether there are
    similar situations there.
     
    Clever Monkey, Oct 19, 2006
    #2
    1. Advertising

  3. David Mathog

    Chris Torek Guest

    In article <eh87u3$3mk$>
    David Mathog <> wrote:
    >Just for the sake of argument, would it be so terribly wrong for the
    >ISO/ANSI C standard to define capabilities relevant for computers
    >other than dishwasher controllers? For instance, if the language
    >required the compiler define for the target platform these constants as
    >0 (not present) or 1 or higher (present, with number indicating various
    >future revision levels):
    >
    >ISOC_CAPABILITY_MULTIUSER
    >ISOC_CAPABILITY_NETWORK_IPV4
    >ISOC_CAPABILITY_NETWORK_IPV6
    >ISOC_CAPABILITY_FILELOCKING
    >ISOC_CAPABILITY_INTERPROCESS
    >etc.
    >
    >The code could test for these, and if present, utilize the relevant
    >supported functions. For instance, if MULTIUSER was defined then
    >some form of "getusername" would be supported.


    This sort of thing has been done in other language standards.

    The result generally seems to be:

    a) the "core" language standard is not as good, because the
    standardizing-group spent a fair bit of effort on the
    "peripheral" parts and had little time left over for the
    "core" part.

    b) the "peripheral" parts *really* stink. :)

    Functionally, there is no real difference between this and what we
    have now:

    >Note that this is more or less what compilers do now, except that the
    >constants refer to POSIX, XPG4, etc, and it is not so much including by
    >capability, but including by language extension, with the latter rarely
    >clearly associated with the former. This results in insanely messy
    >compiler provided include files in which it is often painful to trace
    >through the logic to determine which combination of posix,xpg4,ansi etc
    >must be set at compile time to obtain the desired functions.


    .... except that, in the "now" case, when ISO C conflicts with POSIX,
    it is pretty clear which one you *should* get when you select "ISO
    C" or "POSIX". It may not be obvious *how* to do it, but at least
    the Standard-forming groups are independent and hence (at least
    logically speaking) more accountable.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Oct 19, 2006
    #3
  4. In article <eh87u3$3mk$>,
    David Mathog <> wrote:

    >Just for the sake of argument, would it be so terribly wrong for the
    >ISO/ANSI C standard to define capabilities relevant for computers
    >other than dishwasher controllers? For instance, if the language
    >required the compiler define for the target platform these constants as
    >0 (not present) or 1 or higher (present, with number indicating various
    >future revision levels):


    >ISOC_CAPABILITY_MULTIUSER
    >ISOC_CAPABILITY_NETWORK_IPV4
    >ISOC_CAPABILITY_NETWORK_IPV6
    >ISOC_CAPABILITY_FILELOCKING
    >ISOC_CAPABILITY_INTERPROCESS
    >etc.


    >The code could test for these, and if present, utilize the relevant
    >supported functions. For instance, if MULTIUSER was defined then
    >some form of "getusername" would be supported.


    Looking at that -particular- list, I notice some semantic difficulties.

    The Unix OS I'm using at the moment has IPv6 capabilities, but
    we haven't configured any IPv6 interfaces (or infrastructure).
    Theoretically, by the time we run the binary, we might have -- or we
    might want the binary to be usable on other systems with exactly the
    same OS which might happen to have IPv6 interfaces configured.

    Thus, any capabilities need to semantically distinguish between,
    "the system knows about this family of functions and structures
    and can compile and link with them" versus "this is enabled on the
    system the binary is running on right now".

    Similarily, although my OS supports IPv6, I might know that within
    the effective lifetime of the binary, that we will not run it on
    any system with IPv6 actually configured: therefore, there should
    be available a corresponding series of overrides to say "don't use
    this feature even though the system supports it".


    Secondly, the standardization processes always like to see an
    example implementation (to prove that it can be done without a lot
    of trouble), and like to see that the example implementation has
    actually been successfully used. I would thus propose that instead
    of starting at the standardization level, that an autoconfig library
    be built up, of standardized ways to probe for a feature, and
    standardized feature naming conventions.

    Imagine, for example, a facility sort of like CPAN (Comprehensive Perl
    Archive Network), with an interface that allowed one to easily search
    for a particular feature test and load the test structure in, and then
    "include" that in one's automake configuration file for any particular
    project. Like CPAN, there should be "versions" of the feature test
    available and a mechanism to be notified of new versions; and there
    should be major and minor components to the version number (major
    number changes indicating backwards incompatabilities in the list of
    names defined). And as successful probes for one feature might depend
    upon successful probes for another feature, the probe scripts should
    have the equivilent of perl's "require" -- i.e., run such and such a
    feature test if you haven't already done so. Also, feature tests could
    end up interrelated, so you would want dependancy checking against your
    "installed" feature tests... and if the feature test you'd like to
    load down relies upon something you haven't already loaded in (or need
    a newer version of), you'd like the option of automatically installing
    the missing or newer versions.

    This is a project that could be done "de facto" -- a bunch of
    people could just get together and Make It Happen.

    If you were *really* ambitious, you could try a "Unified" library of
    common routines -- code that already had all the system dependancies
    built in, in order to accomplish the required tasks that were beyond
    the facilities provided by Standard C, together with the infrastructure
    such as described above to detect and load in new versions.
    (Anything like that -might- perhaps best be done in terms of opaque
    types.) But you could probably bog yourself down just in deciding
    what to include and what the opaque interfaces should look like...
    --
    If you lie to the compiler, it will get its revenge. -- Henry Spencer
     
    Walter Roberson, Oct 19, 2006
    #4
  5. David Mathog

    Guest

    David Mathog wrote:
    > One thing that keeps coming up in this forum is that
    > standard C lacks many functions which are required in
    > a workstation or server but not possible in an embedded controller.
    > This results in a plethora of "don't ask here,
    > ask in comp.x.y instead",


    Yes, according to the regulars here, its the worst 99.99% of
    programmers that are making the remaining 0.01% look bad.

    > [...] for queries on functions that from the
    > documentation available to the programmer appear to be part
    > of the C language. I think largely because of this "least common
    > denominator" C language standard we have POSIX, XPG4, etc, which
    > add these useful and in many instances necessary pieces. And this
    > multiplicity of standards can be a real pain. I would really rather
    > write code that complies with _ONE_ language standard than write code
    > that has to comply with _MANY_ interrelated language standards.


    Unfortunately you are only addressing a real world problem that most
    programmers have issues with. This group only deals with non-problems
    having to do with the narrowest irrelevancies of the C language
    standard.

    > Just for the sake of argument, would it be so terribly wrong for the
    > ISO/ANSI C standard to define capabilities relevant for computers
    > other than dishwasher controllers?


    It would be worth it for them to at least consider *addressing* the
    problem in a well designed way. A good example of this is a library of
    my own making, "The Better String Library" ( http://bstring.sf.net/ ).
    It is a narrowly focussed library dealing with strings. However, it
    provides useful abstracted interfaces to IO, while still remaining
    fully ANSI. So if you have a platform specific IO stream, such as a
    socket or something like that, you just have to supply the very base
    primitives, and connect it up with the Better String Library, and you
    will be able to leverage all of the Bstrlib algorithms applied to your
    platform-specific IO. Its fairly straight forward and allows you to
    manage your portability issues as easily as possible.

    The problem is that the C language committee standards people are *not*
    serious programmers or designers. They don't know, they don't care,
    and they are not capable of thinking about these sorts of things. They
    would rather make C++ incompatible complex numbers (that totally
    ignores the possibility of making guassian integers) than truly generic
    interfaces that solve real world problems. They seem blissfully
    unaware that computers use graphical interfaces, that disks can hold
    files that can exceed 4GB in size (and in fact can be infinite in size
    (consider the output of "yes")), that buffered event sampling input
    interfaces are the norm, or that there is such a thing as the internet.
    There is at least one member of standards committee that is convinced
    that the Unicode standard is doomed to long term failure (though he was
    too chicken to take me up on a bet).

    > [...] For instance, if the language
    > required the compiler define for the target platform these constants as
    > 0 (not present) or 1 or higher (present, with number indicating various
    > future revision levels):
    >
    > ISOC_CAPABILITY_MULTIUSER
    > ISOC_CAPABILITY_NETWORK_IPV4
    > ISOC_CAPABILITY_NETWORK_IPV6
    > ISOC_CAPABILITY_FILELOCKING
    > ISOC_CAPABILITY_INTERPROCESS
    > etc.
    >
    > The code could test for these, and if present, utilize the relevant
    > supported functions. For instance, if MULTIUSER was defined then
    > some form of "getusername" would be supported.


    Well this would be useful for exposing primitives capabilities.
    Probably a better way of doing this would be to introduce namespaces
    into the C language, and then define functional interfaces within their
    own namespaces and then specify that the each of these namespaces would
    be optional.

    > Note that this is more or less what compilers do now, except that the
    > constants refer to POSIX, XPG4, etc, and it is not so much including by
    > capability, but including by language extension, with the latter rarely
    > clearly associated with the former. This results in insanely messy
    > compiler provided include files in which it is often painful to trace
    > through the logic to determine which combination of posix,xpg4,ansi etc
    > must be set at compile time to obtain the desired functions.


    Well here's the thing. If you don't buy into the namespace thing, or
    you (probably rightly) believe that there is no way that the ANSI C
    standard committee would go for it, then in fact, the ANSI C committee
    itself has very little to offer anyways.

    The credibility of the ANSI standard is at an all time low. With the
    introduction of C99 and its near universal defacto rejection, the
    committee no longer has real influence in what the programming
    community at large really does. In the latest fiasco, they have been
    taking advice from Microsoft on how to secure the language from Buffer
    Overflows. No you did not misread that (they probably buy anti-spam
    products from the random advertisements they receive in their email
    inboxes as well.) Going forward, nobody will pay attention to the ANSI
    C committee anymore. Their standards from here on in are basically
    dead letters. The only possible reader of the standard is, in fact,
    the C++ standards committee (which seems to be far more credible at
    this point.)

    If all you want to do is set up some macros and provide unified APIs,
    then probably the right answer is to do it yourself and try to
    popularize it yourself. You will have more adoption, and you will not
    have to try to fight the uphill battle of convincing the ANSI C
    committee of the value of your idea.

    Sound crazy? Here's another example:

    http://www.pobox.com/~qed/pstdint.h

    Its a substitute for C99's <stdint.h>. The difference is that you can
    plug it into *most* ANSI C89/90 C compilers. So I took one of the few
    truly valuable things in C99, extracted it, and have supplied a
    universal version that anyone can use without causing backward
    compatibility problems. See how that works? See how the ANSI C
    committee is entirely useless for serving the exact same purpose?

    > For those purists who work on embedded controllers the potential
    > availability of these extra functions should pose no problem whatsoever.
    > They are perfectly free NOT to use them. The cross compiler would
    > negate these constants so that any code that accidentally tried to
    > use a function not supported on the target platform would be flagged at
    > compile time.


    Right. But I think the point is that the ANSI C committee will be of
    no help to you here. You should try to start something yourself.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
     
    , Oct 20, 2006
    #5
  6. writes:
    [snip]
    > Sound crazy? Here's another example:
    >
    > http://www.pobox.com/~qed/pstdint.h
    >
    > Its a substitute for C99's <stdint.h>. The difference is that you can
    > plug it into *most* ANSI C89/90 C compilers. So I took one of the few
    > truly valuable things in C99, extracted it, and have supplied a
    > universal version that anyone can use without causing backward
    > compatibility problems.

    [snip]

    Doug Gwyn wrote something similar some time ago; see
    <http://www.lysator.liu.se/c/q8/index.html>.

    I haven't compared your <stdint.h> implementation with his.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Oct 20, 2006
    #6
  7. <> wrote in message
    news:...
    <snip>
    > http://www.pobox.com/~qed/pstdint.h
    >


    I've got a couple of questions, if you don't mind.

    First, why did you use the optional (and not fully portable) feature of
    space between '#' and the preprocessor directives?

    Second, I'm trying to decide how I want to release some code of mine: Public
    Domain (current preference...), or copyrighted and licensed: GPL, LGPL, MIT,
    my own, or some other. So far, I have input from my brother, who is an IP
    attorney, but doesn't specialize in copyright law. You chose a copyright
    and licensed model. How did you decide that? Do you have any intent to
    profit from your code? If not, why didn't you release under Public Domain,
    GPL/LPGL, MIT, etc?


    Rod Pemberton
     
    Rod Pemberton, Oct 21, 2006
    #7
  8. "Rod Pemberton" <> writes:
    > <> wrote in message
    > news:...
    > <snip>
    >> http://www.pobox.com/~qed/pstdint.h

    >
    > I've got a couple of questions, if you don't mind.
    >
    > First, why did you use the optional (and not fully portable) feature of
    > space between '#' and the preprocessor directives?


    How is that not fully portable? Any C90-conforming (or
    C99-conforming) compiler should accept preprocessor directives with or
    without whitespace before or after the '#' character. Do you know of
    a current compiler that doesn't allow this?

    [snip]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Oct 21, 2006
    #8
  9. David Mathog

    Guest

    Rod Pemberton wrote:
    > <> wrote:
    > <snip>
    > > http://www.pobox.com/~qed/pstdint.h

    >
    > I've got a couple of questions, if you don't mind.
    >
    > First, why did you use the optional (and not fully portable) feature of
    > space between '#' and the preprocessor directives?


    My target platforms are ANSI C compilers, not pre-cambrian compilers.
    I don't have a physical copy of any compiler that fails on the space
    after #, so I have no way to test it anyways. I also want to be able
    to reasonably maintain the code. Similarly, the include file assumes
    your machine is 2s complement, and doesn't support wierd stuff like 40
    bit or 36 bit integers.

    You are exactly the second person to ask me about this issue (the other
    person was using a compiler that clearly was not ANSI -- I told him to
    do the find and replace himself, since his platform was so marginal and
    since my maintenance was intended for the long term), so if you can
    identify a serious amount of development on a compiler that fails on
    this issue, I will take this criticism seriously. But for marginal
    environments, I imagine that those sorts of developers are already used
    to doing that kind of grunt work for all the open source they consume
    anyways.

    > Second, I'm trying to decide how I want to release some code of mine: Public
    > Domain (current preference...), or copyrighted and licensed: GPL, LGPL, MIT,
    > my own, or some other. So far, I have input from my brother, who is an IP
    > attorney, but doesn't specialize in copyright law. You chose a copyright
    > and licensed model. How did you decide that? Do you have any intent to
    > profit from your code? If not, why didn't you release under Public Domain,
    > GPL/LPGL, MIT, etc?


    The license is basically a no-slander and no use in SCO-like lawsuit
    license. It is usable in any BSD or GPL project, but without
    inheriting their additional licensing requirements. The same question
    could be applied to if you wanted to add public domain source code to
    an open source project. The PD source clearly does not gain the
    additional license restrictions. There are also GPL projects that
    refuse to incorporate BSD code, and vice versa, so picking one or the
    other doesn't make it universal.

    There are a few differences. One is that SCO becomes barred from using
    my source to launch a lawsuit, whereas, in the current lawsuit between
    SCO and IBM, the GPL is actually neutral. A second is that if MS
    wanted to take a GPL or BSD project, modify it so that it was
    functionally worse then repropogate it through their license then use
    it as an example in some rigged publication of why open source is worse
    than their software, for example, they could do so and nothing in those
    licenses would stop them. In both cases, the offending parties are
    unable to perform said action on my license.

    My license is otherwise fairly straight forward and easy to comply with
    -- in practice its kind of a more liberal BSD license. I have no
    profit motive.

    I am not a lawyer, and I find it kind of repugnant that lawyers need to
    be consulted just to engage in the practice of open source development.
    So I created a license that was stragically meant to cost people who
    use lawyers for evil purposes more money than those who merely wish to
    engage in the art.

    For the Better String Library license I was a bit torn. In that case I
    *WANT* Microsoft, SCO and whoever else wants to use my library. My
    feeling for a library like that was that going for altruism for ego
    compensation was the right answer. But this may have ended up
    alienating "GPL-only" projects, or Richard Stallman or Linus Torvalds,
    or whatever fanatics who don't like the BSD license. So I recently put
    it under dual license, GPL *and* BSD (you can choose either to use it
    under.) But this, of course is another issue.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
     
    , Oct 21, 2006
    #9
  10. <> wrote in message
    news:...
    > Rod Pemberton wrote:
    > > <> wrote:
    > > <snip>
    > > > http://www.pobox.com/~qed/pstdint.h

    > >
    > > I've got a couple of questions, if you don't mind.
    > >
    > > First, why did you use the optional (and not fully portable) feature of
    > > space between '#' and the preprocessor directives?

    >
    > My target platforms are ANSI C compilers, not pre-cambrian compilers.
    > I don't have a physical copy of any compiler that fails on the space
    > after #, so I have no way to test it anyways. I also want to be able
    > to reasonably maintain the code. Similarly, the include file assumes
    > your machine is 2s complement, and doesn't support wierd stuff like 40
    > bit or 36 bit integers.
    >
    > You are exactly the second person to ask me about this issue (the other
    > person was using a compiler that clearly was not ANSI -- I told him to
    > do the find and replace himself, since his platform was so marginal and
    > since my maintenance was intended for the long term), so if you can
    > identify a serious amount of development on a compiler that fails on
    > this issue, I will take this criticism seriously. But for marginal
    > environments, I imagine that those sorts of developers are already used
    > to doing that kind of grunt work for all the open source they consume
    > anyways.
    >


    No serious criticism. I haven't seen a modern compiler that doesn't accept
    it in about a decade, i.e., "pre-cambrian." I just find it a really awkward
    to read. Of course, there are still a number of "pre-cambrian" versions of
    C floating around out there, like some of the 32-bit ports of Small C...

    <snip>
    Thanks for the response on the copyright issues. Some food for thought.


    Rod Pemberton
     
    Rod Pemberton, Oct 21, 2006
    #10
  11. David Mathog

    CBFalconer Guest

    Keith Thompson wrote:
    > "Rod Pemberton" <> writes:
    >> <> wrote in message
    >>
    >> <snip>
    >>> http://www.pobox.com/~qed/pstdint.h

    >>
    >> I've got a couple of questions, if you don't mind.
    >>
    >> First, why did you use the optional (and not fully portable)
    >> feature of space between '#' and the preprocessor directives?

    >
    > How is that not fully portable? Any C90-conforming (or
    > C99-conforming) compiler should accept preprocessor directives
    > with or without whitespace before or after the '#' character.
    > Do you know of a current compiler that doesn't allow this?


    I do it all the time, to keep track of #if nesting, etc.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
     
    CBFalconer, Oct 21, 2006
    #11
  12. David Mathog

    CBFalconer Guest

    wrote:
    >

    .... snip ...
    >
    > I am not a lawyer, and I find it kind of repugnant that lawyers need to
    > be consulted just to engage in the practice of open source development.
    > So I created a license that was stragically meant to cost people who
    > use lawyers for evil purposes more money than those who merely wish to
    > engage in the art.
    >
    > For the Better String Library license I was a bit torn. In that case I
    > *WANT* Microsoft, SCO and whoever else wants to use my library. My
    > feeling for a library like that was that going for altruism for ego
    > compensation was the right answer. But this may have ended up
    > alienating "GPL-only" projects, or Richard Stallman or Linus Torvalds,
    > or whatever fanatics who don't like the BSD license. So I recently put
    > it under dual license, GPL *and* BSD (you can choose either to use it
    > under.) But this, of course is another issue.


    I usually release my software either under GPL or as public
    domain. Some things use the DJGPP license as an alternative. I
    also indicate willingness to negotiate other licenses.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
     
    CBFalconer, Oct 21, 2006
    #12
  13. David Mathog

    Guest

    Keith Thompson wrote:
    > writes:
    > [snip]
    > > Sound crazy? Here's another example:
    > >
    > > http://www.pobox.com/~qed/pstdint.h
    > >
    > > Its a substitute for C99's <stdint.h>. The difference is that you can
    > > plug it into *most* ANSI C89/90 C compilers. So I took one of the few
    > > truly valuable things in C99, extracted it, and have supplied a
    > > universal version that anyone can use without causing backward
    > > compatibility problems.

    > [snip]
    >
    > Doug Gwyn wrote something similar some time ago; see
    > <http://www.lysator.liu.se/c/q8/index.html>.
    >
    > I haven't compared your <stdint.h> implementation with his.


    His is meant for compiler vendors (its named stdint.h, whereas mine is
    named pstdint.h). He also covers different and seemingly fewer
    compilers than mine does out of the box (he supports some TI DSPs and
    an Apple IIgs compiler, but omits many x86 compilers, including all 16
    bit x86 C compilers). Furthermore, for future compilers that partially
    implement the C99 specification, pstdint.h will automatically just
    inherit that existing functionality. So Doug Gwyn's solution is more
    of an "exercise to the reader" kind of solution, while mine is closer
    to a drop in "it just works" kind of solution (obviously it is likely
    to fail on pre-C99 compilers that it was not designed for).

    So in source libraries, you can imagine that projects that want to use
    Doug Gwyn's solution would have to play makefile tricks that, depending
    on the platform and compiler vendor, would either include his stdint.h
    or not. And presumably the q8def.h file would be modified to include
    any new specific compilers and platforms the project supported. So its
    a bit of work just to get this one really useful feature from C99.

    In my case, the only thing that you would consider doing is including
    the pstdint.h file in place of stdint.h. That's it. If that doesn't
    work, then you modify pstdint.h until it does work (and hopefully you
    tell me about these modifications). Its one file, and it has no impact
    on project install modes etc. My file also goes slightly beyond C99,
    in that it does not assume that you have a long long data type. This
    is, of course, pretty important for older 16 bit compilers.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
     
    , Oct 21, 2006
    #13
  14. David Mathog

    Malcolm Guest

    "CBFalconer" <> wrote in message
    news:...
    > wrote:
    >>

    > ... snip ...
    >>
    >> I am not a lawyer, and I find it kind of repugnant that lawyers need to
    >> be consulted just to engage in the practice of open source development.
    >> So I created a license that was stragically meant to cost people who
    >> use lawyers for evil purposes more money than those who merely wish to
    >> engage in the art.
    >>
    >> For the Better String Library license I was a bit torn. In that case I
    >> *WANT* Microsoft, SCO and whoever else wants to use my library. My
    >> feeling for a library like that was that going for altruism for ego
    >> compensation was the right answer. But this may have ended up
    >> alienating "GPL-only" projects, or Richard Stallman or Linus Torvalds,
    >> or whatever fanatics who don't like the BSD license. So I recently put
    >> it under dual license, GPL *and* BSD (you can choose either to use it
    >> under.) But this, of course is another issue.

    >
    > I usually release my software either under GPL or as public
    > domain. Some things use the DJGPP license as an alternative. I
    > also indicate willingness to negotiate other licenses.
    >

    If I release code I just put it on my website.
    The exception was the BASIC interpreter, which is released as a book, so I
    had to specify that no one could try to restrict my rights in the code.
    You can download a free BASIC interpreter, an much more besides, on my
    website
    --
    www.personal.leeds.ac.uk/~bgy1mm
    freeware games to download.
     
    Malcolm, Oct 21, 2006
    #14
  15. David Mathog

    Malcolm Guest

    <> wrote in message
    > It would be worth it for them to at least consider *addressing* the
    > problem in a well designed way. A good example of this is a library of
    > my own making, "The Better String Library" ( http://bstring.sf.net/ ).
    > It is a narrowly focussed library dealing with strings. However, it
    > provides useful abstracted interfaces to IO, while still remaining
    > fully ANSI. So if you have a platform specific IO stream, such as a
    > socket or something like that, you just have to supply the very base
    > primitives, and connect it up with the Better String Library, and you
    > will be able to leverage all of the Bstrlib algorithms applied to your
    > platform-specific IO. Its fairly straight forward and allows you to
    > manage your portability issues as easily as possible.
    >

    Every man and his dog has released an better string library for C. I'm sure
    yours is very good. That's why you need standardisation. The problem with
    using your library is that it creates a dependency, and I want to keep
    dependencies out of my code if at all possible.
    If it was accepted as a general standard, then of course the situation would
    be different.
    >
    > Well this would be useful for exposing primitives capabilities.
    > Probably a better way of doing this would be to introduce namespaces
    > into the C language, and then define functional interfaces within their
    > own namespaces and then specify that the each of these namespaces would
    > be optional.
    >

    There should be some way of exporting symbols from a group of connected
    source files.
    >
    > The credibility of the ANSI standard is at an all time low. With the
    > introduction of C99 and its near universal defacto rejection, the
    > committee no longer has real influence in what the programming
    > community at large really does. In the latest fiasco, they have been
    > taking advice from Microsoft on how to secure the language from Buffer
    > Overflows. No you did not misread that (they probably buy anti-spam
    > products from the random advertisements they receive in their email
    > inboxes as well.) Going forward, nobody will pay attention to the ANSI
    > C committee anymore. Their standards from here on in are basically
    > dead letters. The only possible reader of the standard is, in fact,
    > the C++ standards committee (which seems to be far more credible at
    > this point.)
    >

    Committees are generally a big mistake. For some reason humans always perfer
    to take decisions in committee - the British government runs that way,
    almost every big company has a board, so does every little club. The only
    big institution that doesn't have a standing committee is the Catholic
    Church.
    C++ is in a worse state than C. It is generally acknowledged that the
    language has got too big, and encourages bad programming practises. However
    there doesn't seem to be any way out. I stopped using C++ a few years ago. I
    am actually using Fortran 77 for a lot of my code.
    --
    www.personal.leeds.ac.uk/~bgy1mm
    freeware games to download.
     
    Malcolm, Oct 21, 2006
    #15
  16. David Mathog

    Guest

    Malcolm wrote:
    > <> wrote in message
    > > It would be worth it for them to at least consider *addressing* the
    > > problem in a well designed way. A good example of this is a library of
    > > my own making, "The Better String Library" ( http://bstring.sf.net/ ).
    > > It is a narrowly focussed library dealing with strings. However, it
    > > provides useful abstracted interfaces to IO, while still remaining
    > > fully ANSI. So if you have a platform specific IO stream, such as a
    > > socket or something like that, you just have to supply the very base
    > > primitives, and connect it up with the Better String Library, and you
    > > will be able to leverage all of the Bstrlib algorithms applied to your
    > > platform-specific IO. Its fairly straight forward and allows you to
    > > manage your portability issues as easily as possible.

    >
    > Every man and his dog has released an better string library for C. I'm sure
    > yours is very good. That's why you need standardisation. The problem with
    > using your library is that it creates a dependency, and I want to keep
    > dependencies out of my code if at all possible.


    But its an open source module. I.e., its a dependency in exactly the
    same way that any other module in your projects are dependencies for
    each other. You don't *have* to rely on me to maintain the code, and
    you don't *have* to follow the latest releases. I.e., you only turn it
    into a real dependency if you consciously rely on my on going
    maintenance and commit to always using the latest version. The truth
    is that basically nobody does that. Everyone just takes whatever
    version is available at the time.

    >From a functionality point of view, the Better String Library

    integrates very well with the standard char * kind of strings. So the
    library does not put you in an "either or" situation. If you have some
    algorithm that relies on char * semantics even though some usage fits
    the better string library semantics, there is no problem with just
    mixing the two.

    So I don't think saying that the Better String Library is introducing a
    "dependency" is a fair way of describing it.

    > If it was accepted as a general standard, then of course the situation would
    > be different.


    Yes, it would give compiler vendors the option of closing the source in
    their implementations of it. Unlike the entire C library, the Better
    String Library asserts a "security statement" as called for by former
    terrorism czar and secure information technology advocate Richard
    Clarke. So a corporation that is concerned about the security of their
    software can reference the included statement which will allow them to
    fully audit their code or my code. But if the problem turns out to be
    a bug in the C library for their compiler, they don't have a well
    defined way of dealing with that.

    Worse yet, we have seen the compiler vendor's reaction to the recent
    standardization process. There is barely any adoption of C99; at best
    there is partial adoption that has basically lead to non-standard
    compilers. So developers are hostage to the compiler vendors who have
    all basically balked at the evolution of the C standard. Compare this
    with the situation with the Better String Library, where they can
    download it at their option, and expect it to behave substantially
    identically on any compilers they use it on.

    While in theory the standardization process encourages universal
    language implementations, we can see that in practice 1) this no longer
    really happens, and 2) this can have disadvantages even when followed.

    > > Well this would be useful for exposing primitives capabilities.
    > > Probably a better way of doing this would be to introduce namespaces
    > > into the C language, and then define functional interfaces within their
    > > own namespaces and then specify that the each of these namespaces would
    > > be optional.

    >
    > There should be some way of exporting symbols from a group of connected
    > source files.


    You mean like a namespace.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
     
    , Oct 21, 2006
    #16
  17. David Mathog

    Malcolm Guest

    <> wrote in message
    news:...
    > Malcolm wrote:
    >> <> wrote in message
    >> > It would be worth it for them to at least consider *addressing* the
    >> > problem in a well designed way. A good example of this is a library of
    >> > my own making, "The Better String Library" ( http://bstring.sf.net/ ).
    >> > It is a narrowly focussed library dealing with strings. However, it
    >> > provides useful abstracted interfaces to IO, while still remaining
    >> > fully ANSI. So if you have a platform specific IO stream, such as a
    >> > socket or something like that, you just have to supply the very base
    >> > primitives, and connect it up with the Better String Library, and you
    >> > will be able to leverage all of the Bstrlib algorithms applied to your
    >> > platform-specific IO. Its fairly straight forward and allows you to
    >> > manage your portability issues as easily as possible.

    >>
    >> Every man and his dog has released an better string library for C. I'm
    >> sure
    >> yours is very good. That's why you need standardisation. The problem with
    >> using your library is that it creates a dependency, and I want to keep
    >> dependencies out of my code if at all possible.

    >
    > But its an open source module. I.e., its a dependency in exactly the
    > same way that any other module in your projects are dependencies for
    > each other. You don't *have* to rely on me to maintain the code, and
    > you don't *have* to follow the latest releases. I.e., you only turn it
    > into a real dependency if you consciously rely on my on going
    > maintenance and commit to always using the latest version. The truth
    > is that basically nobody does that. Everyone just takes whatever
    > version is available at the time.
    >

    Well I'm writing a module that does a few trivial manipulations on file
    names. So I'll include your string library.
    Oliver, my colleague, is outputting files in PDB format, and also wants a
    few string manipulations. So he uses Fred's super string library.
    Suddenly we've got all these string libraries sloshing about our code,
    making it hard to read, and making it hard to call one module from another.

    That's the problem with dependencies.
    --
    www.personal.leeds.ac.uk/~bgy1mm
    freeware games to download.
     
    Malcolm, Oct 21, 2006
    #17
  18. David Mathog

    Guest

    Malcolm wrote:
    > <> wrote:
    > > Malcolm wrote:
    > >> <> wrote:
    > >> > It would be worth it for them to at least consider *addressing* the
    > >> > problem in a well designed way. A good example of this is a library of
    > >> > my own making, "The Better String Library" ( http://bstring.sf.net/ ).
    > >> > It is a narrowly focussed library dealing with strings. However, it
    > >> > provides useful abstracted interfaces to IO, while still remaining
    > >> > fully ANSI. So if you have a platform specific IO stream, such as a
    > >> > socket or something like that, you just have to supply the very base
    > >> > primitives, and connect it up with the Better String Library, and you
    > >> > will be able to leverage all of the Bstrlib algorithms applied to your
    > >> > platform-specific IO. Its fairly straight forward and allows you to
    > >> > manage your portability issues as easily as possible.
    > >>
    > >> Every man and his dog has released an better string library for C. I'm
    > >> sure
    > >> yours is very good. That's why you need standardisation. The problem with
    > >> using your library is that it creates a dependency, and I want to keep
    > >> dependencies out of my code if at all possible.

    > >
    > > But its an open source module. I.e., its a dependency in exactly the
    > > same way that any other module in your projects are dependencies for
    > > each other. You don't *have* to rely on me to maintain the code, and
    > > you don't *have* to follow the latest releases. I.e., you only turn it
    > > into a real dependency if you consciously rely on my on going
    > > maintenance and commit to always using the latest version. The truth
    > > is that basically nobody does that. Everyone just takes whatever
    > > version is available at the time.

    >
    > Well I'm writing a module that does a few trivial manipulations on file
    > names. So I'll include your string library.
    > Oliver, my colleague, is outputting files in PDB format, and also wants a
    > few string manipulations. So he uses Fred's super string library.


    What the hell is "Fred's super string library"?

    > Suddenly we've got all these string libraries sloshing about our code,
    > making it hard to read, and making it hard to call one module from another.


    Well, as I said, the Better String Library integrates fairly well with
    old char * code, so API interfaces should be easily dealt with. I.e.,
    for external interfaces you don't need to *require* that people use
    bstring's or CBString's -- you can just use them internally to each
    module, and use char *s for the API calls.

    You can even treat bstring's, most of the time, as if they were just
    wrapped char * strings. So if this "Fred's super string library" can
    accept const char *'s for input, then you can pass it bstring data
    directly, by just dereferencing the ->data member.

    I did put some consideration for this into Bstrlib. So if you're
    having integration problems with other string libraries then I would
    suggest that perhaps you look to see if there is a problem with the
    other string libraries.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
     
    , Oct 21, 2006
    #18
  19. David Mathog

    CBFalconer Guest

    wrote:
    >

    .... snip ...
    >
    > Worse yet, we have seen the compiler vendor's reaction to the
    > recent standardization process. There is barely any adoption of
    > C99; at best there is partial adoption that has basically lead to
    > non-standard compilers. So developers are hostage to the compiler
    > vendors who have all basically balked at the evolution of the C
    > standard. Compare this with the situation with the Better String
    > Library, where they can download it at their option, and expect it
    > to behave substantially identically on any compilers they use it on.


    So why don't you join the GNU gcc team and get it in shape? The
    source is available, as is glibc. Once you have done that the
    other compiler vendors will probably fall in line.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
     
    CBFalconer, Oct 21, 2006
    #19
  20. David Mathog

    CBFalconer Guest

    wrote:
    > Malcolm wrote:
    >

    .... snip ...
    >>
    >> Well I'm writing a module that does a few trivial manipulations
    >> on file names. So I'll include your string library. Oliver, my
    >> colleague, is outputting files in PDB format, and also wants a
    >> few string manipulations. So he uses Fred's super string library.

    >
    > What the hell is "Fred's super string library"?


    The one that Fred wrote, available at:

    <http://fredstuff.foo>

    Oliver likes it. Malcolm doesn't. :=)

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
     
    CBFalconer, Oct 21, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    4
    Views:
    336
    Andrew Thompson
    Jan 8, 2005
  2. Steven T. Hatton

    Least Common Denominator Feature Set

    Steven T. Hatton, Jun 8, 2004, in forum: C++
    Replies:
    5
    Views:
    413
    Steven T. Hatton
    Jun 9, 2004
  3. John Salerno
    Replies:
    25
    Views:
    693
    bruno at modulix
    May 17, 2006
  4. AAaron123
    Replies:
    0
    Views:
    604
    AAaron123
    Oct 3, 2008
  5. Steven D'Aprano
    Replies:
    5
    Views:
    93
    Tim Delaney
    Aug 24, 2013
Loading...

Share This Page