Re: Two Questions about "strlen", "strcat" and "strcpy"

From: Paul Hsieh (qed_at_pobox.com)
Date: 08/31/04 

Date: Tue, 31 Aug 2004 13:03:16 GMT

jacob@jacob.remcomp.fr says...
> Paul Hsieh wrote:
> > > Important is that we have in the standard language a way of using
> > > length prefixed strings in the same way as now we have zero terminated
> > > strings.
> >
> > No. zero terminated strings is the whole problem in the first place.
> > This is where both buffer overflows and retrograde performance comes
> > from. The whole CLIB style of '\0' terminated strings forces the
> > programmer to think in terms of implementation and constantly respin
> > solutions to common problems. Every other modern language in
> > existence basically solves lets the programmer think about strings
> > just as strings. So what we want is something closer to how other
> > programming languages deal with strings (like Python, Perl, Java,
> > Pascal, etc), while supersetting the CLIB char * nonsense. Guess what
> > -- bstrlib *does* this.
>
> By giving the programmer the choice of zero terminated strings
> OR length prefixed strings the language would retain compatibility
> and at the same time allow the development of more robust
> applications.

Bstrlib is directly compatible with '\0' terminated strings (it implicitely
concatenates '\0's automatically.) Bstrlib doesn't make it an either or choice
-- it supports both *simultaneously* while internally only using the length
based mechanism (since its faster, safer and more functional.) Bstrlib is a
*NO COMPROMISE* solution -- its truly portable, totally compatible with char *,
it outperforms everything (except Vstr), its safer than everything, and its
more functional than everything (except for missing Unicode support). Go
download it and study it. You're not going to be able to just poke holes in it
especially if you don't actually get it and understand how it works.

> > > Operator overloading makes possible to write such libraries without
> > > too much pain.
> >
> > Ok, this is a different thing, and it solves a different problem.
> > This is basically a focus on syntactical concerns more than anything
> > else [...]
>
> [...] but syntax sugar *is* important to easy the usage of the new data
> type. If not, we would all program on assembler.

We have C++ for this. (Fortunately Bstrlib has a C++ API for people who want
this!)

> > As I have posted before, it would make more sense if there were
> > *additional* operators (using multipler operator characters and some
> > previously unused characters such as @, $ to create things that look
> > like: @+, $*, @==, $^^, etc) that basically had empty definitions
> > unless actually defined. There are other operator overloading things
> > such as:
> >
> > X"..."
> > "..."X
> > 3.75X
> >
> > Where the X could be other letters. This gives programmers a way of
> > using operator overloading without suffering from the confusion of
> > using previous operators that someone reading the code can easily
> > mistake for having different semantics from what they think. See?
> > Its still explicit (something C is useful for) while providing for
> > more modern functionality.
>
> This is quite correct Paul. But I have an incredible difficult time
> trying to convince people about the need of evolution in C, and by the
> other answers in this thread you can immediately see that the
> conservative mood (innovation is off topic here) prevents any discussion
> about improvements like the one you propose. I wanted to use greek
> letters for new operators like
> SIGMA j=1,inf (expression in j)

Look -- its because you are not thinking in the right terms. If you extend the
language in which it is *CLEAR* that you have truly made forward progress that
is not easily duplicated with the old standard then it will foster interest.
Using greek letters in the source code -- that's just going to create more
problems for source analysis tools and text editors.

Adding an infinite number of operators (via a grammar of operators) that can
all be defined arbitrarily -- now *THAT* would be innovation. It would deliver
something that mathematicians would be really interested in -- add *more*
operators on top of an ordinary mathematical system than can be accommodated by
just the ones available by the default language. And you don't see anything
comparable in other languages.

Just adding operator overloading alone? Nobody is going to care -- C++ already
does this. There's barely a person anywhere who has access to a C compiler
that isn't also capable of C++.

You want your audience to be captivated with the thought that they can *ONLY*
accoplish certain programming tasks in your language. There's so much room
left in C language unexplored and unaddressed.
 
