A C tutorial

[Richard Heathfield]

Your examples implied that the base character set of the implementation
is good enough for any text-based utility.

It's sufficient for clear communication to occur, yes.

It would be different if the target medium were paper (e.g. for a book, a
magazine article, or whatever); in those circumstances, it's appropriate to
use, say, PostScript or even PDF, or basically whatever the publishers want
- after all, they're the ones that have to print it. But when publishing
material on the Net, I see no reason arbitrarily to restrict one's audience
by choosing esoteric file formats.

 

[Richard Heathfield]

Dan Pop wrote:

I was talking about the one you claimed it concerned you: malicious code
in your utilities. It seems that, after all, it was a false concern...

I was talking about not trusting Adobe. You may think I am wrong not to
trust Adobe, and that this is a "false concern". That's up to you. But it's
for me to decide who /I/ will trust, rightly or wrongly. You can decide who
/you/ are going to trust, okay?

 

[Randy Howard]

Your example talks about Adobe Photoshop and the change in question does
not qualify as malicious code.

You're absolutely right. Sorry, I crossed up two different huge,
bloated, Adobe software packages in my head. I suppose it's only a
matter of time before it bleeds over into Acrobat, but for now it
seems not to be.

 

[Mark McIntyre]

Really?

Yes, really.

Show me.

Sure, for Eur 150/hour.

For example, please solve exercise 1-13 in K&R2, using a
PDF file instead of a text file as input. Please restrict yourself to those
parts of C introduced in those first 24 pages, to make it a fair
comparison.

As it happens, this is ludicrously easy. You need to think a little harder.

By the way, where did I mention that you could use only the first 24 pages
of K&R? If you choose to introduce artificial restrictions, then thats your
lookout.

 

[Mark McIntyre]

Yes, he did, but it's not as if I'm asking him to write a full reader. Just
a simple little word-length histogram program.

??? 1.13 asks me to return the lower case of the program's input, or the
input unmodified, should that not be a letter.

but your one (1.12) is just as easy. I'll define a word break as any
whitespace character in the input, and off I go.

If pdf processing is so
easy, he shouldn't find this to be a major challenge.

Its not.

But perhaps he has to
open a file or something, in which case I agree that the restriction would
be a bit harsh.

Pipe is your friend. After all, you can't process a text /file/ via the
same program without it.

But 1-13 is a different matter.

Its certainly a good attempt to change the subject from file readers to
something totally different. Nice try.

 

[Richard Heathfield]

Yes, really.


Sure, for Eur 150/hour.

Then it can hardly be as easy as you claim.

As it happens, this is ludicrously easy.

Prove it.

You need to think a little harder.

Nope. You are the one making the claim (that PDF processing is as easy as
text processing).

By the way, where did I mention that you could use only the first 24 pages
of K&R?

You didn't, but you said that PDF processing was as easy as text processing,
and I can solve K&R 1-13 using only the information presented in the first
24 pages of K&R. Still, as you say, it's quite an arbitrary restriction, so
I don't insist on it as long as the program remains relatively simple.

 

[Richard Heathfield]

??? 1.13 asks me to return the lower case of the program's input, or the
input unmodified, should that not be a letter.

Would this be the Mark McIntyre edition of K&R2, then?

K&R2, page 24: "Exercise 1-13. Write a program to print a histogram of the
lengths of words in its input..."

but your one (1.12) is just as easy. I'll define a word break as any
whitespace character in the input, and off I go.

Ex 1-12 asks you to print one word per line. Okay, so you say it's easy. So
why not demonstrate that it's easy?

Its not.

Prove it.

Pipe is your friend. After all, you can't process a text /file/ via the
same program without it.


Its certainly a good attempt to change the subject from file readers to
something totally different. Nice try.

Excuse me? It's not totally different /at all/. What's the matter - is it
suddenly hard to process PDF files? I thought you said it wasn't.

