Re: C scripting (continued)
- From: jt@xxxxxxxxxxx (Jens Thoms Toerring)
- Date: 1 Apr 2009 16:21:13 GMT
In article <49d32bce$0$2742$ba4acef3@xxxxxxxxxxxxxx> you wrote:
Jens Thoms Toerring wrote:
jacob navia <jacob@xxxxxxxxxx> wrote:
The main complaints about the version of a C script I presented in this
forum were:
(1) Limited buffers could overflow
(2) Security issues concerning specially crafted file names
Those issues were not at all any problem in the environment where this
script was used but from a more general perspective they could be an
issue.
You post a revised version of a program that takes about
100 lines of C code to a) compilee, b) link and c) run the
C programs in a certain directory.
d) Gather statistics about what parts of those process failed
e) print them
And, as has been pointed
out, there are still some issues with the program.
No, there is just a transcript error from the program
to the post. That's all . NO issues were raised.
Ok, I had make four changes to get it to compile on my
(Linux) machine (with a few warnings remaining), and I
couldn't easily distinguisg between "transcript errors"
and "issues". But that we should be bothered about.
?So I am
wondering is what you actually want to prove with this?
That a program that takes just 5072 bytes of executable size
I can do the same thing that in other scripting languages with the
same style of security.
Having small programs is nice, definitely. And that you
can do the same things in C you can do in a scripting lan-
guages is, I think, uncontentious (especially since many
scripting languages are actually based on C). It just
doesn't convince me that C is very useful for scripting
since IMHO there are other priorities than just code size.
I could come up with less then 10 lines of a Makefile or
similar number of limes of a Perl or bash script to do
more or less the same,
rather less since it would be surprising that Makefiles
gather statistics about which things failed
:-)
Right, though I would prefer the direct output of make any
time since it shows what went wrong and not just how many
times something went wrong;-)
and I am rather sure many of the
other "regulars" could do the same (or they rather might
know an even more concise way to do it). So it's no a
very convincing example of why one should write scripts
in C.
For you. Your opinion. My opinion differs.
That's right, it's definitely my opinion.
If you want to write everything in C (and I don't blame you,
I like C and also write a lot of stuff in C, but not every-
thing) that's fine with me. What I don't understand is why
you seem to see C as the one and only "true way" of writing
programs.
What I like in C is precisely this minimalist approach that simplifies
software construction and allows to produce powerful and small programs.
In this days of trying to make of everything a monster program that
takes megabytes to run it is refreshing to see a standalone
program that takes just 5K.
As I said, small code size is nice. But when writing a script
that's actually rather low on my priority list. What's high on
my list is get the job done as fast as possible and with the
least hassle. And many scripting languages simply make a lot
of things simpler. I don't know what you think about tools
like awk or sed etc. All you can do with them you can also
write in C, but it would seem to me to be a huge PITA doing
that compared to just writing one or a few more lines in e.g.
awk to get a job done. And with e.g. Perl I can do basically
everything I could do in awk, just with a lot of other nice
things thrown in. If it takes a megabyte more doesn't bother
me much.
C is, at least to me, a nice. small and often ele-
gant language, but, alas, at times bogged down with histo-
rical decisions that can't be easily undone and simply have
to be accepted. It's very useful for a lot of things I do
(especially if speed is an issue or you have to write e.g.
libraries or device drivers). But there are things that
are too time-consuming and complicated to write in C and then,
if possible, I tend to write that in a different language.
Your choice.
Yes, of course. But I thought you wanted to convince me that
there are advantages in writing scripts in C (the mere fact
that you can do that has, as far as I can see, never been
questioned).
[snip]
But, if I understand what you write at other times, you
don't seem to like C for what it is: you want to extend
it in all kinds of directions, e.g. making it more like
C++, with operator and function overloading etc., just to
name a few examples.
Surely not as C++, I never proposed that. C++ exists, and
it is a model of what should not be done.
I get the feeling that you actually
want to develop your own language and the restrictions of
C are keeping you back all of the time, making you unhappy
more than necessary.
There are three main points that I want to add:
(1) Abstract types like lists/extensible arrays and others.
(2) Non zero terminated strings
(3) To use the above two a simple language extension is
necessary.
Aren't you missing a garbage collector, operator overloading,
default arguments, arbitrary precision numbers etc. from that
list? At least that's what I remember you to have proposed
quite a few times here.
I have to admit that I never felt that zero-terminated strings
are that evil as you tend to paint them. They're just an array
with one of the elements being set to zero. That fits well
into what I see as making C a slim, effective language. I can
see the security improvements when using counted strings. On
the other hand, as far as I can see, to achieve this security
you then need to have bound checking done on each and every
access to a char in such a string - something that for a good
reason isn't part of the way things are done in C. I thus would
prefer to see this left to a library and not made a core part
of the C language.
I am also not really convinced that introducing abstract types
into the language is beneficial. Until now C has a number of
simple data types, basically numbers and chars, arrays of
them, plus structures that allow you to make up abstract data
types. And, in my opinion, that's a good deal of what makes C
such a nice and relatively simple language. Adding abstract
data types would, again in my opinion, go against the grain
of what makes C what it is.
Of course, that are my private opinions. And, of course, I also
have a few things I would love to have added to C and which I
can't simply do via a library like exceptions...
Why don't you simple cast off all the
baggage and start your own language? Other people have done
so before and have been very successful, with C++ as the
most obvious example?
Implicit here is the idea that C should NOT evolve. That is dead
and any improvement (even getting rid of gets() or asctime())
is just a waste.
Well, the gets() and ascitime() stuff is just a red hering. I
actually couldn't care less if the exist, remain or not (and
I can't remember having seen any real code use e.g. gets()).
And, yes, I don't think that C needs much evolving. For me
it works quite fine most of the time. And the direction of
"evolution" you propose would, again in my opinion, lead to
a different language that would cast off a lot of the advan-
tages is see with C. I find it important that with C I still
can "feel" what's happening behind the scenes, there are no
unexpected calls of functions like you would need for over-
loading, constructors etc. So I use C for stuff where I care
about that. And for other stuff I use a different language.
The main difference seems to me that you seem to want C to be
more similar to higher level languages, so that you can do
everything in C. I would prefer C to stay as "near to the
metal" as possible and when that's unimportant for a task
and writing it in C is inconvenient I'd use something more
suitable. Unfortunately, I think it's going to be difficult
that we at one point will come to hold the same opinion...
C has a very important role nowadays as a lingua franca.
Many kernels, device drivers etc. are written in C, as
well as all kinds of other languages and libraries. But
that's also what makes C so hard to change fundamentally.
How much you rave and swear, it won't get changed easily.
Your opinion.
I thought that's not my opinion but your experience;-)
And if you don't like it come up with something that's
really better and gets accepted!
lcc-win has a download rate of several hundreds per day.
We passed the million downloads recently. lcc-win is accepted.
Congratulations! I didn't know it's that popular. It's a pity
you seem not to be able to publish a Linux version. I'm sure
I would give it a try. And, actually, you seem to have created
a new language, with all the additions you made (sorry, I tried
to have a closer look at the documentation, but whenever I try
to download something I get a "The change you wanted was re-
jected" error message). And having a one million user base
seems to me to be pretty impressive! And if it can be used
as a standard comformant C compiler beside it's even more
impressive.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@xxxxxxxxxxx
\__________________________ http://toerring.de
.
- Follow-Ups:
- Re: C scripting (continued)
- From: jameskuyper
- Re: C scripting (continued)
- From: jacob navia
- Re: C scripting (continued)
- References:
- Re: C scripting (continued)
- From: Jens Thoms Toerring
- Re: C scripting (continued)
- From: jacob navia
- Re: C scripting (continued)
- Prev by Date: Re: size_t compare with zero
- Next by Date: Re: size_t compare with zero
- Previous by thread: Re: C scripting (continued)
- Next by thread: Re: C scripting (continued)
- Index(es):
Relevant Pages
|
Loading
