C as a scripting language

[CBFalconer]

Mr Falconer at least tried to contribute something to the
community. I have included his ggets in lcc-win, because it is
useful and because I appreciate people that try to contribute to
the community even if I disagree with him in almost everything
else.

Well, that's fair enough, and not even insulting. I can definitely
live with that. Why don't you try hashlib?

 

[CBFalconer]

Common widsom says that python, ruby or similar are good for
scripting, but C is not the right tool for it.

Here is a small "benchmark" that shows that C can be used as a
scripting language in the same way as, for instance, ruby.
.... snip ...
sprintf(cmd,"../lcc -g2 -nw %s",buf);
p = strchr(buf,'.');
if (p) *p=0;
r = system(cmd);
if (r) {
printf("Compilation of %s.c failed\n",buf);
CFailures[CompilationFailures++] = strdup(buf);

I assume you want this to work. It won't. The return value from
'system' does not reflect the success of compilation, although it
may on some systems. The following is an extract from the C

<snip>

That does not mean it will not work. It means it will not work where
the implementation has defined it differently. A very big difference.

I quoted the C standard on the subject, and you snipped it. As far
as I am concerned code mentioned here must agree with the standard,
or point out how to avoid the problem.

 

[Keith Thompson]

jacob navia wrote: [...]
r = system(cmd);
if (r) {
printf("Compilation of %s.c failed\n",buf); [...]

I assume you want this to work. It won't. The return value from
'system' does not reflect the success of compilation, although it
may on some systems. The following is an extract from the C

<snip>

That does not mean it will not work. It means it will not work where
the implementation has defined it differently. A very big difference.

I quoted the C standard on the subject, and you snipped it. As far
as I am concerned code mentioned here must agree with the standard,
or point out how to avoid the problem.

But that's not what you said. You specifically said that it won't
work. The standard does not support your claim. The standard doesn't
require it to work, but it certainly permits it to work. (And in fact
it does work on, for example, Unix-like systems.)

If you want to point out that it's non-portable, feel free (though I
think several other people had already done so). But your claim that
it won't work is both incorrect and unsupported by the standard. (A
claim that it does work would also be unsupported by the standard.)

Non-portable code, though it's usually off topic here, can be
perfectly legitimate. Blurring the distinction between non-portable
code and non-working code, and between off-topic information and
incorrect information, doesn't do anybody any favors.

 

[James Kuyper]

I quoted the C standard on the subject, and you snipped it. As far
as I am concerned code mentioned here must agree with the standard,
or point out how to avoid the problem.

If that's what you want to say, then just say that it's not portable -
but don't lie by pretending to believe that anything non-standard is
non-existent. At least, I hope you are lying - if you actually believe
what your rhetorical device implies that you believe, then you have very
serious mental problems. As it stands, the rhetorical device makes you
look almost as stupid as you would have to be to actually believe it.

 

[TonyMc]

WHY DO ONES LOOK LIKE ELLS?

Proverbially that only works for inches, so you could try using metric
instead.

Tony

 

[Richard Bos]

Common widsom says that python, ruby or similar are good for scripting,
but C is not the right tool for it.

The next example I will post

Common wisdom also says that masturbation is better done in private.


As for scripting in C, if I were to do that (which I might - on that one
point I agree with you), I'd make double-damn certain that my script did
_not_ depend on one particular compiler, and would quite possibly use a
C interpreter instead.

Richard

 

[jacob navia]

Common wisdom also says that masturbation is better done in private.

I do not understand why you post then...

 

[Richard Bos]

Oh look, a pig just flew past my window....

I refer the honourable gentlemen to RFC 1925, point 3; and would
particularly enjoin them to read on past the first sentence thereof.

Richard

 

[Richard Bos]

<ot>

Read an interesting essay by David Wheeler on this subject recently:

http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html

</ot>

It must be said that, though the author claims to argue against spaces
in filenames, what his arguments mainly prove, IMO, is that
- _non-printing_ characters in file names are evil, and
- Unix CLI globbing is broken, in that it behaves as the C pre-
processor, rather than as a function call.

Solve those, and mere spaces in filenames are little problem.

Richard

 

[Richard Bos]

I do not understand why you post then...

That's hardly surprising.

Conversely, I have a pretty good idea why you post; I just disagree with
your arguments.

Richard

 

[CBFalconer]

If that's what you want to say, then just say that it's not portable -
but don't lie by pretending to believe that anything non-standard is
non-existent. At least, I hope you are lying - if you actually believe
what your rhetorical device implies that you believe, then you have very
serious mental problems. As it stands, the rhetorical device makes you
look almost as stupid as you would have to be to actually believe it.

Note the underlined "mentioned here". That refers to c.l.c, where
the language is specified by the C standard. If this was another
newsgroup, I would have no comment or objection. As long as the
post is on c.l.c I consider it should remain reasonably close to
topical. I originally simply pointed out to Navia that the code
would not function, and quoted the standard portion that defined
the reason. Now you are expanding it into accusations of lying.

 

[CBFalconer]