But okay, if you /think/ it's different, just show me a cat for PDF.
Presumably that's easy too, right?

 

[nrk]

Would this be the Mark McIntyre edition of K&R2, then?

K&R2, page 24: "Exercise 1-13. Write a program to print a histogram of the
lengths of words in its input..."


Ex 1-12 asks you to print one word per line. Okay, so you say it's easy.
So why not demonstrate that it's easy?


Prove it.



Excuse me? It's not totally different /at all/. What's the matter - is it
suddenly hard to process PDF files? I thought you said it wasn't.

But okay, if you /think/ it's different, just show me a cat for PDF.
Presumably that's easy too, right?

Actually, its not all that hard.

system("pdftotext file.pdf");
system("cat file.txt");

Smile. It's supposed to be funny. Seriously though, there is a utility
called pdftotext. It doesn't really do a great job in terms of rendering
readable text from pdf, but for purposes of solving the proposed exercise,
it should be enough to use this and pipe the output through your standard C
solution for text files

-nrk.

 

[Mark McIntyre]

Then it can hardly be as easy as you claim.

No, thats just my hourly rate for answering homework questions. if you
charge less, then maybe you can write it, sell it to me and I'll sell it
back to you at my rate...

Prove it.

Golly, prove that you can convert uppercase characters in a stream of data
into lowercase ones using only standard C? oooo thats tricky....

Nope. You are the one making the claim (that PDF processing is as easy as
text processing).

Indeed. But thats not what you asked me to do. You asked me to solve K&R2
1.13. Now in my copy thats
"write a program to convert its input to lower case, using a function
lower(c) which returns c if c is not a letter, and the lower case value of
c if it is a letter"

You didn't, but you said that PDF processing was as easy as text processing,
and I can solve K&R 1-13 using only the information presented in the first
24 pages of K&R.

Terriffic.

Still, as you say, it's quite an arbitrary restriction, so
I don't insist on it as long as the program remains relatively simple.

You'll have to point out where I said it would be a simple /program/. I
said that it was simple to /write/ a program. Call me a pedant if you
like.

 

[Mark McIntyre]

Ex 1-12 asks you to print one word per line. Okay, so you say it's easy. So
why not demonstrate that it's easy?

*sigh*

Are you clinically thick on this point? Here's the algo, you go implement
it.

assumptions
1) whitespace defines the end of a word.
2) there exists a file containing the data to process

read file char by char till find whitespace
print out whats been found so far
print out a newline
repeat search till end of file

Excuse me? It's not totally different /at all/.

Let me see:
I was talking about writing a file reader for pdfs in standard C.
You wanted me to answer some K&R exercise using only a subset of standard
C.

I'm struggling to spot the similarity here.

What's the matter - is it
suddenly hard to process PDF files? I thought you said it wasn't.
But okay, if you /think/ it's different, just show me a cat for PDF.
Presumably that's easy too, right?

Yup. You really are being clinically thick, aren't you?

 

[Mark McIntyre]

Actually, its not all that hard.

system("pdftotext file.pdf");
system("cat file.txt");

Smile. It's supposed to be funny. Seriously though, there is a utility
called pdftotext.

Oh, rats, you spoiled it.

Richard. Read back through my posts. See if you can spot where I said I
intended to convert the pdf into cutsey graphical output... my proposed
reader does nothing more sophisticated than determine the words in the pdf,
and print them to stdout.

I'm sorry, I've been taking the p*ss. But you deserved it, getting all on
your high horse about pdf being nonportable, you don't trust commercial
vendors etc. You've behaved like the worst sort of linuxhead geek mole,
obsessed with the idea that anything commercial is of necessity filled with
spyware, viruses and bad code, whereas free software simply *must* be
safe, reliable, and honest. And I *know* you're not like that at all
really.

 

[Richard Heathfield]

Actually, its not all that hard.

system("pdftotext file.pdf");
system("cat file.txt");

Smile. It's supposed to be funny.

