Re: Two Questions about "strlen", "strcat" and "strcpy"
From: jacob navia (jacob_at_jacob.remcomp.fr)
Date: 08/31/04
- Next message: thomas.christmann_at_online.de: "Re: Problem with passing dynamic arrays by reference"
- Previous message: Alef T Veld: "bitwise subnetscanning?"
- In reply to: Paul Hsieh: "Re: Two Questions about "strlen", "strcat" and "strcpy""
- Next in thread: Paul Hsieh: "Re: Two Questions about "strlen", "strcat" and "strcpy""
- Reply: Paul Hsieh: "Re: Two Questions about "strlen", "strcat" and "strcpy""
- Reply: beliavsky_at_aol.com: "Re: Two Questions about "strlen", "strcat" and "strcpy""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 31 Aug 2004 12:37:39 +0200
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.
>
>>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 -- and its not a very good solution to it either. The set of
> operators available are dictated by the syntax/considerations for
> arithmetic on scalars. For example if you want a comprehensive vector
> library, which operator are you proposing to assign for cross-product,
> dot-product, SIMD-product, tensor and trace, while retaining sum and
> difference? Ask for enough operations and you will eventually just
> run out of operators.
1: Overloading the [] operator makes it possible to design container
objects that add semantics to object access. Strings can be implemented
that use the [] indexing operator to bounds check the access, and to
implement length delimited strings. Above all, instead of hard wiring
length prefixed strings into the compiler it allows the user to define
string libraries that use this feature.
2: Overloading the assignment operator allows the user to write:
String S1 = "abc";
using the usual semantics. Yes This *is* syntatic sugar since the user
could write:
String S1 = new_string("abc");
but syntax sugar *is* important to easy the usage of the new data
type. If not, we would all program on assembler.
>
> 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)
> The C standards people have the opportunity to truly move the language
> forward, and in fact get a small leg up over other languages if they
> would consider things like this. But they are clearly such
> retrograde, short-sighted and as we now see from the C99 debacle, now
> ultimately ineffective. The standards committee is stuck in their old
> "we have to make sure the VAX people, the embedded people, the super
> computer people, the DOS people and the UNIX people can all adopt our
> standard while actually doing completely different things in their
> compiler" mantra.
>
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.
> The computing universe has changed. People don't want just the minor
> silly things in C99 over C89. C still represents the lowest level
> language, but there still remain several real problems not solved in
> the language.
>
The standards comitee is convinced that all development should be only
in C++. There isn't even a public forum where innovation can be
presented and discussed. The comp.lang.c group discusses only important
questions like the eternal:
I wrote i++ = i++ and it doesn't work...
> 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.
> 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?
> a) Compile time type assertions to allow for type safe macros.
typeof() ?
> 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.
> a) Include things like round() and trunc() as seperate
> functions.
They are separate functions now in C99.
> 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.
> b) More powerful heap API (freeall(), memsize(), sub-heaps,
> totalAllocCount(), allAllocsIterate() etc).
Ditto.
> 4. Some way of performing a restartable vsnprintf (), or
> generally va_* reuse (according to the standard, not the
> implementation).
> 5. Real co-routines -- none of this setjmp/longjmp nonsense.
> 6. A scope specific "goto case ____". This kind of functionality
> is *mandatory* for implementing fast state machines. Today
> programmers are either forced to have redundant case ____ and
> labels that are not scope protected or they do is the slow way
> (while wrapped switch statement). Think about it -- there is
> literally *NO* programming language with control mechanisms
> that perfectly match the very common programming idiom of
> state machines (except assembly language!)
> 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.
> 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 is becoming obsolete, as FORTRAN did. Of course there are still places
where FORTRAN is good today, and it is still used.
C will go the same road. Nobody will want to program new software in it,
like now in FORTRAN. (Yes there are still some applications being
developed in FORTRAN, and yes, there will be always some people that
will develop in C. But the mainstream of programming will forget C)
This future is not inevitable, but by refusing innovation, this group
contributes a lot to make it real.
I have never seen a newsgroup about a programming language where you can
write:
"Innovation is off topic here as you should know by now"
and get away with it.
jacob
- Next message: thomas.christmann_at_online.de: "Re: Problem with passing dynamic arrays by reference"
- Previous message: Alef T Veld: "bitwise subnetscanning?"
- In reply to: Paul Hsieh: "Re: Two Questions about "strlen", "strcat" and "strcpy""
- Next in thread: Paul Hsieh: "Re: Two Questions about "strlen", "strcat" and "strcpy""
- Reply: Paul Hsieh: "Re: Two Questions about "strlen", "strcat" and "strcpy""
- Reply: beliavsky_at_aol.com: "Re: Two Questions about "strlen", "strcat" and "strcpy""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