I do not understand why you post then...

Here I have a period of agreement with you. Rare, but useful.

 

[Flash Gordon]

Note the underlined "mentioned here". That refers to c.l.c, where
the language is specified by the C standard. If this was another
newsgroup, I would have no comment or objection. As long as the
post is on c.l.c I consider it should remain reasonably close to
topical.
Yes.

I originally simply pointed out to Navia that the code
would not function, and quoted the standard portion that defined
the reason. Now you are expanding it into accusations of lying.

Saying the could "would not function" is factually incorrect and is NOT
supported by the standard. It relies on implementation defined aspects
where the particular implementation, as required by the standard, has
defined them. The implementation has defined them in a way that
*guarantees* that the code will, in fact, work.

When something is non-portable say so. Don't say it won't work when it
is *guaranteed* to work correctly on some implementations.

 

[jacob navia]

Shouldn't that be lcc-nix or lcc-nux? Or does it need wine?

Unix knows how to do windows, and NO it doiesn't need wine!
Compiling when drunk is not recommended!

 

[James Kuyper]

Note the underlined "mentioned here". That refers to c.l.c, where
the language is specified by the C standard.

Your original claim the code would not work was not qualified in that
fashion, and it is that claim which I was objecting to. If you had said
"It won't work on all systems", I would have had no objections. It's the
claim that "It won't", without any qualifications to limit the supposed
applicability of that statement, that makes it a lie.

If this was another
newsgroup, I would have no comment or objection. As long as the
post is on c.l.c I consider it should remain reasonably close to
topical.

Lying about what's wrong with the code won't do anything to improve
topicality. What's wrong with that code is that it will indeed work on
some systems, but not on others. Claiming that the problem is that it
simply won't work is clearly wrong, because it can easily be verified
that it will work, on the system it is intended to be used on. This
leaves people to wonder whether your claim a lie, or simple
incompetence. Those of us who monitor this newsgroup regularly know that
you routinely lie in this fashion in a bizarre attempt to express (very
badly) the fact that an issue is off-topic. However, newbies can be
forgiven for assuming that incompetence is the more likely explanation.

I originally simply pointed out to Navia that the code
would not function, and quoted the standard portion that defined
the reason. Now you are expanding it into accusations of lying.

It will function, it just won't do so portably; and I'm fairly certain
that you are actually aware of that fact, so claiming that it simply
won't function is a lie.

 

[CBFalconer]

CBFalconer wrote:
.... snip ...


Saying the could "would not function" is factually incorrect and
is NOT supported by the standard. It relies on implementation
defined aspects where the particular implementation, as required
by the standard, has defined them. The implementation has defined
them in a way that *guarantees* that the code will, in fact, work.

When something is non-portable say so. Don't say it won't work
when it is *guaranteed* to work correctly on some implementations.

Well, we obviously don't agree on the definitions and restrictions
to be observed.

 

[Flash Gordon]

Well, we obviously don't agree on the definitions and restrictions
to be observed.

I can't think of any reasonable definition of "does not work" which
allows for the possibility of something working. I agree that the
behaviour of the system call in question is not topical here, but that
does not stop it from working.

 

[jacob navia]

Greetings.

f = popen("ls *.c","r");
while (fgets(buf,sizeof(buf),f)) {
char *p = strchr(buf,'\n');
if (p) *p=0;
tests++;
sprintf(cmd,"../lcc -g2 -nw %s",buf);
p = strchr(buf,'.');
if (p) *p=0;
r = system(cmd);
if (r) {
printf("Compilation of %s.c failed\n",buf);
CFailures[CompilationFailures++] = strdup(buf);
} else {
sprintf(cmd,"gcc %s.o lcclibc_asm.s -lm");
r = system(cmd);

So what if you have a file in the directory named '&rm -rf ~&.c'?

Regards,
Tristan

This will provoke the same results as in ruby.

I explained the context (a script that starts an automatic
regression test for the lcc-win compiler) and in that
context there are no malicious files in that directory.

 

[Richard Bos]

So what if you have a file in the directory named '&rm -rf ~&.c'?

Then you murder the person who named it that. It's the only reasonable
reaction, really.

Richard

 

[CBFalconer]

CBFalconer wrote:
.... snip ...


I can't think of any reasonable definition of "does not work" which
allows for the possibility of something working. I agree that the
behaviour of the system call in question is not topical here, but
that does not stop it from working.

I belong to a fanatical religion which specifies that one should
never fail to tuck their legs beneath their chair while typing. So
I pick up a 20 pound weight, normally used to power a grandfather
clock, hold out in front of my knees, and drop it.

LO and BEHOLD, I don't break any toes. I have followed the
standards of my religion, and the system works. It totally avoids
any trips to the hospital, doctors, etc. attributable to dropping
grandfather clock weights.

However, my co-worker belongs to a different religion. When he
drops that weight he fairly regularly breaks toes (his own and
others).

I claim his problem is not following the standard. You seem to
claim that he deserves no calumny for that failure. I have no wish
to pay for his medical treatment. You seem to volunteer for that.