Oh, it is. Highly amusing, in fact. Have the film rights gone?

Seriously though, there is a utility
called pdftotext. It doesn't really do a great job in terms of rendering
readable text from pdf, but for purposes of solving the proposed exercise,
it should be enough to use this and pipe the output through your standard
C solution for text files

No, not really. The output from pdftotext sucks. It's certainly not good
enough for comp.lang.c, IMHO. Furthermore, the availability of pdftotext
and cat is not guaranteed by ISO C, so your system() calls might fail to do
what is expected of them.

 

[Richard Heathfield]

*sigh*

Are you clinically thick on this point?

No. If you really, really think that I am, though, then there is no point
whatsoever in continuing this discussion.

Here's the algo, you go implement it.

I already did, for text files. You said processing PDFs is easy. I want you
to show me how easy it is, by answering a really, really simple exercise
using PDF instead of text as input. Is that so hard to understand?

Let me see:
I was talking about writing a file reader for pdfs in standard C.
You wanted me to answer some K&R exercise using only a subset of standard
C.

....specifically using a PDF file as input, rather than a normal text file.

Either you can process PDF data easily or you can't. Put up or shut up, as
the saying goes.

Yup. You really are being clinically thick, aren't you?

If you say so. Now, show me how clever you are - show me how to write a PDF
cat in ISO C. You may not assume that PDF processing facilities exist
elsewhere - i.e. system() calls to pdftotext and cat don't cut it.

 

[Richard Heathfield]

No, thats just my hourly rate for answering homework questions.

This isn't homework. You made a claim, and now you refuse to back it up. I
conclude that the claim is insupportable. If you think I'm wrong, *prove*
it.

Golly, prove that you can convert uppercase characters in a stream of data
into lowercase ones using only standard C? oooo thats tricky....

Learn To Read. Then Turn To Page 24 Of K&R2, And Read Exercise 1-13.

Note also that you are /not/ using a normal data stream, but a PDF file. It
is your program's job to interpret that file correctly so that the purposes
of the exercise are correctly satisfied.

Indeed. But thats not what you asked me to do.

Yes, it is.

You asked me to solve K&R2 1.13. Now in my copy thats
"write a program to convert its input to lower case, using a function
lower(c) which returns c if c is not a letter, and the lower case value of
c if it is a letter"

Then get a book that has the same 1.13 as everyone else's 1.13.

Terriffic.

The point, which you appear to have failed to grasp, is that text processing
in C is *easy*. You have claimed that PDF processing is easy, too, but you
apparently can't even solve a simple exercise using PDF input.

You'll have to point out where I said it would be a simple /program/. I
said that it was simple to /write/ a program. Call me a pedant if you
like.

I don't have to. You are destroying your own point, blunder by blunder.

Just as a reminder, here is what you claimed: "Its also easy to write tex to
dvi to pcl processors in standard C. Its also easy to write pdf readers in
standard C."

I remain unconvinced.

 

[Richard Heathfield]

Oh, rats, you spoiled it.

Richard. Read back through my posts. See if you can spot where I said I
intended to convert the pdf into cutsey graphical output...

I don't have to. You claimed PDF processing is easy, but you appear to be
incapable of supporting your claim.

my proposed
reader does nothing more sophisticated than determine the words in the
pdf, and print them to stdout.

In other words, you appear to be claiming now that PDF processing is so
difficult that the only way you can realistically use PDF data is to turn
it to text data first, and *hope* that the conversion utility got the
conversion right. The obvious strategy, then, is to store the data in text
format to begin with, thus neatly cutting out the middle man. Well done - I
knew you'd get there in the end.

I'm sorry, I've been taking the p*ss.

If you must do that, please learn how to do it properly.

 

[nrk]

Oh, it is. Highly amusing, in fact. Have the film rights gone?

Not yet. You know how to reach me if you're interested. As an added
incentive, I promise to try not to deliver the script to you in PDF format.

