Language standard: the least common denominator vs. utility

[David Mathog]

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

[Clever Monkey]

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.

[Chris Torek]

In article <eh**********@naig.caltech.edu>
David Mathog <ma****@caltech.eduwrote:

>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) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Walter Roberson]

In article <eh**********@naig.caltech.edu>,
David Mathog <ma****@caltech.eduwrote:

>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

[websnarf]

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/

[Keith Thompson]

we******@gmail.com 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.himplementation with his.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[Rod Pemberton]

<we******@gmail.comwrote in message
news:11*********************@i3g2000cwc.googlegrou ps.com...
<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

[Keith Thompson]

"Rod Pemberton" <do*********@bitfoad.cmmwrites:

<we******@gmail.comwrote in message
news:11*********************@i3g2000cwc.googlegrou ps.com...
<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) ks***@mib.org <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.

[websnarf]

Rod Pemberton wrote:

<we******@gmail.comwrote:
<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/

[Rod Pemberton]

<we******@gmail.comwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...

Rod Pemberton wrote:

<we******@gmail.comwrote:
<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

[websnarf]

Keith Thompson wrote:

we******@gmail.com 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.himplementation 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/

[CBFalconer]

Keith Thompson wrote:

"Rod Pemberton" <do*********@bitfoad.cmmwrites:

><we******@gmail.comwrote 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]

we******@gmail.com 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>

[Malcolm]

"CBFalconer" <cb********@yahoo.comwrote in message
news:45***************@yahoo.com...

we******@gmail.com 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]

<we******@gmail.comwrote 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.

[websnarf]

Malcolm wrote:

<we******@gmail.comwrote 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/

[Malcolm]

<we******@gmail.comwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...

Malcolm wrote:

><we******@gmail.comwrote 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.

[websnarf]

Malcolm wrote:

<we******@gmail.comwrote:

Malcolm wrote:

<we******@gmail.comwrote:
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/

[CBFalconer]

we******@gmail.com 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]

we******@gmail.com 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>

[websnarf]

CBFalconer wrote:

we******@gmail.com 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?

Because I don't want or need the vast majority of C99 features? I have
my own solution to the stdint.h problem, and the gcc people have
already dealt with that in their compiler. Helping someone to
implement C99 would be serving *someone else's* adgenda, not mine.

[...] The
source is available, as is glibc. Once you have done that the
other compiler vendors will probably fall in line.

I rather doubt that. With no user demand at all, the fact the gcc
happens to support it would not suddenly create this demand. (For
example, gcc supports locally scoped functions, but nobody uses them.)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[CBFalconer]

we******@gmail.com wrote:

>

.... snip ...

>
I rather doubt that. With no user demand at all, the fact the gcc
happens to support it would not suddenly create this demand. (For
example, gcc supports locally scoped functions, but nobody uses them.)

GPC does. Probably Ada too. There goes your 'nobody' claim.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[James Antill]

On Sat, 21 Oct 2006 18:27:05 +0100, Malcolm wrote:

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.

I don't understand your argument. With std. C-strings at least
allocation, deallocation[1], copying[2], concatenation[3], parsing[4] and
IO formatting[5] are all prone to being done in a variety of ways. Calling
conventions on who owns what when are totally up in the air (and if you
need to "share" a string between multiple places it's often so
complicated it's easier to just strdup() and assume it's not going to
change).
Using any decent string API has to unify the first 4 problems, and likely
at least helps with the others.

In fact, in my experience, to counter those and the general
security/usability problems of C-strings the better programmers tend to
implement some form of string API within their application. So the real
argument is "dep. on an external and well tested API" vs. "dep. on an
internal API".

I would be very surprised if lack of integration was a real problem for
using any of the worthwhile string libraries.

Also there just aren't that many worthwhile string libraries out there
(and there are even fewer designs behind them), so even if you did use
more than 1 it'd be very hard to get above 2 without their being major
overlap.
[1] Do you malloc(), or use fixed size buffers. To you grow the buffer, or
work out the length and allocate once. Where do you keep the meta data etc.

[2] strcpy(), strncpy(), memcpy(), memmove(), sprintf(), etc.

[3] Dito [2].

[4] Do you destroy the string via. strtok(), do you use sscanf(), do you
strspn/strcspn and memcpy the sub-strings out somewhere else.

[5] Do you split your IO to just have a pointer and length,
doing any formatting via. snprintf() (non-std. call) somewhere
else ... or use something that looks like fprintf() so you can easily
concatenate multiple strings into the output without having to do even
more allocations.

--
James Antill -- ja***@and.org
http://www.and.org/and-httpd/ -- $2,000 security guarantee
http://www.and.org/vstr/