Web programming in C lang with TCC

[lovecreatesbeauty]

$ cat /usr/lib/cgi-bin/ex1.c
#!/usr/local/bin/tcc -run

#include <tcclib.h>

int main(void)
{
printf("Content-type: text/html\r\n\r\n");
printf("Hello <a href=\"http://bellard.org/tcc/\">TCC</a> cgi
\n");

return 0;
}
$

Screenshot:
https://gknszq.bay.livefilestore.co...P6NGMFXem425vYBBi4JhJJdC5D/tcc_cgi.JPG?psid=1

 

[Mark Bluemel]

$ cat /usr/lib/cgi-bin/ex1.c
#!/usr/local/bin/tcc -run

#include<tcclib.h>

int main(void)
{
printf("Content-type: text/html\r\n\r\n");
printf("Hello<a href=\"http://bellard.org/tcc/\">TCC</a> cgi
\n");

return 0;
}
$

Screenshot:
https://gknszq.bay.livefilestore.co...P6NGMFXem425vYBBi4JhJJdC5D/tcc_cgi.JPG?psid=1

Did you have a question or a point to make?

 

[lovecreatesbeauty]

Did you have a question or a point to make?

Thanks for posting.

I mean I posted this one "The end of C-like script languages - C
script with TCC" some days ago.

People seems don't believe the C can be directly used in web
programming

I wish C (with TCC) eat up PHP, Perl, ..

 

[Angel]

People seems don't believe the C can be directly used in web
programming

CGI programs written in C have been around longer than PHP and Perl
have, I think.

 

[Tom St Denis]

$ cat /usr/lib/cgi-bin/ex1.c
#!/usr/local/bin/tcc -run

#include <tcclib.h>

int main(void)
{
       printf("Content-type: text/html\r\n\r\n");

i think in some pc, in some compiler, in some OS: "\n\n" could be sufficient
but if above there is "\r\n" than below there is need of "\r\n" too;
[and this is not here]

Not only is this ridiculously OT, but in HTTP you must send \r\n\r\n
to indicate two blank lines REGARDLESS of your platform hosting or
consuming content.

so for me it should be the file as
--------------
// file name page.c
#include <stdio.h>

int main(void)
{printf("Content-type: text/html \n\n");
 printf("Hello <a href=\"http://bellard.org/tcc/\">TCC</a> cgi\n");
 return 0;}

Except this won't work, and you'd know that if you tested it (any half
decent web server would reject the CGI output and issue an error).

Tom

 

[Keith Thompson]

I mean I posted this one "The end of C-like script languages - C
script with TCC" some days ago.

People seems don't believe the C can be directly used in web
programming

I don't think anyone has ever suggested that it's not possible.
And for generating static content, as your program does, it probably
works as well as any other language -- though not as well as just
creating an html file in the right place.

For other purpose, scripting languages offer much easier string
handling, which is a considerable advantage in this context.

I wish C (with TCC) eat up PHP, Perl, ..

By all means, wish away.

 

[lovecreatesbeauty]

I don't think anyone has ever suggested that it's not possible.
And for generating static content, as your program does, it probably
works as well as any other language -- though not as well as just
creating an html file in the right place.

Thank you.

I tried some more examples with TCC just now tonight (01:25 dark and
silent morning like the night here.

You're right. TCC presents static pages easily but lacks of session
management. And PHP features like $_GET['x'], $_POST['x'] are missing
from TCC currently. Maybe someone will contribute on this area for
TCC. Can this guy be me

For other purpose, scripting languages offer much easier string
handling, which is a considerable advantage in this context.

TCC seems can use the whole C library as well as the stdio.h and
string.h. I think the string operation function are not a problem for
TCC to succeed on web.

 

[lovecreatesbeauty]

CGI programs written in C have been around longer than PHP and Perl
have, I think.

With TCC, the request points directly to the .c source file
http://192.168.122.199/cgi-bin/a.c
not something like
http://192.168.122.199/cgi-bin/a.out
or
http://192.168.122.199/cgi-bin/a.sh

I may be wrong.

 

[lovecreatesbeauty]

For other purpose, scripting languages offer much easier string
handling, which is a considerable advantage in this context.

I think by now C scripting with TCC can at least kick Perl out of
stage

By all means, wish away.

What's your opinion on TCC's ability of making C a power script tool?
C is great and should be used everywhere.

 

[lovecreatesbeauty]

No more weird languages like Perl, Pythod, Ruby, PHP, ..blah..

 

[Dr Nick]

$ cat /usr/lib/cgi-bin/ex1.c
#!/usr/local/bin/tcc -run

#include <tcclib.h>

int main(void)
{
       printf("Content-type: text/html\r\n\r\n");

i think in some pc, in some compiler, in some OS: "\n\n" could be sufficient
but if above there is "\r\n" than below there is need of "\r\n" too;
[and this is not here]

Not only is this ridiculously OT, but in HTTP you must send \r\n\r\n
to indicate two blank lines REGARDLESS of your platform hosting or
consuming content.

Hmm. I'm not convinced. Of course, when the HTTP is sent from the
server it has to have carriage-return line-feed (I'm not using \n for
very deliberate reasons here) but I think the server is perfectly at
liberty to take any line separation it wants on the incoming from the
cgi.

Indeed, I just went and looked at RFC 3875 and it just says the header
and body must be "separated by a blank line".

There's a good reason for this, of course. C is quite at liberty to
take your \r\n\ and turn it into - say - carriage-return carriage-return
line-feed.

Still OT, but at least correct now. I've got good reasons for knowing
this.

 

[Keith Thompson]

I think by now C scripting with TCC can at least kick Perl out of
stage

That hardly seems likely.

What's your opinion on TCC's ability of making C a power script tool?
C is great and should be used everywhere.

C is great for some things (implementing Perl, for example), but not for
everything. I'd go into more detail, but I'm not interested in a
language flame war.

It's always been possible to do CGI in C; just write a C program that
produces HTML, compile it, and put the executable in the right place on
the server. TCC seems to add the ability to use the source file
directly, which might be convenient, but I don't see that it's that big
an advantage.

If it works for you, that's great. If you expect it to be a
Perl-killer, you're going to be disappointed.

 

[Tom St Denis]

"lovecreatesbeauty" <[email protected]> ha scritto nel messaggio
$ cat /usr/lib/cgi-bin/ex1.c
#!/usr/local/bin/tcc -run
#include <tcclib.h>
int main(void)
{
       printf("Content-type: text/html\r\n\r\n");
i think in some pc, in some compiler, in some OS: "\n\n" could be sufficient
but if above there is "\r\n" than below there is need of "\r\n" too;
[and this is not here]

Not only is this ridiculously OT, but in HTTP you must send \r\n\r\n
to indicate two blank lines REGARDLESS of your platform hosting or
consuming content.

Hmm.  I'm not convinced.  Of course, when the HTTP is sent from the
server it has to have carriage-return line-feed (I'm not using \n for
very deliberate reasons here) but I think the server is perfectly at
liberty to take any line separation it wants on the incoming from the
cgi.

Indeed, I just went and looked at RFC 3875 and it just says the header
and body must be "separated by a blank line".

There's a good reason for this, of course.  C is quite at liberty to
take your \r\n\ and turn it into - say - carriage-return carriage-return
line-feed.

Still OT, but at least correct now.  I've got good reasons for knowing
this.

Um, things like Apache expect both characters and most platforms do
not turn \n into two characters. Indeed sizeof("\n") is 2 ...
always. Where things differ is what \n DOES.

So no, for a conforming C CGI application your HTTP headers must end
each line with \r\n.

Modern servers/browsers might "put up with" just \n, but my experience
with IIS and Apache is that \r\n is what they required lest you get an
error.

More so, it is wicked off topic and completely not news. Indeed my
first CGI applications were all in C way back when. It was just
faster. Then I realized that perl was infinitely better at working
with textual data...

Tom

 

[Dr Nick]

"lovecreatesbeauty" <[email protected]> ha scritto nel messaggionews:3617d215-8302-4044-bed7-0e4d50038203@r35g2000prj.googlegroups.com...

$ cat /usr/lib/cgi-bin/ex1.c
#!/usr/local/bin/tcc -run

#include <tcclib.h>

int main(void)
{
       printf("Content-type: text/html\r\n\r\n");

i think in some pc, in some compiler, in some OS: "\n\n" could be sufficient
but if above there is "\r\n" than below there is need of "\r\n" too;
[and this is not here]

Not only is this ridiculously OT, but in HTTP you must send \r\n\r\n
to indicate two blank lines REGARDLESS of your platform hosting or
consuming content.

Hmm.  I'm not convinced.  Of course, when the HTTP is sent from the
server it has to have carriage-return line-feed (I'm not using \n for
very deliberate reasons here) but I think the server is perfectly at
liberty to take any line separation it wants on the incoming from the
cgi.

Indeed, I just went and looked at RFC 3875 and it just says the header
and body must be "separated by a blank line".

There's a good reason for this, of course.  C is quite at liberty to
take your \r\n\ and turn it into - say - carriage-return carriage-return
line-feed.

Still OT, but at least correct now.  I've got good reasons for knowing
this.

Um, things like Apache expect both characters and most platforms do
not turn \n into two characters. Indeed sizeof("\n") is 2 ...
always. Where things differ is what \n DOES.

So no, for a conforming C CGI application your HTTP headers must end
each line with \r\n.

Modern servers/browsers might "put up with" just \n, but my experience
with IIS and Apache is that \r\n is what they required lest you get an
error.

More so, it is wicked off topic and completely not news. Indeed my
first CGI applications were all in C way back when. It was just
faster. Then I realized that perl was infinitely better at working
with textual data...

No-no-no, I'm afraid you're wrong (apart from saying it's OT!). cgi to
server is RFC 3875, not HTTP. What you send might look like HTTP
headers, and might end up as HTTP headers, but it's not HTTP.

And Apache is perfectly happy getting a \n and has been for 10+ years
IME.

How do you write a C program that will always send carriage-return,
line-feed and nothing else?

My cgi is in C, but it runs a scripting language because - as you say -
you have an awful lot of strings to deal with.

 

[Keith Thompson]

How do you write a C program that will always send carriage-return,
line-feed and nothing else?

[...]

Probably by setting the output stream to binary mode and writing "\r\n".

 

[Seebs]

I think by now C scripting with TCC can at least kick Perl out of
stage

I don't.

What's your opinion on TCC's ability of making C a power script tool?
C is great and should be used everywhere.

Frankly... I think it's stupid, and won't work.

Look, it's not that I don't like C. I love C. But this is not what C
is good at. C is not really a great language for expressive string
manpulation. C is good for back-end stuff, but it's simply not a good
choice for the kinds of things we use scripting languages for.

It's like watching someone who's working on replacing screws with nails
on the grounds that he really likes using a hammer, and screws don't
hammer very well.

The fact is, even a very good C programmer will not be able to compete
effectively with someone using a more appropriate language for this kind
of thing. It's a waste of energy.

I don't want to give the impression that it's an unheard of waste of
energy; I wrote a wrapper program which "interpreted" C about twenty years
ago. It was an interesting curiousity; it was not useful.

-s

 

[Seebs]

No more weird languages like Perl, Pythod, Ruby, PHP, ..blah..

I don't much care for some of those, but...

For the sorts of things usually done with CGI, I can run rings around C
in any of them. (And I say this as someone who has done CGI in C, and in
shell for that matter...)

-s

 

[Seebs]

Um, things like Apache expect both characters and most platforms do
not turn \n into two characters. Indeed sizeof("\n") is 2 ...
always. Where things differ is what \n DOES.

Pretty sure it'll be sizeof(char *), not sizeof(char[2]).

Not disputing the rest, although I think the one thing I've done in C
that did CGI emitted \n plain and it worked...

-s

 

[Ben Bacarisse]

Um, things like Apache expect both characters and most platforms do
not turn \n into two characters. Indeed sizeof("\n") is 2 ...
always. Where things differ is what \n DOES.

Pretty sure it'll be sizeof(char *), not sizeof(char[2]).

sizeof "\n" == 2 from 6.3.2.1 p3 (and 6.4.5 p5).

 

[Shao Miller]

Um, things like Apache expect both characters and most platforms do
not turn \n into two characters. Indeed sizeof("\n") is 2 ...
always. Where things differ is what \n DOES.

Pretty sure it'll be sizeof(char *), not sizeof(char[2]).

Not disputing the rest, although I think the one thing I've done in C
that did CGI emitted \n plain and it worked...

Then why was he so sure it'd be 2? Was it because of 6.4.5p5 and
6.3.2.1p3 and 6.5.3.4p3?