No, not really. The output from pdftotext sucks. It's certainly not good
enough for comp.lang.c, IMHO. Furthermore, the availability of pdftotext
and cat is not guaranteed by ISO C, so your system() calls might fail to
do what is expected of them.

Wot eez deez PDF in ISO C? Sorry, I'll stop now. ;-)

-nrk.

 

[Mark McIntyre]

This isn't homework. You made a claim, and now you refuse to back it up. I
conclude that the claim is insupportable. If you think I'm wrong, *prove*
it.

Richard, I'm not playing this game with you any longer. Its patently
obvious that to write a PDF interpreter in standard C is not a hard task. I
don't have to prove anything and I suspect that most regulars here could do
it standing on their heads. If you can't (and I'm quite sure you can) then
thats surprising.

Learn To Read. Then Turn To Page 24 Of K&R2, And Read Exercise 1-13.

Learn to Understand. In my copy of K&R, page 24 begins:
"caller, as does "falling off the end" of a fucntion by reaching the
terminating right brace.
Exercise 1-13. Write a program to convert..."

Note also that you are /not/ using a normal data stream, but a PDF file.

And a PDF file is not a data stream because ?

is your program's job to interpret that file correctly so that the purposes
of the exercise are correctly satisfied.

I can satisfy the requrements of the exercise correctly with /any/
datastream. Data is data.

Then get a book that has the same 1.13 as everyone else's 1.13.

Why? If you don't make it clear what you want thats hardly my problem.

The point, which you appear to have failed to grasp, is that text processing
in C is *easy*. You have claimed that PDF processing is easy, too, but you
apparently can't even solve a simple exercise using PDF input.

Richad, I'm well used to watching you manipulate other's posts to your own
advantage, so its pointless trying it on me. I #can# do this. I choose not
to because I don't propose to pander to your childishness.

Just as a reminder, here is what you claimed: "Its also easy to write tex to
dvi to pcl processors in standard C. Its also easy to write pdf readers in
standard C."

I remain unconvinced.

Thats tough.

 

[Mark McIntyre]

I don't have to. You claimed PDF processing is easy, but you appear to be
incapable of supporting your claim.

As I've said elsethread, thats a false assertion. I have watched you do
this before with other people, and found it disturbing. Report the facts,
not your twist on them to suit your desire to win the point.

Here's my position. I claim that its easy to /write/ a pdf processor in
standard C. I don't propose to post teh code here because its too long, and
frankly unnecesary. I don't claim that the program will be simple.

In other words, you appear to be claiming now that PDF processing is so
difficult that the only way you can realistically use PDF data is to turn
it to text data first,

Now you're beginning to annoy me. You lie with the above remark. What I'm
saying and I believe you understand that, is that using only Standard C,
its clearly not possible to generate graphical output. Therefore I won't do
it.

The obvious strategy, then, is to store the data in text
format to begin with, thus neatly cutting out the middle man.

I'm not converting it into a text file. What gives you that bizarre
impression?

If you must do that, please learn how to do it properly.

I'll be more obvious next time. When you get a sense of humour and less of
a sense of self-importance, let me know.

 

[Randy Howard]

Then get a book that has the same 1.13 as everyone else's 1.13.

It's clear that he's using K&R1, despite writing K&R2 above.

 

[Randy Howard]

Learn to Understand. In my copy of K&R, page 24 begins:
"caller, as does "falling off the end" of a fucntion by reaching the
terminating right brace.
Exercise 1-13. Write a program to convert..."

Clearly, you made a mistake the first time, and used K&R1, even though
you yourself mentioned K&R2 previously. If we read a little further along,
it's conveniently located in your quoted text below:

Why? If you don't make it clear what you want thats hardly my problem.

Not only did he make it clear, you did as well, you just opened the
wrong version of the book. Right?

I'm not disagreeing with your arguments btw, I just don't see any
reason to try and cover up such a simple mistake.