C as a scripting language
jacob navia
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.
Setup
-----
The task to be solved is as follows:
In the current directory you have a bunch of .c files.
For each file in that directory you should start the C
compiler, compile the file, and if the compile works,
link it and then run it. You should gather some statistics
about how many runs were done, and how many compilation
errors or run time errors were discovered, printing them
at the end.
Here is a solution using the "ruby" language:
--------------------------------------------------------------
#/usr/bin/ruby -w
class Array
alias :append :push
end
def run_and_collect(file_list)
comp_counter = 0
run_counter = 0
count_all_compilations = 0
failed_compilations = 0
count_all_runs = 0
failed_runs = 0
failed_run_progs = []
successfull_runs = []
failed_compilation_runs = []
file_list.each {|file|
ret_val = system("../lcc -O -DNO_LABEL_VALUES -c -nw -g2
#{file} -o a.obj && gcc a.obj lcclibc_asm.s -o a -lm")
count_all_compilations += 1
if (ret_val == false)
puts("failed compilation: #{file}")
failed_compilations += 1
failed_compilation_runs.append(file)
else
ret_val = true
ret_val = system("./a")
run_counter+= 1
if (ret_val == false)
puts("failed run: #{file}");
failed_runs += 1
failed_run_progs.append(file + " ")
successfull_runs.append(file)
end
end
}
puts("Compilations: #{count_all_compilations}, failed:
#{failed_compilations}\n
Runs: #{run_counter}, failed: #{failed_runs}\n
#{failed_run_progs} \n")
end
run_and_collect(ARGV)
---------------------------------------------------------------------
Now the C solution:
--------------------------------------------------------------------
#define MAXTESTS 1000
#include <stdio.h>
#include <string.h>
void ShowFailures(char *tab[],int);
int main(int argc,char *argv[])
{
FILE *f;
char buf[512],cmd[1024], tmpbuf[512];
int r, tests=0,CompilationFailures=0, LinkFailures=0, RunFailures=0;
char *CFailures[MAXTESTS],*LFailures[MAXTESTS],
*RFailures[MAXTESTS];
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);
if (r) {
printf("Link of %s.o failed\n",buf);
LFailures[LinkFailures++] = strdup(buf);
} else {
r = system("./a.out");
if (r) {
printf("Execution of %s failed\n",buf);
RFailures[RunFailures++] = strdup(buf);
}
}
}
}
pclose(f);
printf("\n********************************\n%d"
"tests\n********************************\n",tests);
if (CompilationFailures) {
printf("Compilation Failures: (%d)\n",CompilationFailures);
ShowFailures(CFailures,CompilationFailures);
}
if (LinkFailures) {
printf("Link failures: (%d)\n",LinkFailures);
ShowFailures(LFailures,LinkFailures);
}
if (RunFailures) {
printf("Run failures (%d)\n",RunFailures);
ShowFailures(RFailures,RunFailures);
}
}
void ShowFailures(char *tab[],int n)
{
for (int i=0; i<n; i++) { printf("%s ",tab[i]); } printf("\n");
}
----------------------------------------------------------------------------
Both programs use identical algorithms:
(1) The list of *.c files will be established. Ruby uses a list, C uses
a pipe connected to another process that sends a line at a time.
(2) For each file the compiler is called, then the linker and the
resulting program. Statistics are gathered.
(3) A printout at the end of the run lists the failures.
The length in source code of both programs is very similar.
The running time of both programs is identical.
I wrote the C program, and a friend wrote the ruby program. It was
for testing the Unix version of lcc-win, i.e. both programs are
used in a "production" setting.
I think that both languages are perfectly equivalent in this example.
The next example I will post is web programming.
Thanks for your attention.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Keith Thompson
> 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.
>
> Setup
> -----
>
> The task to be solved is as follows:
>
> In the current directory you have a bunch of .c files.
> For each file in that directory you should start the C
> compiler, compile the file, and if the compile works,
> link it and then run it. You should gather some statistics
> about how many runs were done, and how many compilation
> errors or run time errors were discovered, printing them
> at the end.
>
> Here is a solution using the "ruby" language:
> --------------------------------------------------------------
When I compile the above with "lcc -ansic" (using lcc-win), I get:
Warning c.c: 13 missing prototype for popen
Warning c.c: 13 Missing prototype for 'popen'
Error c.c: 13 operands of = have illegal types 'pointer to struct _iobuf' and 'int'
Warning c.c: 21 missing prototype for system
Warning c.c: 21 Missing prototype for 'system'
Warning c.c: 26 sprintf: missing argument for format s
Warning c.c: 27 Missing prototype for 'system'
Warning c.c: 32 Missing prototype for 'system'
Warning c.c: 40 missing prototype for pclose
Warning c.c: 40 Missing prototype for 'pclose'
1 error, 9 warnings
I'm surprised it didn't warn about the missing prototype for strdup.
(And you might want to look into the duplicate warnings for the
missing prototypes.)
Even with those problems corrected, there are a number of system
dependencies in the program. You assume that system() returns 0 if
the invoked command succeeds; the standard says only that the result
is implementation-defined. You assume the existence of an "ls"
command, and of the popen() and pclose() functions.
Perhaps this would be better suited to comp.unix.programmer.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacob navia
He wrote that *windows* lcc-win doesn't understand popen...
Obviously I am using Unix lcc-win, that knows about popen
in /usr/include/stdio.h
This would be obvious to anyone but Mr Thompson...
Or maybe he ignores everything about the Unix system,
I do not know.
In any case the point of my message is that using C
is perfectly OK as a scripting language and compres
equal to ruby.
Mr Thompson did not address those issues.
jacob navia
nonsense
I didn't realize that he called lcc-win wqith
-ansic
that eliminates all non-standard functions like popen.
Of course, when he posts that,
HE IS NOT LYING
and (of course)
HE IS NOT POSTING IN BAD FAITH trying to make
my compiler system in the worst possible light.
HE IS NOT BIASED.
No, of course not!
Mark McIntyre
> Keith Thompson wrote:
> He wrote that *windows* lcc-win doesn't understand popen...
>
> Obviously I am using Unix lcc-win,
Did you say that? What makes it obvious?
> that knows about popen in /usr/include/stdio.h
Presumably #ifdef'ed out when the -ansic flag is used ?
> This would be obvious to anyone but Mr Thompson...
When you're through being rude, you might want to consider the entirely
reasonable points that Keith made about multiple warnings.
> Or maybe he ignores everything about the Unix system,
Or maybe he makes reasonable points which you choose to ignore or
complain about.
> In any case the point of my message is that using C
> is perfectly OK as a scripting language and compres
> equal to ruby.
I doubt anyone will disagree with you that it can be used similarly to
interpreted languages. I've actually used an interpreted C
implementation in that fashion.
> Mr Thompson did not address those issues.
Nobody is obligated to respond only to the questions you asked in your
post. Its commonplace in fact for other facets to be pointed out,
especially errors of grammar and bad style.
Mark McIntyre
> Keith Thompson wrote:
At least he wasn't gratuitously rude and offensive to someone who was
merely asking some questions about the code posted.
> HE IS NOT POSTING IN BAD FAITH trying to make
> my compiler system in the worst possible light.
You're right, he isn't.
You might want to review your paranoia though.
--
Mark McIntyre
CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Richard
> jacob navia wrote:
>> Keith Thompson wrote:
>> nonsense
>
> At least he wasn't gratuitously rude and offensive to someone who was
> merely asking some questions about the code posted.
>
>> HE IS NOT POSTING IN BAD FAITH trying to make
>> my compiler system in the worst possible light.
>
> You're right, he isn't.
>
> You might want to review your paranoia though.
Occasionally one reads a usenet post and is so dumb founded at a
poster's misreading of their own self importance and views that one is
left breathless from shock. This is such a post. For "Mr" McIntyre to
talk about "rude and offesnsive" is akin to Chuck Falconer talking about
hand holding nOObs.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Keith Thompson
> Keith Thompson wrote:
> He wrote that *windows* lcc-win doesn't understand popen...
>
> Obviously I am using Unix lcc-win, that knows about popen
> in /usr/include/stdio.h
My point was that, in this instance, lcc-win was behaving as a
conforming C compiler should, issuing a warning for a call to the
non-standard popen() function. Note that "gcc -std=c99" also issues a
warning.
A conforming C implementation must allow a user to use the name popen
for his own purposes. If it provides a mode that allows the use of
the POSIX popen function declared in <stdio.h>, that's fine.
> This would be obvious to anyone but Mr Thompson...
> Or maybe he ignores everything about the Unix system,
> I do not know.
Correct, you do not know.
Please feel free to address me by my first name, as most people here
do. (I'm not sure whether you're trying to be formal or rude.)
I had actually assumed that popen() was declared in some header other
than <stdio.h>, perhaps <unistd.h>. On checking, I see that POSIX
does require it to be declared in <stdio.h>. So in that respect, your
posted code is merely non-portable, not wrong.
> In any case the point of my message is that using C
> is perfectly OK as a scripting language and compres
> equal to ruby.
>
> Mr Thompson did not address those issues.
No, I didn't; was I required to?
I'll also note that strdup() is non-standard, that you call system()
without the required "#include <stdlib.h>", and that you have a
missing argument in your sprintf call. The first is just a
portability issue, but the others are actual errors. Did your
compiler not warn you about them?
As for the use of C as a scripting language, I'll just make one
observation. In the C version, you had to pick arbitrary buffer sizes
(512 and 1024 bytes). If an input line overflows the buffer, you
appear to quietly use the truncated buffer, and then read the next
line and process it as if it were a separate line. There are ways to
avoid this in C, but they tend to make the code more verbose with
error checking. Scripting languages typically handle arbitary input
lines much more easily. (And you don't use argc, argv, or tmpbuf.)
If you're not interested in having your errors pointed out, you can
ignore this; others may benefit.
Personally, I'd almost certainly use Perl for a task like this, but
that's just me. For a task for which saving time or space isn't very
important, I find that a scripting language makes things easier, by
freeing me from thinking about things like memory management and
rolling my own data structures.
Bartc
"jacob navia" <ja...@nospam.org> wrote in message
news:49cbe2b6$0$17753$ba4a...@news.orange.fr...
> 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.
It's not surprising that C can be used for any task.
But the point of scripting languages is to accomplish a task more quickly
and less painfully than using C, where everything has to be just right,
especially the punctuation. And without bothering with compile-link-run as
much.
> The length in source code of both programs is very similar.
>
This is not too surprising. It would be interesting to see Ruby or Python
code from someone who isn't primarily a C programmer.
You've neatly avoided the problems of an unknown number of files in C (by
using a size assumed to be big enough), and you don't have very demanding
string ops.
> The running time of both programs is identical.
The running times for programs doing file i/o are going to be comparable.
--
Bartc
George Peter Staplin
> 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.
>
> Setup
> -----
[snip]
>
> I think that both languages are perfectly equivalent in this example.
>
> The next example I will post is web programming.
>
> Thanks for your attention.
Jacob, there are actually other people that share your view.
The Varnish web cache/accelerator uses VCL as a configuration language, and
then compiles that to C which then is compiled at runtime for use with
Varnish.
There is even an entire operating system where the shell compiles a C-like
language at runtime, and puts the resulting code into Malloc()ed memory.
See: http://www.losethos.com/
Losethos is a one man, six year effort. It's quite interesting from what
I've seen. He wrote his own C-like compiler for that project.
I've also heard of some LISP-like languages that compile to C at runtime,
and then load the resulting object code transparently.
Now, if only C had an eval() these things would be so much easier... :)
-George
jacob navia
Now THAT is an interesting project.
I would like to know more but apparently the download links do not work
with my browser. I will try tomorrow.
Thanks for the link!
Keith Thompson
> Keith Thompson wrote:
> nonsense
>
> I didn't realize that he called lcc-win wqith
> -ansic
>
> that eliminates all non-standard functions like popen.
>
> Of course, when he posts that,
>
> HE IS NOT LYING
Correct.
> and (of course)
>
> HE IS NOT POSTING IN BAD FAITH trying to make
> my compiler system in the worst possible light.
Correct.
> HE IS NOT BIASED.
Correct.
> No, of course not!
You're really not good at the sarcasm thing.
Flash Gordon
<snip>
> #define MAXTESTS 1000
> #include <stdio.h>
> #include <string.h>
All headers included are above
<snip>
> void ShowFailures(char *tab[],int);
> int main(int argc,char *argv[])
> {
> FILE *f;
> char buf[512],cmd[1024], tmpbuf[512];
You might want to use fewer magic numbers and get rid of tmpbuf as you
don't use it.
<snip>
> r = system(cmd);
You might want to include stdlib.h for system.
> if (r) {
> printf("Compilation of %s.c failed\n",buf);
> CFailures[CompilationFailures++] = strdup(buf);
> } else {
> sprintf(cmd,"gcc %s.o lcclibc_asm.s -lm");
You might want to provide the arguments your format specifier promises.
<snip>
> Both programs use identical algorithms:
> (1) The list of *.c files will be established. Ruby uses a list, C uses
> a pipe connected to another process that sends a line at a time.
So if that list is part of then that is an advantage for Ruby, since you
are using features that are not part of C.
> (2) For each file the compiler is called, then the linker and the
> resulting program. Statistics are gathered.
If your C program links the code then it is by chance.
> (3) A printout at the end of the run lists the failures.
>
> The length in source code of both programs is very similar.
>
> The running time of both programs is identical.
>
> I wrote the C program, and a friend wrote the ruby program. It was
> for testing the Unix version of lcc-win, i.e. both programs are
> used in a "production" setting.
<snip>
Then you need to fix your program. Start with fixing all the things the
compiler warns about in it.
--
Flash Gordon
jacob navia
> jacob navia wrote:
>
> <snip>
>
>> #define MAXTESTS 1000
>> #include <stdio.h>
>> #include <string.h>
>
> All headers included are above
>
> <snip>
>
>> void ShowFailures(char *tab[],int);
>> int main(int argc,char *argv[])
>> {
>> FILE *f;
>> char buf[512],cmd[1024], tmpbuf[512];
>
> You might want to use fewer magic numbers and get rid of tmpbuf as you
> don't use it.
>
> <snip>
>
>> r = system(cmd);
>
> You might want to include stdlib.h for system.
>
>> if (r) {
>> printf("Compilation of %s.c failed\n",buf);
>> CFailures[CompilationFailures++] = strdup(buf);
>> } else {
>> sprintf(cmd,"gcc %s.o lcclibc_asm.s -lm");
>
> You might want to provide the arguments your format specifier promises.
>
This is the only error that creeped in when pasting the code and trying
to reformat it. should be:
>> sprintf(cmd,"gcc %s.o lcclibc_asm.s -lm",buf);
obviously
> <snip>
>
>> Both programs use identical algorithms:
>> (1) The list of *.c files will be established. Ruby uses a list, C uses
>> a pipe connected to another process that sends a line at a time.
>
> So if that list is part of then that is an advantage for Ruby, since you
> are using features that are not part of C.
>
You do not know what C is dude
[snip drivel]
Obviously the regs here do not understand the purpose of scripting.
Scripting is a quick program, not designed for speed or portability
that fills a task in a production chain. If there are 512 bytes
unused somewhere nobody cares.
By the way, the same code runs under lcc-win under windows. You should
just change the "ls" to "dir /b" and the rest is the same.
ANd I will go on posting code here whenever I feel like it. Other people
(like Gordon) can't do that. He has never posted a single line here.
The same for all other "regs" complaining their usual nonsense.
The are unable to do anything constructive and limit themselves to
pissing around other people.
Well let them do that if they are happy with it.
Mark Wooding
> In the current directory you have a bunch of .c files.
> For each file in that directory you should start the C
> compiler, compile the file, and if the compile works,
> link it and then run it. You should gather some statistics
> about how many runs were done, and how many compilation
> errors or run time errors were discovered, printing them
> at the end.
[snip to C version]
> #define MAXTESTS 1000
> #include <stdio.h>
> #include <string.h>
> void ShowFailures(char *tab[],int);
> int main(int argc,char *argv[])
> {
> FILE *f;
> char buf[512],cmd[1024], tmpbuf[512];
> int r, tests=0,CompilationFailures=0, LinkFailures=0, RunFailures=0;
> char *CFailures[MAXTESTS],*LFailures[MAXTESTS],
> *RFailures[MAXTESTS];
>
> f = popen("ls *.c","r");
> while (fgets(buf,sizeof(buf),f)) {
Dereferencing null pointers isn't fun. Let's hope there weren't any
errors setting up that pipe, eh?
This will incorrectly interpret filenames which contain newline
characters as the names of two or more separate files (which may or may
not exist). It will also silently do something wrong on very long file
names (namely to split the file name into 511-byte chunks, with a short
trailing chunk, and treat each chunk as a separate name).
It will also process the files contained within directories matching
`*.c', regardless of the names of the contained files.
> 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);
Buffer overflow here if there are many files. Let's hope there was
enough memory for the string copy.
> } else {
> sprintf(cmd,"gcc %s.o lcclibc_asm.s -lm");
> r = system(cmd);
> if (r) {
> printf("Link of %s.o failed\n",buf);
> LFailures[LinkFailures++] = strdup(buf);
And again.
> } else {
> r = system("./a.out");
> if (r) {
> printf("Execution of %s failed\n",buf);
> RFailures[RunFailures++] = strdup(buf);
And... It's like shooting fish in a barrel.
> }
> }
> }
> }
> pclose(f);
This discards the exit status from `ls'. You'll never know whether it
returned all the files. In fact, you'll never know if you actually had
permission to read the current directory at all.
> printf("\n********************************\n%d"
> "tests\n********************************\n",tests);
> if (CompilationFailures) {
> printf("Compilation Failures: (%d)\n",CompilationFailures);
> ShowFailures(CFailures,CompilationFailures);
With hilarious results if we stashed a null pointer earlier.
> }
> if (LinkFailures) {
> printf("Link failures: (%d)\n",LinkFailures);
> ShowFailures(LFailures,LinkFailures);
> }
And...
> if (RunFailures) {
> printf("Run failures (%d)\n",RunFailures);
> ShowFailures(RFailures,RunFailures);
> }
> }
>
> void ShowFailures(char *tab[],int n)
> {
> for (int i=0; i<n; i++) { printf("%s ",tab[i]); } printf("\n");
> }
> Both programs use identical algorithms:
> (1) The list of *.c files will be established. Ruby uses a list, C uses
> a pipe connected to another process that sends a line at a time.
Actually, the Ruby code doesn't do this at all; it just processes the
files named on its command line.
> (2) For each file the compiler is called, then the linker and the
> resulting program. Statistics are gathered.
The Ruby version doesn't check separately for link failures: it uses a
shell operator to do both compiling and (if that worked) linking,
without informing the script which part was responsible for any
failures.
> (3) A printout at the end of the run lists the failures.
>
> The length in source code of both programs is very similar.
Indeed. The C code is doing things the Ruby code doesn't do. I'll
certainly agree that the programs are commensurate in length.
> The running time of both programs is identical.
Unsurprising. Compared to the overheads of running the compiler and
linker, you won't notice even fairly gross inefficiencies in the script.
I'd probably have written the whole thing as a shell script, I must
admit:
#! /bin/sh
set -e
stages="compile link run"
clean () { for i in $stages; do rm -f $i-failures done; }
for i in $stages; do eval n$i=0; done
try () {
set -e
what=$1 name=$2; shift 2
if ! "$@"; then
echo "failed to $what: $name"
eval n$i="\$(expr \$n$i + 1)"
echo "$name" >>$what
fi
}
clean
for f in *.c; do
o=${f%.c}.o
try compile "$f" ../lcc -g2 -nw "$f"
try link "$f" gcc "$o" lcclibc_asm.s -lm
try run "$f" ./a.out
done
for i in $stages; do
if [ -r $i-failures ]; then
eval n=\$n$i
echo "$i failures ($n)"
cat $i-failures
fi
done
clean
Shorter than either, mostly easier to read (apologies for the eval
hacking, though -- I would have used `wc -l' but that loses when file
names contain newlines), with all the features of the C version and none
of the bugs. (Downside: it clobbers some files you're unlikely to have
created.)
> I wrote the C program, and a friend wrote the ruby program. It was
> for testing the Unix version of lcc-win, i.e. both programs are
> used in a "production" setting.
>
> I think that both languages are perfectly equivalent in this example.
Well, except that the Ruby version is robust against errors and
unexpected inputs, whereas bulletproofing the C version equivalently
would expand it greatly.
-- [mdw]
jacob navia
> jacob navia <ja...@nospam.org> writes:
>
> Dereferencing null pointers isn't fun. Let's hope there weren't any
> errors setting up that pipe, eh?
>
It would be highly surprising that in a directory where
there are 600 .c files that doesn't work...
> This will incorrectly interpret filenames which contain newline
> characters as the names of two or more separate files (which may or may
> not exist).
Sure. And I do not care. And if you put 8 backspaces
in a file name it will be kind of invisible duh!
> It will also silently do something wrong on very long file
> names (namely to split the file name into 511-byte chunks, with a short
> trailing chunk, and treat each chunk as a separate name).
>
And I do not care either since I know that all file names are
exactly 8 chars long, and with 512 I have enough leeway.
What the regs do not understand is that a script tailored for
a given situation and in a given context is NOT a general
program to compile and run all C files in a given directory.
It is a script for a particular situation in a given software chain.
Ben Bacarisse
> jacob navia wrote:
>
>> 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.
>>
>> Setup
>> -----
> [snip]
>>
>> I think that both languages are perfectly equivalent in this example.
>>
>> The next example I will post is web programming.
>>
>> Thanks for your attention.
>
> Jacob, there are actually other people that share your view.
>
> The Varnish web cache/accelerator uses VCL as a configuration language, and
> then compiles that to C which then is compiled at runtime for use with
> Varnish.
<snip other examples of compiling to C>
I think your examples make the opposite point, don't they? Examples of
how people have addressed certain problem areas by using languages
that get turned /into/ C suggests, to me, that these projects decided
(maybe wrongly of course) that C was not suitable for writing the code
in the first place.
--
Ben.
Keith Thompson
[...]
> What the regs do not understand is that a script tailored for
> a given situation and in a given context is NOT a general
> program to compile and run all C files in a given directory.
>
> It is a script for a particular situation in a given software chain.
We don't understand because you didn't bother to say so.
One advantage of using a scripting language is that a lot of these
details, such as handling arbitrary input lines and file names, is
taken care of automatically; there's no need to assume that input
lines are reasonably sort and file names are sane.
If I were to write an equivalent script in Perl, with a little care,
it would correctly handle things like extremely long file names with
embedded newline characters. Maybe that's not worth worrying about,
but it's worth mentioning.
As you pointed out in your original article, the version written in a
scripting language is of comparable size to the version written in C.
But to get the same safety that the script gives you for free, the C
version would have to be substantially larger.
Is your point that C is a good as a scripting language for a
quick-and-dirty task that's not intended to be portable or reusable?
C is not the best tool for everything. (You'll probably interpret
this as a personal attack on you, the C language, and lcc-win. It
isn't.)
Incidentally, Perl is implemented in C.
Flash Gordon
> Mark Wooding wrote:
<snip>
>> This will incorrectly interpret filenames which contain newline
>> characters as the names of two or more separate files (which may or may
>> not exist).
>
> Sure. And I do not care. And if you put 8 backspaces
> in a file name it will be kind of invisible duh!
Strange things are known to happen.
> > It will also silently do something wrong on very long file
>> names (namely to split the file name into 511-byte chunks, with a short
>> trailing chunk, and treat each chunk as a separate name).
>
> And I do not care either since I know that all file names are
> exactly 8 chars long, and with 512 I have enough leeway.
If you don't tell people what restrictions code is designed to work in
how do you expect them to know?
> What the regs do not understand is that a script tailored for
> a given situation and in a given context is NOT a general
> program to compile and run all C files in a given directory.
Some scripts have very restricted use, others don't.
> It is a script for a particular situation in a given software chain.
Only to the same extent that applies to all software.
I have to write scripts which will work much more flexibly and robustly.
If they do something nasty because someone accidentally created a file named
ls ..
cd ..; rm *
then I would be in *serious* trouble. I've not come across that, but I
have seen a file names "*" and files with other commands in the name due
to idiot sysadmins not knowing what they were doing.
Other customers have very good and intelligent sysadmins, and I'm not
going to name either group of customers ;-)
--
Flash Gordon
Flash Gordon
So the error of failing to include stdlib.h was in your real code? In
that case you should take note of the warnings your compiler does, I'm
sure, produce for it.
> should be:
>
> >> sprintf(cmd,"gcc %s.o lcclibc_asm.s -lm",buf);
>
> obviously
>
>> <snip>
>>
>>> Both programs use identical algorithms:
>>> (1) The list of *.c files will be established. Ruby uses a list, C uses
>>> a pipe connected to another process that sends a line at a time.
>>
>> So if that list is part of then that is an advantage for Ruby, since
>> you are using features that are not part of C.
>
> You do not know what C is dude
I know exactly what it is and have done a fair bit of programming in it
for some very different systems.
> [snip drivel]
>
> Obviously the regs here do not understand the purpose of scripting.
Wrong, from what I've seen a number of us (including me) do a fir bit of
scripting.
> Scripting is a quick program,
Only some times. Some times they are large programs.
> not designed for speed or portability
Only some times. Some times they are very much designed for portability
to a specific range of systems.
> that fills a task in a production chain.
Definitely only sometimes. There are a *lot* of scripts automating all
sorts of tasks on servers. Others are pushed out to client machines to
automate tasks.
> If there are 512 bytes
> unused somewhere nobody cares.
You've obviously not done scripting on a system tight on memory (which
is done).
I've written a rather more sophisticatedly build system in DCL in the
past. Entirely non-portable, and targetted at a specific project, bit
very good. Unfortunately I left that company almost 9 years ago so I
don't have it.
> By the way, the same code runs under lcc-win under windows.
Wow. It runs on two implementations which are designed to be very similar.
> You should
> just change the "ls" to "dir /b" and the rest is the same.
So you have to change it.
> ANd I will go on posting code here whenever I feel like it.
No where in that post did I complain about you posting code. I just
pointed out a number of errors in your C.
> Other people
> (like Gordon) can't do that. He has never posted a single line here.
Wrong. I have posted code here on a number of occasions. I don't post
code I write professionally because I don't need help with the C issues
and there are other resources for the non-C issues.
Oh, and it is impolite to use someones last name without the appropriate
honorific, but feel free to use my nick or look up my first name (my
full name is easy to find).
> The same for all other "regs" complaining their usual nonsense.
>
> The are unable to do anything constructive and limit themselves to
> pissing around other people.
You need to learn that pointing out errors in code is constructive. The
"regs" also post corrected code and alternative versions when they feel
like it.
> Well let them do that if they are happy with it.
You have yet to understand what people are doing.
--
Flash Gordon
Han from China
> A conforming C implementation must allow a user to use the name popen
> for his own purposes.
Wrong. And I suspect you know why you're wrong, but you choose to
ignore that fact because it doesn't flatter your topicality opinions.
Any other time, you're very particular with the wording of the standard.
For those interested in what the standard actually requires, note
that the standard, through a poor definition of a strictly conforming
program, lets a conforming implementation decide what constitutes
a strictly conforming program. Despite what Keith would have you believe,
this is not "trolling" -- anyone who cares about truth can check the
standard and verify that what I'm saying is correct.
Yours,
Han from China
--
"Only entropy comes easy." -- Anton Chekhov
Han from China
> ANd I will go on posting code here whenever I feel like it. Other people
> (like Gordon) can't do that. He has never posted a single line here.
> The same for all other "regs" complaining their usual nonsense.
You're lying about the "regs"*, Jacob. Heathfield posts buggy code all
the time. ;-)
Gordon talks about C, at the very least, which is pretty much all I
do as well, to be honest. But as for attack-dog and "village idiot"
McIntyre, he knows better than even to talk about C.
* My "regs" set is as follows: Thompson, Heathfield, McIntyre,
Falconer, possibly Gordon, possibly Carmody, possibly Keighley. I'm
tempted to add Kuyper, Sosman, and Klein, but that would be unfair,
since despite what they've said about me, I respect the fact that
they're not phonies.
> The are unable to do anything constructive and limit themselves to
> pissing around other people.
Right. They think they're top gun programmers because they can
nitpick and throw standard quotes around. Even *I* do that as part
of the point I'm trying to prove, so it's not saying much for them if
they can't differentiate themselves in any way operationally from me,
a crappy C programmer who trips over himself like Heathfield!
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.
>
>
> 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
standard.
7.20.4.6 The system function
Synopsis
[#1]
#include <stdlib.h>
int system(const char *string);
... snip ...
Returns
[#3] If the argument is a null pointer, the system function
returns nonzero only if a command processor is available.
If the argument is not a null pointer, and the system
function does return, it returns an implementation-defined
value. ^^^^^^^^^^^^^^^^^^^^^^
Also consider using my ggets to form buf content in the first
place. That way there is no intrinsic length limitation, and the
final '\n' is automatically removed and zeroed.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer
>
... snip ...
>
> By the way, the same code runs under lcc-win under windows. You
> should just change the "ls" to "dir /b" and the rest is the same.
>
> ANd I will go on posting code here whenever I feel like it. Other
> people (like Gordon) can't do that. He has never posted a single
> line here. The same for all other "regs" complaining their usual
> nonsense.
I didn't notice any complaints about posting code. I do it all the
time. However I attempt to make that code run on any conformant C
system, and if not there is usually an annotation explaining the
difference.
Notice that I responded to your original post, which did not pick
any fights. You may have noticed that my responses are growing
less sympathetics as I read your attacks on people.
CBFalconer
> Keith Thompson wrote:
>
> He wrote that *windows* lcc-win doesn't understand popen...
>
> Obviously I am using Unix lcc-win, that knows about popen
> in /usr/include/stdio.h
>
> This would be obvious to anyone but Mr Thompson... Or maybe he
> ignores everything about the Unix system, I do not know.
>
> In any case the point of my message is that using C is perfectly
> OK as a scripting language and compres equal to ruby.
>
> Mr Thompson did not address those issues.
Here you are starting another pointless fight. You are posting on
c.l.c, where the subject is the C language, as defined by the C
standard. Not some Unix standard. C does not have popen.
pete
A program which uses a library function named popen declared in stdio.h
(which happens to be the case being discussed)
can't be a "strictly conforming program".
There are restrictions on what features can be used
by a "strictly conforming program".
[#5] A strictly conforming program shall use only those
features of the language and library specified in this
International Standard.
What constitutes a "conforming program" is another matter.
And what constitutes a "correct program" is yet another matter.
I consider how to write a "correct program" to be on topic.
--
pete
Han from China
> A program which uses a library function named popen declared in stdio.h
> (which happens to be the case being discussed)
> can't be a "strictly conforming program".
>
> There are restrictions on what features can be used
> by a "strictly conforming program".
>
> [#5] A strictly conforming program shall use only those
> features of the language and library specified in this
> International Standard.
If that were the end of it, then there'd be no problem. But that isn't
the full definition of a strictly conforming program. There are a
couple of other necessary conditions for a program to be strictly
conforming:
A strictly conforming program shall use only those features
of the language and library specified in this International
Standard. It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior,
and shall not exceed any minimum implementation limit.
Since "output" is vague, and more important, since the standard doesn't
enumerate a full list of minimum implementation limits (the "one program"
doesn't count), a conforming hosted implementation must decide for itself
whether a program exceeds any minimum implementation limit and therefore
whether the program is strictly conforming.
It's possible that what is strictly conforming for one conforming
hosted implementation is not strictly conforming for another. This
relativity opens many doors.
A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming program.
So as long as the popen() function doesn't alter the behavior of
what a conforming hosted implementation regards as a strictly
conforming program, the popen() function is permitted.
Han from China
> ... the popen() function is permitted.
Jacob's compiler meets the C99 standard's definition of a conforming
hosted implementation. He's allowed to decide what constitutes
"output" and "minimum implementation limits", so he's allowed to
decide whether any program is or is not strictly conforming, and so
he's allowed to decide whether anything he adds to his compiler will
clash with a strictly conforming program.
All this time, the "regs" (see my "regs" set in a prior post in
this thread) have been telling Jacob his compiler isn't conforming,
while the standard tells us that his compiler *is* conforming. The
reader may not believe I'm offering a practical definition of
conforming, but we're not dealing with practical people; we're
dealing with standard bashers, and their own standard refutes
their statements and attacks against Jacob.
William Pursell
> Flash Gordon wrote:
> > You might want to provide the arguments your format specifier promises.
>
> This is the only error that creeped in when pasting the code and trying
> to reformat it. should be:
>
> >> sprintf(cmd,"gcc %s.o lcclibc_asm.s -lm",buf);
>
> obviously
No. It's not obvious. He is doing you a favor by pointing
out an error. If the error was a trivial error of cut
and paste, then you should either simply thank him
or ignore the point completely.
>
> You do not know what C is dude
Why are you so phenomenally rude?
<snip>
> ANd I will go on posting code here whenever I feel like it. Other people
> (like Gordon) can't do that. He has never posted a single line here.
> The same for all other "regs" complaining their usual nonsense.
So there is another concrete characteristic of a "reg". Someone
who has never posted any code to the group. I had previously
concluded that the "regulars" consists solely of CBF, but clearly
the group of "regulars" is completely empty.
> The are unable to do anything constructive and limit themselves to
> pissing around other people.
>
> Well let them do that if they are happy with it.
Jacob, you continue to behave like a buffoon. You only
damage your own image by doing so.
Richard Heathfield
<snip>
> You do not know what C is dude
It seems that neither do my installations of Microsoft C, Borland C,
or gcc. Your code didn't compile on any of them until I removed the
gratuitously non-portable code, at which point I was left with the
non-gratuitously non-portable code. This compiled (with lots of
diagnostic messages, admittedly, but it DID compile).
Unfortunately, it didn't link on two of the compilers that I tested
your code on. On the third, gcc, it linked, but didn't do anything
useful at runtime because of non-portable assumptions made within
the program itself.
You know what /you/ think C is, but some of us look at it very
differently to you.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield
<snip>
> Also consider using my ggets
Don't you think he's got enough problems already?
Ian Collins
>
> I'd probably have written the whole thing as a shell script,
Or use more than one tool form the box.
The outer loop can be simplified to (and made more portable):
while( --argc > 0 )
{
const char* file = argv[argc];
..
}
If the program is run with
./a.out `ls *.c`
It will still fail with file names with spaces, but no sane developer
has spaces in source file names, do they?
--
Ian Collins
Flash Gordon
> jacob navia wrote:
>> 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.
>>
>> 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.
--
Flash Gordon
Richard Heathfield
<snip>
> It will still fail with file names with spaces, but no sane
> developer has spaces in source file names, do they?
No sane user[1] inserts spaces into any file name. There are very
few sane users, however. It doesn't help that the most common
desktop OS actively encourages the darn things.
[1] definition: a "sane user" is someone who shares my
preconceptions about how computers should be used and who should be
allowed to use them. It may well be that the world boasts only one
sane user[2].
[2] Yes, I know this is morally equivalent to "the whole school was
parading along High Street, and my little boy was the ONLY one in
step!", but I don't care.
jacob navia
> So there is another concrete characteristic of a "reg". Someone
> who has never posted any code to the group. I had previously
> concluded that the "regulars" consists solely of CBF, but clearly
> the group of "regulars" is completely empty.
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.
Chris McDonald
>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.
Well it only took about 2 follow-ups to this thread before it was smashed
by those complaining about Jacob, lcc, the mantra of the newsgroup -
and it wouldn't be a real thread without ggets getting a run...
Unsurprisingly, hardly any comments about the actual subject of the thread.
I haven't used it recently, but it would seem very easy to develop a
C-interpreter (for some people's understanding of 'C') using the Ch
embeddable interpreter: http://www.softintegration.com/
This seems a better approach than compiling C code snippets on the fly.
--
Chris.
pete
> pete wrote:
>> A program which uses a library function named popen declared in stdio.h
>> (which happens to be the case being discussed)
>> can't be a "strictly conforming program".
>>
>> There are restrictions on what features can be used
>> by a "strictly conforming program".
>>
>> [#5] A strictly conforming program shall use only those
>> features of the language and library specified in this
>> International Standard.
>
> If that were the end of it, then there'd be no problem. But that isn't
> the full definition of a strictly conforming program. There are a
> couple of other necessary conditions for a program to be strictly
> conforming:
>
> A strictly conforming program shall use only those features
> of the language and library specified in this International
> Standard. It shall not produce output dependent on any
> unspecified, undefined, or implementation-defined behavior,
> and shall not exceed any minimum implementation limit.
>
> Since "output" is vague, and more important, since the standard doesn't
> enumerate a full list of minimum implementation limits (the "one program"
> doesn't count), a conforming hosted implementation must decide for itself
> whether a program exceeds any minimum implementation limit and therefore
> whether the program is strictly conforming.
I understand the "one program" description
to be the full list of minimum implementation limits.
>
> It's possible that what is strictly conforming for one conforming
> hosted implementation is not strictly conforming for another. This
> relativity opens many doors.
>
> A conforming implementation may have extensions (including additional
> library functions), provided they do not alter the behavior of any
> strictly conforming program.
>
> So as long as the popen() function doesn't alter the behavior of
> what a conforming hosted implementation regards as a strictly
> conforming program, the popen() function is permitted.
That would be simpler if popen were declared in a nonstandard header.
But being declared in stdio.h, it prevents me from defining
my own popen in a program which #includes <stdio.h>
and that's what Keith was taliking about.
--
pete
Tristan Miller
In article <49cbe2b6$0$17753$ba4a...@news.orange.fr>, jacob navia wrote:
> 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.
>
> Setup
> -----
>
> The task to be solved is as follows:
>
> In the current directory you have a bunch of .c files.
> For each file in that directory you should start the C
> compiler, compile the file, and if the compile works,
> link it and then run it. You should gather some statistics
> about how many runs were done, and how many compilation
> errors or run time errors were discovered, printing them
> at the end.
You've produced two enormous monstrosities here where a single command line
in a decent interactive shell would have done the job. In bash, for
example:
for f in *.c; do gcc $f && ./a.out; done
This would be only a bit larger if you want to count compilation and
run-time errors. It would still probably fit on one line.
The moral of the story: use the right tool for the job. In this case,
neither ruby nor C seems to be the right tool.
Regards,
Tristan
--
_
_V.-o Tristan Miller >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=- <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you
Boon
> Jacob wrote:
>
>> Keith wrote [that *windows* lcc-win doesn't understand popen...]
>>
>> Obviously I am using Unix lcc-win,
>
> Did you say that? What makes it obvious?
popen was a dead giveaway.
gwo...@gmail.com
> run-time errors. It would still probably fit on one line.
#!/bin/bash
# Maybe slightly more than one line ;)
filecount=0
compcomplete=0
runcomplete=0
for f in *.c
do
filecount=$(( $filecount + 1 ))
exename="${f%.c}".exe
gcc -o "${exename}" "$f" &&
compcomplete=$(( $compcomplete + 1)) &&
./${exename} &&
runcomplete=$(( $runcomplete + 1 ))
done
echo $filecount Files
echo $(( $filecount - $compcomplete )) compilation error
echo $(( $filecount - $runcomplete )) runtime errors
> The moral of the story: use the right tool for the job. In this case,
> neither ruby nor C seems to be the right tool.
Amen.
jacob navia
Both ruby and C keep a list of files that failed. You fail
to do that.
But it is a good first attempt :-)
jacob navia
As it was the use of "ls" :-)
Tristan Miller
In article
<74c4a0ae-51f6-4a32...@q2g2000vbr.googlegroups.com>,
gwo...@gmail.com wrote:
>> This would be only a bit larger if you want to count compilation and
>> run-time errors. It would still probably fit on one line.
>
> #!/bin/bash
> # Maybe slightly more than one line ;)
> filecount=0
> compcomplete=0
> runcomplete=0
> for f in *.c
> do
> filecount=$(( $filecount + 1 ))
> exename="${f%.c}".exe
> gcc -o "${exename}" "$f" &&
> compcomplete=$(( $compcomplete + 1)) &&
> ./${exename} &&
> runcomplete=$(( $runcomplete + 1 ))
> done
>
> echo $filecount Files
> echo $(( $filecount - $compcomplete )) compilation error
> echo $(( $filecount - $runcomplete )) runtime errors
Well, if you're writing a maintainable script, yes. But for just a
throwaway, I'd opt for the simpler
F=0 C=0 R=0 for f in *.c;do F=$((F+1)) gcc $f && C=$((C+1)) ./a.out &&
R=$((R+1));done;echo $F $((F-C)) $((F-R))
I have to run such interactive-mode scripts all the time. No need for
indentation, descriptive variable names, and fancy output for a small
nonce task.
James Kuyper
...
>> In the current directory you have a bunch of .c files.
>> For each file in that directory you should start the C
>> compiler, compile the file, and if the compile works,
>> link it and then run it. You should gather some statistics
>> about how many runs were done, and how many compilation
>> errors or run time errors were discovered, printing them
>> at the end.
>
> You've produced two enormous monstrosities here where a single command line
> in a decent interactive shell would have done the job. In bash, for
> example:
>
> for f in *.c; do gcc $f && ./a.out; done
The specifications given above include actually running the programs
after they've been compiled.
> This would be only a bit larger if you want to count compilation and
> run-time errors. It would still probably fit on one line.
It's clearly possible, and I think it could be done more easily by a
shell script than either of the examples jacob gave. However, I
seriously doubt that it can be done in a single line, and I'm positive
that doing it in one line would be a bad idea, if only because it would
be harder to understand than it need be.
Chris Dollin
> 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.
(fx:snip)
> Here is a solution using the "ruby" language:
(fx:snip ruby)
If I may offtopically say so, this is a completely horrible solution,
twice as long and ten times less transparent than it need be.
> The length in source code of both programs is very similar.
A factor of two isn't "very similar".
> The running time of both programs is identical.
Well, yes, the run-time is going to be dominated by the cost of
compiling and maybe running.
Here's my hacked ruby version. You could probably use this as the
basis for a shorter C version. I changed the command strings (obviously)
and dumped print-as-we-go in favour of print-problems-at-end.
#/usr/bin/ruby -w
def run_and_collect(file_list)
run_failures = []
run_successes = []
compile_failures = []
#
file_list.each do |file|
compiledOK = system( "gcc -O #{file} -o runMe" )
if compiledOK
ranOK = system( "./runMe" )
(ranOK ? run_successes : run_failures).push( file )
else
compile_failures.push(file)
end
end
puts("Compilations: #{file_list.size}" )
puts( " failed: #{compile_failures.size} (#{compile_failures})\n" );
puts( "Runs: #{run_successes.size + run_failures.size}" )
puts( " failed: #{run_failures.size} (#{run_failures})\n" );
end
run_and_collect(ARGV)
--
"You're down as expendable. You don't get a weapon." /Dark Lord of Derkholm/
Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN
Ed Prochak
> Common widsom says that python, ruby or similar are good for scripting,
> but C is not the right tool for it.
>
>
> Both programs use identical algorithms:
> (1) The list of *.c files will be established. Ruby uses a list, C uses
> a pipe connected to another process that sends a line at a time.
> (2) For each file the compiler is called, then the linker and the
> resulting program. Statistics are gathered.
> (3) A printout at the end of the run lists the failures.
>
> The length in source code of both programs is very similar.
>
>
> for testing the Unix version of lcc-win, i.e. both programs are
> used in a "production" setting.
>
> I think that both languages are perfectly equivalent in this example.
>
> The next example I will post is web programming.
>
> Thanks for your attention.
Please, not another C shell! 8^(
make it go away. make it go away!
Ed
James Kuyper
Possibly because your specification of the problem to be solved failed
to require it.
Tristan Miller
In article <49ccc926$0$17748$ba4a...@news.orange.fr>, jacob navia wrote:
> Both ruby and C keep a list of files that failed. You fail
> to do that.
That wasn't one of your stated requirements.
Tristan Miller
In article <m25zl.8$6n...@nwrddc01.gnilink.net>, James Kuyper wrote:
> Tristan Miller wrote:
> ...
>>> In the current directory you have a bunch of .c files.
>>> For each file in that directory you should start the C
>>> compiler, compile the file, and if the compile works,
>>> link it and then run it. You should gather some statistics
>>> about how many runs were done, and how many compilation
>>> errors or run time errors were discovered, printing them
>>> at the end.
>>
>> You've produced two enormous monstrosities here where a single command
>> line
>> in a decent interactive shell would have done the job. In bash, for
>> example:
>>
>> for f in *.c; do gcc $f && ./a.out; done
>
> The specifications given above include actually running the programs
> after they've been compiled.
Yes, and? ./a.out accomplishes this on *nix.
> It's clearly possible, and I think it could be done more easily by a
> shell script than either of the examples jacob gave. However, I
> seriously doubt that it can be done in a single line, and I'm positive
> that doing it in one line would be a bad idea, if only because it would
> be harder to understand than it need be.
Depends if you need anyone else to understand it. If it's just a one-off
script, like the dozens I need to write each day, then there's no reason
why it couldn't (and shouldn't) be written directly at the command prompt
in one line. In another post I gave an example of this; it's about 110
characters long.
Keith Thompson
popen was a dead giveaway that the program was intended for a
Unix-like system. I suppose jacob's name at the top was probably a
dead giveaway that some variant of lcc-win was being used, but I
didn't want ot make that assumption.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Chris Dollin
> Boon <root@localhost> writes:
>> Mark wrote:
>>> Jacob wrote:
>>>> Keith wrote [that *windows* lcc-win doesn't understand popen...]
>>>>
>>>> Obviously I am using Unix lcc-win,
>>>
>>> Did you say that? What makes it obvious?
>>
>> popen was a dead giveaway.
>
> popen was a dead giveaway that the program was intended for a
> Unix-like system. I suppose jacob's name at the top was probably a
> dead giveaway that some variant of lcc-win was being used, but I
> didn't want ot make that assumption.
I thought the "../lcc" in the `system` argument was a bit of a giveaway.
--
"You're down as expendable. You don't get a weapon." /Dark Lord of Derkholm/
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
jameskuyper
> Greetings.
>
> In article <m25zl.8$6n...@nwrddc01.gnilink.net>, James Kuyper wrote:
> > Tristan Miller wrote:
...
> >
> > The specifications given above include actually running the programs
> > after they've been compiled.
>
> Yes, and? ./a.out accomplishes this on *nix.
You are, of course, correct. I always name my executables something
else, but I'm well aware of the fact that a.out is the default, so I'm
not sure how I managed to miss that.
> > It's clearly possible, and I think it could be done more easily by a
> > shell script than either of the examples jacob gave. However, I
> > seriously doubt that it can be done in a single line, and I'm positive
> > that doing it in one line would be a bad idea, if only because it would
> > be harder to understand than it need be.
>
> Depends if you need anyone else to understand it.
At an absolute minimum, I need to be able to understand it, even if no
one else needs to do so, and trying to do all of those things on a
single line would push the limits on my own ability to understand what
I was writing.
> ... If it's just a one-off
> script, like the dozens I need to write each day, then there's no reason
> why it couldn't (and shouldn't) be written directly at the command prompt
> in one line. In another post I gave an example of this; it's about 110
> characters long.
Your version doesn't meet the specification that a count of
compilation errors and runtime errors be collected and reported.
However, the same is true of both of jacob's versions, too. All three
"scripts" count only the number of failed compilations and the number
of failed runs, but not the number of errors. On a unix-like system
I'd pipe the compiler output to "grep -i error | wc -l", resigning
myself to the fact that it would produce an overcount due to the
possibility of the string "error" coming up for some reason (such as a
file name) in some context other than an error message.
jfbod...@gmail.com
> Ian Collins said:
>
> <snip>
>
> > It will still fail with file names with spaces, but no sane
> > developer has spaces in source file names, do they?
>
> No sane user[1] inserts spaces into any file name.
If the file system allows it, then why not? Other than giving CLI-
based tools fits, that is.
Keith Thompson
> Keith Thompson wrote:
>> Boon <root@localhost> writes:
>>> Mark wrote:
>>>> Jacob wrote:
>>>>> Keith wrote [that *windows* lcc-win doesn't understand popen...]
>>>>>
>>>>> Obviously I am using Unix lcc-win,
>>>>
>>>> Did you say that? What makes it obvious?
>>>
>>> popen was a dead giveaway.
>>
>> popen was a dead giveaway that the program was intended for a
>> Unix-like system. I suppose jacob's name at the top was probably a
>> dead giveaway that some variant of lcc-win was being used, but I
>> didn't want ot make that assumption.
>
> I thought the "../lcc" in the `system` argument was a bit of a giveaway.
Yeah, that too.
Richard Heathfield
Flash Gordon
> jacob navia <ja...@nospam.org> writes:
>
>> 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.
>
> Well it only took about 2 follow-ups to this thread before it was smashed
> by those complaining about Jacob, lcc, the mantra of the newsgroup -
> and it wouldn't be a real thread without ggets getting a run...
>
> Unsurprisingly, hardly any comments about the actual subject of the thread.
Before you can compare implementations of a scripting job in different
languages you first have to get the requirements for the scripts and
working versions of the scripts.
> I haven't used it recently, but it would seem very easy to develop a
> C-interpreter (for some people's understanding of 'C') using the Ch
> embeddable interpreter: http://www.softintegration.com/
>
> This seems a better approach than compiling C code snippets on the fly.
Or simply use a C-like language designed for scripting such as csh or tcsh
--
Flash Gordon
Han from China
> I understand the "one program" description
> to be the full list of minimum implementation limits.
I wish it could be, but all the standard says is
The implementation shall be able to translate and execute at least
one program that contains at least one instance of every one of
the following limits
So a conforming C implementation can meet its obligations by
translating and executing oneprogram.c. This says nothing about
any other programs. There's a footnote to the above, but footnotes
aren't normative.
> That would be simpler if popen were declared in a nonstandard header.
> But being declared in stdio.h, it prevents me from defining
> my own popen in a program which #includes <stdio.h>
> and that's what Keith was taliking about.
Granted, it may not be the best choice, but a conforming C implementation
is allowed to declare popen() in stdio.h. This won't clash with any
strictly conforming program, since the standard allows the conforming
C implementation to decide what is and is not a strictly conforming
program.
Let's look at the conforming C implementation on the DS9K. You hand
it what you believe to be a strictly conforming program that uses
your own popen(). The DS9K says, "Nope, this program exceeds one
of my minimum implementation limits and therefore isn't strictly
conforming. So if this program's popen() clashes with my own popen()
in stdio.h, that doesn't matter, since I'm still following my
obligations as a conforming C implementation -- all I'm required
to do is accept strictly conforming programs and not alter their
behavior, but this program you've handed me isn't a strictly
conforming program, because it violates one of my minimum implementation
limits."
Yours,
Han from China
--
"Only entropy comes easy." -- Anton Chekhov
Mark McIntyre
>
> You do not know what C is dude
You're actually a worse troll in many ways that Han, Kenny and the rest.
> [snip drivel]
Actually, as far as I can see, you /inserted/ drivel.
> Obviously the regs here do not understand the purpose of scripting.
If you think /that/, then you're even more foolish than your posts
generally indicate.
> By the way, the same code runs under lcc-win under windows.
Good...
> You should
> just change the "ls" to "dir /b" and the rest is the same.
Ah - this is a different definition of "same" to the usual one ?
> ANd I will go on posting code here whenever I feel like it.
Indeed you can. But equally other people can critique it and point out
errors in your code whenever they feel like it.
> Other people
> (like Gordon) can't do that. He has never posted a single line here.
> The same for all other "regs" complaining their usual nonsense.
That's a complete and total lie. To mention but one, I've frequently
posted code here. So have all the other regs I can think of.
> The are unable to do anything constructive and limit themselves to
> pissing around other people.
Perhaps you ought to grow up.
--
Mark McIntyre
CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Mark McIntyre
>> errors setting up that pipe, eh?
>>
>
> It would be highly surprising that in a directory where
> there are 600 .c files that doesn't work...
Did you check what happened when you had execute but not read perms in
the directory?
By the way, your unnamed but apparently chosen OSen can't /have/ 600
files in one directory, not with the version you've secretly selected.
>> This will incorrectly interpret filenames which contain newline
>> characters as the names of two or more separate files (which may or may
>> not exist).
>
> Sure. And I do not care.
Which kinda invalidates your point - the C version doesn't do what the
Ruby one does when it encounters these files.
> And if you put 8 backspaces
> in a file name it will be kind of invisible duh!
Whats with the magic eight?
Apparently you have no experience of operating systems newer than 1995.
> > It will also silently do something wrong on very long file
>> names (namely to split the file name into 511-byte chunks, with a short
>> trailing chunk, and treat each chunk as a separate name).
>>
>
> And I do not care either since I know that all file names are
> exactly 8 chars long, and with 512 I have enough leeway.
Again, apparently you're limited to CPM or MSDOS. Was this another of
the unstated assumptions at the beginning?
> What the regs do not understand is that a script tailored for
> a given situation and in a given context is NOT a general
> program to compile and run all C files in a given directory.
Absolutely. A script intended for a specific case is intended for a
specficic case.....
Tautology, thy name is logical fallacy.
If you make a general statement like "bread is sweet and contains eggs",
and then limit your experimental evidence to Brioche, don't be surprised
if someone mentions Naan, Roti, sourdough as counterexamples....
Mark McIntyre
> jfbod...@gmail.com said:
>
>> On Mar 27, 3:23 am, Richard Heathfield <r...@see.sig.invalid>
>> wrote:
>>> Ian Collins said:
>>>
>>> <snip>
>>>
>>>> It will still fail with file names with spaces, but no sane
>>>> developer has spaces in source file names, do they?
>>> No sane user[1] inserts spaces into any file name.
>> If the file system allows it, then why not? Other than giving
>> CLI- based tools fits, that is.
>
> That sounds like a pretty good reason all on its own.
It doesn't bother any of the CLI-based tools on my computers...
ls -1 | while read i ; do file "$i" ; done
a file with spaces in.bat: ASCII text
C: directory
CTX.DAT: Java serialization data, version 5
My Pictures: directory
My Videos: directory
wibble.sh: POSIX shell script text executable
luserXtrog
wrote:
> Richard Heathfield wrote:
WHY DO ONES LOOK LIKE ELLS?
arrgggh.
Nice script, though. If I do that a few more times, I might just
remember the shell syntax for a loop.
--
lxt
Ian Collins
> jacob navia wrote:
>
>> The are unable to do anything constructive and limit themselves to
>> pissing around other people.
>
> Perhaps you ought to grow up.
>
--
Ian Collins
Azazel
<ot>
Read an interesting essay by David Wheeler on this subject recently:
http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html
</ot>
--
Az.
www: http://www.azazel.net/
pgp: http://www.azazel.net/~azazel/az_key.asc
Ian Collins
> Nice script, though. If I do that a few more times, I might just
> remember the shell syntax for a loop.
Which shell!
--
Ian Collins
CBFalconer
> Boon wrote:
>> Mark wrote:
>>> Jacob wrote:
>>>
>>>> Obviously I am using Unix lcc-win,
>>>
>>> Did you say that? What makes it obvious?
>>
>> popen was a dead giveaway.
>
> As it was the use of "ls" :-)
Oh? I can use 'ls' on this Winders machine. Quoted to avoid wrap.
> [1] c:\>ls
> 4dos/ asm/ cygwin/ hwinfo/ prgs/
> Aladdin/ autoexec.6-4 desclist.txt hwmanual/ rh_opt.gdt
> AutoExec.bat autoexec.old detlogo.txt indent.pro rh_opt.gpr
> Exactime.ini autoexec.sav disks/ jpstree.idx save/
> Ghostgum/ backup.lfn djgpp/ linux/ sbcdr/
> My Documents/ bakups/ dnld/ logs/ scandisk.log
> Netscape/ c/ docs/ lynx/ setupxlg.txt
> Program Files/ cbm/ dos622/ misc/ shutdown.bak
> PwrQuest/ cdroms/ faq/ mspgcc/ stds/
> TextPad/ cfiles/ fp5.ini netlog.txt sysdirs.lst
> USRobot/ command.com fpc/ orig/ util/
> WINDOWSWinHlp32.BMK config.6-4 fpfiles/ p/ validate.lst
> Wincupl/ config.sav frunlog.txt pcd/ w9secret/
> _bhist config.sys games/ perl/ windows/
> alfred.gif cpm/ hidedirs.lst pp/
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer
> William Pursell wrote:
>
>> So there is another concrete characteristic of a "reg". Someone
>> who has never posted any code to the group. I had previously
>> concluded that the "regulars" consists solely of CBF, but
>> clearly the group of "regulars" is completely empty.
>
> 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
>>> Ian Collins said:
>>>
>>> <snip>
>>>
>>>> It will still fail with file names with spaces, but no sane
>>>> developer has spaces in source file names, do they?
>>>
>>> No sane user[1] inserts spaces into any file name.
>>
>> If the file system allows it, then why not? Other than giving
>> CLI- based tools fits, that is.
>
> That sounds like a pretty good reason all on its own.
Just an interesting statistic. Jacob was the OP at 3:15 pm
yesterday, EST. As of roughly 10 pm EST today that has generated
64 messages. I have not tried to count the number that contained
worthwhile information, but I guarantee is is considerably less.
Incidentally, I agree that sanity requires non-insertion of spaces
in file names.
CBFalconer
>
> CBFalconer wrote:
> > jacob navia wrote:
> >> 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.
> >>
> >> 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.
pete
> pete wrote:
>> I understand the "one program" description
>> to be the full list of minimum implementation limits.
>
> I wish it could be, but all the standard says is
>
> The implementation shall be able to translate and execute at least
> one program that contains at least one instance of every one of
> the following limits
>
> So a conforming C implementation can meet its obligations by
> translating and executing oneprogram.c. This says nothing about
> any other programs. There's a footnote to the above, but footnotes
> aren't normative.
I try to understand the standard as best as I can,
but I have to admit that I have actually given up on trying to grok
the oneprogram part of the standard.
--
pete
Han from China
> You're actually a worse troll in many ways that Han, Kenny and the rest.
Please don't troll this newsgroup. Surely you predicted the noisy
reaction to the above statement, so one has to wonder why you're
interested in inviting noise to this newsgroup.
> To mention but one, I've frequently posted code here. So have all the
> other regs I can think of.
That depends on your definition of "code", doesn't it? I suggest you,
Gordon, and Thompson present your best programs, and we'll compare
your accomplishments with those of a compiler writer. Heathfield
has already published his best program -- a tiny, bug-ridden
"error-message handler" on his Web site. Otherwise, it's fair to
conclude that the "regs" (see my "regs" set earlier) are shitty
C programmers like me and that they're just trying to feel big
by nitpicking at the statements of a compiler writer (anyone can
nitpick).
But the fact is that you hardly ever discuss C on this newsgroup. All
you do these days is contribute noise. That's because you don't know
C, as your posting history indicates. You got sick of the smackdowns
exposing your ignorance, so you thought you'd be better off limiting
yourself to being a clueless lackey and barking dog.
Barky Mark! *woof* *woof* *woof*
Han from China
> Obviously I am using Unix lcc-win
Yes, you made that obvious in your initial post when you wrote
I wrote the C program, and a friend wrote the ruby program. It was
for testing the *Unix version of lcc-win*, i.e. both programs are
used in a "production" setting.
I suggest you ignore Thompson's passive-aggressive trolling.
Han from China
>> Obviously I am using Unix lcc-win,
>
> Did you say that? What makes it obvious?
In his initial post when he wrote
I wrote the C program, and a friend wrote the ruby program. It was
for testing the *Unix version of lcc-win*, i.e. both programs are
used in a "production" setting.
You dumb troublemaker.
Keith Thompson
> Flash Gordon wrote:
>> CBFalconer wrote:
>> > 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.
Keith Thompson
[...]
> I try to understand the standard as best as I can,
> but I have to admit that I have actually given up on trying to grok
> the oneprogram part of the standard.
The standard attempts to enforce reasonable capacity limits for C
implementations, so that a compiler that, for example, rejects any
non-empty translation unit as being too big cannot claim conformance.
The problem is that there's no good way to define "reasonable" in this
context. How many nested #include levels can a compiler support? How
many declarations? How long an input line, or string literal, or
identifier? It's going to depend on the internal details of the
compiler's implementation. Furthermore, typical compilers use
dynamically allocated data structures for most things, so a compiler
that can handle some number of nested blocks might choke on fewer if
the program also contains very complex expressions; the internal data
structures for both are allocated from the same memory pool. There's
no clear dividing line between programs that are small enough that any
compiler should be able to handle them, and programs that are big
enough that a compiler isn't required to handle it.
The committee's solution is C99 5.2.4.1, Translation limits:
The implementation shall be able to translate and execute at least
one program that contains at least one instance of every one of
the following limits:
followed by a page or so of specific numeric requirements.
This "one program" is not really the point; such a program would be so
artificially contrived that it's extremely unlikely it would be
useful.
The point is that the easiest way to satisfy 5.2.4.1 is to create an
implementation that actually behaves reasonably on real-world code;
the ability to handle the "one program" is then a side effect. The
committee couldn't write all the rules to require compilers to have
reasonable capacity limitations in all cases, so they imposed a single
narrow requirement that has the effect of forcing implementers to do
the job themselves.
(Someone could create a pseudo-compiler that specifically recognizes a
chosen "one program" and rejects everything else. In fact, I'm almost
tempted to do it myself. But such an "implementation", though it
might meet the letter of the standard, would be useless, and it
wouldn't compete with real implementations.)
Han from China
> The problem is that there's no good way to define "reasonable" in this
> context. How many nested #include levels can a compiler support? How
> many declarations? How long an input line, or string literal, or
> identifier? It's going to depend on the internal details of the
> compiler's implementation. Furthermore, typical compilers use
> dynamically allocated data structures for most things, so a compiler
> that can handle some number of nested blocks might choke on fewer if
> the program also contains very complex expressions; the internal data
> structures for both are allocated from the same memory pool. There's
> no clear dividing line between programs that are small enough that any
> compiler should be able to handle them, and programs that are big
> enough that a compiler isn't required to handle it.
Granted, but the fact is the standard is letting the compiler decide
what is and is not a strictly conforming program. Through the chain of
reasoning I've outlined in a reply to pete, this lets a conforming C
implementation place a declaration of popen() in stdio.h. That
contradicts your statement that implies a conforming C implementation
can't do so.
> The committee's solution is C99 5.2.4.1, Translation limits:
>
> The implementation shall be able to translate and execute at least
> one program that contains at least one instance of every one of
> the following limits:
>
> followed by a page or so of specific numeric requirements.
>
>
> This "one program" is not really the point; such a program would be so
> artificially contrived that it's extremely unlikely it would be
> useful.
Yes, but as you know, the standard defines those minimums for only
that one program.
> The point is that the easiest way to satisfy 5.2.4.1 is to create an
> implementation that actually behaves reasonably on real-world code;
> the ability to handle the "one program" is then a side effect.
What's "reasonable" is a subjective assessment. Everyone on this
newsgroup would have a different assessment of what's "reasonable".
We have to stick with the standard to achieve objectivity.
> The committee couldn't write all the rules to require compilers to have
> reasonable capacity limitations in all cases, so they imposed a single
> narrow requirement that has the effect of forcing implementers to do
> the job themselves.
And in the process forcing implementors to decide what constitutes
a strictly conforming program and what doesn't. That basically kills
the entire notion of a strictly conforming program.
> (Someone could create a pseudo-compiler that specifically recognizes a
> chosen "one program" and rejects everything else. In fact, I'm almost
> tempted to do it myself. But such an "implementation", though it
> might meet the letter of the standard, would be useless, and it
> wouldn't compete with real implementations.)
Again, what's useful, "useless", or a "real" implementation is something
about which everyone on this newsgroup would have a different opinion.
We have to stick with the standard to achieve objectivity... remember?
James Kuyper
> Flash Gordon wrote:
>> CBFalconer wrote:
>>> 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.
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
Han from China
> Granted, it may not be the best choice, but a conforming C implementation
> is allowed to declare popen() in stdio.h. This won't clash with any
> strictly conforming program, since the standard allows the conforming
> C implementation to decide what is and is not a strictly conforming
> program.
I should point out that the intent of my argument is not to say that a
conforming C implementation can *reject* virtually every program by
considering virtually every program not to be strictly conforming based on
some "output" dependency or "minimum implementation limit", even though
that's possible; the intent of my argument is rather to say that a
conforming C implementation can *accept* virtually every C program,
provided that the virtually empty set of strictly conforming programs is
accepted and there are no behavior alterations. In particular, an
implementation can declare popen() in stdio.h and still be a conforming C
implementation.
Let's make this more concrete. Here's a challenge: Suppose I have an
implementation that declares popen() in stdio.h. My implementation accepts
all strictly conforming programs, as defined in and required by 4{5} and
4{6} of the latest C99 draft. The challenge is to post a strictly
conforming program whose behavior would be altered by my implementation.
If this challenge is met, then my implementation isn't a conforming C
implementation and my entire argument is gunned down. If this challenge is
not met, then I maintain that I have a conforming C implementation. Any
takers?
pete
I didn't really understand your argument.
This is what I was thinking of:
/* BEGIN new.c */
#include <stdio.h>
int popen(void)
{
return 0;
}
int main(void)
{
return popen();
}
/* END new.c */
--
pete
Han from China
> /* BEGIN new.c */
>
> #include <stdio.h>
>
> int popen(void)
> {
> return 0;
> }
>
> int main(void)
> {
> return popen();
> }
>
> /* END new.c */
OK, my implementation doesn't consider that a strictly conforming
program, since it violates the following necessary condition for
a strictly conforming program, as defined in 4{5}:
It shall not produce output dependent on any unspecified,
undefined, or implementation-defined behavior.
My implementation considers a return status from main() to be
output.
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
> jacob navia <ja...@nospam.org> wrote:
>
>> 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.
>
I do not understand why you post then...
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Richard Bos
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
> On 2009-03-27, jfbod...@gmail.com <jfbod...@gmail.com> wrote:
> > If the file system allows it, then why not? Other than giving CLI-
> > based tools fits, that is.
>
> <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
> Richard Bos wrote:
> > jacob navia <ja...@nospam.org> wrote:
> >
> >> 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.
>
> 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
Richard
Non portable code is NOT off topic here. This group is dedicated to the
discussion of the C programming language. And I have seen plenty of C
programs which are not portable despite being written in Ansi C.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
CBFalconer
> CBFalconer wrote:
>> Flash Gordon wrote:
>>> CBFalconer wrote:
> ...
>>>> 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,
>
> 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
> Richard Bos wrote:
>> jacob navia <ja...@nospam.org> wrote:
>>
>>> 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.
>
> I do not understand why you post then...
Here I have a period of agreement with you. Rare, but useful.
pete
> pete wrote:
>> /* BEGIN new.c */
>>
>> #include <stdio.h>
>>
>> int popen(void)
>> {
>> return 0;
>> }
>>
>> int main(void)
>> {
>> return popen();
>> }
>>
>> /* END new.c */
>
> OK, my implementation doesn't consider that a strictly conforming
> program, since it violates the following necessary condition for
> a strictly conforming program, as defined in 4{5}:
>
> It shall not produce output dependent on any unspecified,
> undefined, or implementation-defined behavior.
>
> My implementation considers a return status from main() to be
> output.
The return value is zero.
The return value is not dependent on anything.
--
pete
Han from China
> Han from China wrote:
>> program, since it violates the following necessary condition for
>> a strictly conforming program, as defined in 4{5}:
>>
>> It shall not produce output dependent on any unspecified,
>> undefined, or implementation-defined behavior.
>>
>> My implementation considers a return status from main() to be
>> output.
>
> The return value is zero.
> The return value is not dependent on anything.
7.20.4.3{5}:
If the value of status is zero or EXIT_SUCCESS, an implementation-
defined form of the status successful termination is returned.
So the return status of zero depends on implementation-defined
behavior. This means the program can't be strictly conforming,
according to 4{5}.
Note: Again, this isn't "trolling". The argument is not new. Many
on this newsgroup (including James Kuyper, I believe) and on comp.std.c
have made the same argument in the past, but to my knowledge, it's
never been resolved.
Such arguments let us reduce the set of strictly conforming programs
(if there are any) to the point where no strictly conforming program
is going to clash with the inclusion of a popen() declaration in
stdio.h. Thus, a conforming C implementation is permitted to declare
popen() in stdio.h.
Yours,
Flash Gordon
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.
--
Flash Gordon
Joe Wright
> Keith Thompson wrote:
> He wrote that *windows* lcc-win doesn't understand popen...
>
> Obviously I am using Unix lcc-win, that knows about popen
> in /usr/include/stdio.h
>
Shouldn't that be lcc-nix or lcc-nux? Or does it need wine?
--
Joe Wright
"Memory is the second thing to go. I forget what the first is."
jacob navia
> jacob navia wrote:
>> Keith Thompson wrote:
>> He wrote that *windows* lcc-win doesn't understand popen...
>>
>> Obviously I am using Unix lcc-win, that knows about popen
>> in /usr/include/stdio.h
>>
> 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!
Richard Bos
> My implementation considers a return status from main() to be
> output.
Your implementation does not get to consider that, since the section on
<stdio.h> defines what output is, in the context of the C Standard.
Since the return value from main() does not go to a stream (at least not
within C), it is not output.
Richard
James Kuyper
> James Kuyper wrote:
>> CBFalconer wrote:
>>> Flash Gordon wrote:
>>>> CBFalconer wrote:
>> ...
>>>>> 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.
>> 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.
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.
Richard
> James Kuyper wrote:
>> CBFalconer wrote:
>>> Flash Gordon wrote:
>>>> CBFalconer wrote:
>> ...
>>>>> 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.
>>
>> 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.
Wrong. There is nothing in the remit of this group which limits code to
the C standard. And when YOU do not know what the functions called are
does not mean others do not. And since they might be written in
"standard C" even a ridiculous old busy body like you should accept it.
This group is to help C programmers of all levels on all platforms. If
you can not then please do not post anything. Thank you.
If you wish to suggest a "standards compliant" alternative then that is
quite another thing.
Malcolm McLean
"Keith Thompson" <ks...@mib.org> wrote in message
> 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.
>
non-standard library that it calls, or if it is written in such an eccentric
dialect of C as to be no longer really C at all.
Most real world C programs are non-portable, because of the standard
library's very restricted IO capabilities. No mine, incidentally. Most of my
C programs depend only on the standard library, because they are utiltities
to deal with molecular model files.
Han from China
> Your implementation does not get to consider that, since the section on
> <stdio.h> defines what output is, in the context of the C Standard.
> Since the return value from main() does not go to a stream (at least not
> within C), it is not output.
If that's the case, then it should be easy for you to quote that
section of the C Standard and show why a conforming C implementation
isn't allowed to consider the return status from main() as a form of
output. I'm not interested in your personal interpretations; I'm
interested in what the C Standard actually says.
Kenny McCormack
Han from China <autistic...@comp.lang.c> wrote:
>> Your implementation does not get to consider that, since the section on
>> <stdio.h> defines what output is, in the context of the C Standard.
>> Since the return value from main() does not go to a stream (at least not
>> within C), it is not output.
>
>If that's the case, then it should be easy for you to quote that
>section of the C Standard and show why a conforming C implementation
>isn't allowed to consider the return status from main() as a form of
>output. I'm not interested in your personal interpretations; I'm
>interested in what the C Standard actually says.
Infinite reducibility...
(Strikes again...)
Han from China
> Infinite reducibility...
>
> (Strikes again...)
Indeed. I'm still trying to figure out why a conforming C implementation
can't declare popen() in stdio.h, as Keith implies. Certainly that
view isn't supported by the standard.
What's happening is a case of "selective pedantry": if an exact
reading of the standard conflicts with topicality or an attack on
a compiler writer, be "practical" and consider "real-world"
implementations; otherwise, use exact readings to attack that
compiler writer and newcomers or to revel in such marvels as why,
for instance, (void *)0 is a null pointer constant but ((void *)0)
isn't.