> The standards comitee refuses any change, since change should not exist
> in C. Change and improvements are only allowed in C++. The comitee
> has refused until now to correct even ouright *bugs* like the buffer
> overflow specified in the asctime function. I pointed to that bug, and
> was told that the comitee rejected any correction in 2001.

You don't get it. The C standards committee is dead. They committed suicide
with the C99 standard. Even if they *were* to listen to you or me, it would
not matter. They will not issue any more C standards -- they *CAN'T*. Since
C99 has been such an abysmal failure, they have nothing to build upon anymore -
- their credbility is completely gone. That *DEFACTO* standard is no longer in
their hands. Its in *YOURS*.

Its over for them. The future of C can *ONLY* come from people like you. This
is why I am so frustrated that you (and Walter, the D guy) are not leveraging
this opportunity correctly.

> > Jacob, people like you and the guy that is making "D" (Walter B---?)
> > make me sad. You are both seem overly concerned with such
> > ridiculously superficial aspects of the language -- yet both of you
> > two are the only ones putting your money where your mouth is and
> > converting your capability to make *compilers* to demonstrate the
> > possibility of evolution of C. Yet you haven't figured out that you
> > haven't sold your ideas to any significant population of programmers.
>
> I spoke with Walter about D. He has overall good ideas, and his
> language/compiler *is* an improvement. The problem with it is that is
> object oriented, i.e. it provides support for a specific way of
> organizing data. I think that C should be paradigm neutral, without
> forcing *any* preconceived schema into the user's throat.

Monolithic ivory towers ... who uses D?
 
> > There are ideas in programming languages, especially the C-class of
> > programming langauges that I *desperately* want to see:
> >
> > 1. A preprocessor with "Turing complete" (or close enough) power.
> > The point is that the LISP people continue to laugh at C
> > programmers who have no code generation or "lambda"
> > programming ability.
>
> Can you give an example?
> You mean anonymous code blocks?

I mean integers, arithmetic and control structures that execute at the
*PREPROCESSOR* level. Masm has had this since its inception and its a very
powerful technique for building massive amounts of code or tables based on any
sort of algorithm you like. Something like this for example:
 
#define glue3(x,y,z) x ## y ## z
#TEXTEQUATE FNLIST =
#FOR IDX0 in (0,1,2,3,4)
# FOR IDX1 in #RANGE(0,3)
void glue3(output,IDX0,IDX1) (void) {
    printf (#IDX0 #IDX1 "\n");
}
# IF #LENGTH(FNLIST) > 0
# TEXTEQUATE FNLIST = FNLIST ,
# ENDIF
# TEXTEQUATE FNLIST = FNLIST glue3(output,IDX0,IDX1)
# ENDFOR
#ENDFOR
void (*fns[5][4])(void) = { FNLIST };

> > a) Compile time type assertions to allow for type safe macros.
>
> typeof() ?

Yeah. You need this to go with the functionality I am talking about above.
But really you only need something like assertTypeEqual(*,*) or
assertTypeCompatible(*,*) something like that.
 
> > 2. Exposing more important hardware functions such as a widening
> > multiply, bit scan and bit count operations. Many CPUs have
> > instructions for accelerating these operations, and its
> > otherwise fairly straightforward to simulate these operations.
>
> Lcc-win32 introduces intrinsics like _overflow(), MMX intrinsics, etc.

And what use are these MMX intrinsics to compilers for the PowerPC or ARM or
Alpha processors? I'm not talking about esoteric functions that are very CPU
specific. I am talking about mechanisms that clearly the majority of modern
processors have decided to implement. Remember you are trying to establish a
*STANDARD*, not just an implementation.

The Intel C compiler's vector-loop detection mechanism is probably the best way
to incorporate SIMD instruction sets -- not exposing instrinsics (which is not
really any better than assembly.)
 
> > a) Include things like round() and trunc() as seperate
> > functions.
>
> They are separate functions now in C99.

I was unaware of this.
 
> > 3. For more powerful and useful C library.
> > a) Fix all the stupid problems like strtok(), gets(), etc.
>
> I have been saying this since quite a long time but nobody wants to
> change anything.

Gcc has added strtok_r() and has a link time warning for use of gets(). I
wouldn't say that nobody wants to change anything -- its just that the
standards committee have their heads up their asses and has put far more weight
into the concerns of compiler vendors (who don't want customer support calls
wondering why they don't support gets() anymore) over the needs of actual
developers (who will benefit in the long run, if they are forced to not use
these stupid functions.)
 
> > b) More powerful heap API (freeall(), memsize(), sub-heaps,
> > totalAllocCount(), allAllocsIterate() etc).
>
> Ditto.

I have working code for all of this -- the kind of difference it makes cannot
be underscored. Leaks and memory corruptions are tracked down far more
effectively -- and the performance gain of performing freeall()'s is pretty
incredible for some applications.

> > 7. Create an API for making "virtual file" objects. I.e., memory
> > files, network streams, algorithmic fractal strings, etc. could
> > be fopen(*,"r")'ed, fread()'ed, etc.
>
> This things should be done in a library. A low level language can be
> improved with powerful libraries.

No. Some modules/libraries have been precanned to use FILE I/O as their only
interface (the official JPEG source library comes to mind.) I don't *WANT* to
change the JPEG library code -- I want to change the behaviour of file
functions underneath it, so I can feed it JPEG data from sources other than
files without changing any of their code (I don't want to maintain changes from
having hacked in everwhere where they have used a file function as the JPEG
group updates their code).
 
> > Think about it. This list is a set of *REAL* programming language
> > improvements, that are not really duplicated by any other language
> > (well ok, except for CPP improvements, which are duplicated with LISP
> > lambdas and MASM's preprocessor, of m4 or whatever). If you add these
> > things I don't see how anyone could *deny* that you were moving the
> > language forward in a significant way without just trying to be "me
> > too" with other languages.
>
> Well "me too" is not intrinsically bad. Better to improve C than leave
> it as it is now.

C++ already does this. Look, small incremental changes to languages have
always been rejected by the programming community. This is why Scheme has no
more adoption than Lisp, its why Objective-C never really took off, that's why
nobody cares about C99.
 
> C is becoming obsolete, as FORTRAN did. Of course there are still places
> where FORTRAN is good today, and it is still used.

Yes, thanks to the C standards committee! Look, we all have the C89 standard,
and compiler vendors aren't really moving from it. The C standard committee
has had nothing to offer us even with the myriad of remaining problems that are
in the language. Under the current standard, yes, C *will* become the next
COBOL. For the simple reason that no effort is being made to revitalize it.

The one advantage the C std committee has over you (and Walter) is that they
*DISCUSSED* the proposed changes in a large group (with their retrograde
adgenda). The C++ committee, of course, has the same advantage. If you simply
stay in your cubbyhole making your own changes to LCC-Win32, you're not going
to get widespread acceptance of what you are doing. In the end your only
customer will be yourself. You need to put together an "innovators committee"
of your own. Do it and drive the final nail in the coffin of the C std
committee. Don't do it and we might as well write the eulogy for the C
language itself. 

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

Relevant Pages

  • Re: Language standard: the least common denominator vs. utility
    ... Probably a better way of doing this would be to introduce namespaces ... The credibility of the ANSI standard is at an all time low. ... taking advice from Microsoft on how to secure the language from Buffer ... C committee anymore. ...
    (comp.lang.c)
  • Re: On the development of C
    ... With the development of the c++ language, ... The first standard went beyond standardization of existing practice, ... the committee, Mr Gwyn answered: ... The "C strings" are represented by a sequences of characters in memory ...
    (comp.lang.c)
  • Progress on C++0x
    ... committee decision to really aim for a new standard this decade, ... The current status list for progress pm core language feature can be ... C++ standard will support garbage collection! ... THe only major feature adopted into the working paper at this meeting ...
    (borland.public.delphi.non-technical)
  • Re: On the development of C
    ... With the development of the c++ language, ... The first standard went beyond standardization of existing practice, ... the committee, Mr Gwyn answered: ... The "C strings" are represented by a sequences of characters in memory ...
    (comp.lang.c)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)