473,325 Members | 2,771 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,325 software developers and data experts.

A C tutorial

There is a C tutorial at
http://www.cs.virginia.edu/~lcc-win32
It is written to go with the compiler, available
at the same URL.

I have added quite a bit of material, and I would be
glad if people in this group give it a try and tell me if
I am saying nonsense somewhere.

Beware that I am not very orthodox, hence my tutorial
(and the associated compiler) is not just a tutorial about
ANSI C, but covers things like operator overloading and
other heresies :-)

And since it is running in a specific OS, windows
programming makes for quite a lot of pages. If you
use another OS however, the first part is (almost)
straight C.

jacob

Nov 14 '05
156 7379
Da*****@cern.ch (Dan Pop) writes:
In <c0*************@news.t-online.com> Martin Dickopp <ex****************@zero-based.org> writes:
You seem to believe that only things which have previously been claimed
or implied can be disproven. That is not the case.
I merely don't see the point in disproving things no one has claimed
or implied.


That you don't see the point doesn't mean there isn't one. :)

Maybe someone has found my posting interesting, maybe nobody has. In the
latter case, it would indeed have been a waste of time and bandwidth.
That's the risk when participating in an off-topic discussion (which I
admit being guilty of).
Unless you enjoy talking alone...


Someone has replied to every single of my postings in this subthread so
far - you. :)

Martin
Nov 14 '05 #101

In article <c0**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop) writes:
In <c0**********@titan.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:
jacob navia wrote:
But PDF is a widely used format,


Oh, I know, I know. That doesn't mean it necessarily /should/ be.


Name one document format with a public specification that should be
used instead, allowing for comparable quality of the printed output.


I'm with Richard on this one. I rarely print PDFs. I frequently view
them on screen, and I almost never encounter one which any reader,
including Adobe's bloated and insecure Acrobat Reader (or even more
bloated and insecure Acrobat), will present in a manner that's both
convenient and comfortable to read. That's across a wide range of
display hardware; the display I use most often these days is an LCD
screen with 1280x1024 resolution, and most PDFs still render with
unreadably small fonts if I want to get a decent portion of the text
on-screen. (In particular, I have very little patience for reading
any document that requires horizontal scrolling.)

And I have very rarely encountered a PDF document which could not
have conveyed the same content very nicely in HTML, and let *my*
renderer of choice format it the way *I* want it.

That, for me, is enough to hate PDF. Perhaps the tool itself is a
good one, but it's used far widely than it should be.

--
Michael Wojcik mi************@microfocus.com

But I still wouldn't count out the monkey - modern novelists being as
unpredictable as they are at times. -- Marilyn J. Miller
Nov 14 '05 #102
In <c0********@enews4.newsguy.com> mw*****@newsguy.com (Michael Wojcik) writes:

And I have very rarely encountered a PDF document which could not
have conveyed the same content very nicely in HTML, and let *my*
renderer of choice format it the way *I* want it.


The document formatting is part of the author's work and it is his choice
whether to keep a strict control over it or delegate the control to the
user.

The 1 to 1 correspondence between what you see on the screen and what you
get printed is a big bonus when selectively printing parts of the
document, which is what I often do. And high resolution screens are
commonly available these days (1050x1400 for laptops, 1200x1600 for
desktops) for people who want to enjoy the quality of a good PDF
renderer.

Last but not least, having the complete document, which can be a thick
book, in a single file of reasonable size is extremely convenient.

I don't like PDF for documents where plain text would do equally well,
like most of the C standard. But once multiple fonts are a *real* need,
as well as pictures and complex diagrams, not to mention *proper* support
for languages other than English and whatever can fit into Latin-1, I have
yet to see something better than PDF.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #103
In <c0*************@news.t-online.com> Martin Dickopp <ex****************@zero-based.org> writes:
Da*****@cern.ch (Dan Pop) writes:
Unless you enjoy talking alone...
^^^^^^^^^^^^^^^^^^^^^^^Someone has replied to every single of my postings in this subthread so
far - you. :)


I didn't realise this possibility until now, but I'll keep it in mind in
the future ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #104
Richard Bos wrote:
Richard Heathfield <do******@address.co.uk.invalid> wrote:
Mark McIntyre wrote:
> But software Y, which
> coincidentally happens to be commercially produced, you don't trust,
> for precisely the same reason.
No. I trust gcc partly because of the million eyes, but mainly because I
firmly believe that GNU have the interests of the programming community
at heart.


You _have_ read the GCC man pages, haven't you?


Yes.
I refer in particular to
their comments about -pedantic.
What about those comments? As long as they provide conformance, they can be
as rude as they like about it, can't they?
I don't have the same faith in Adobe.


Neither do I, but at least if Adobe turn out to be criminals rather than
merely scummy weasels we can sue them.


I find it easier merely to have no dealings with them whatsoever.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #105
Dan Pop wrote:
In <c0**********@sparta.btinternet.com> Richard Heathfield
<do******@address.co.uk.invalid> writes:
Dan Pop wrote:
My claim is that gcc is the ideal target for such an attack. If, from
my claim you infer that you have no reason not to blindly trust gcc,
then
fine. But then, you'll look like the king of the hypocrites when
claiming that you distrust software you cannot check for malicious code
(an attacked gcc is a piece of software you cannot check for malicious
code, even if the sources are available, as long as you use gcc to
rebuild the program).


King of the hypocrites? No, not really. You see, I don't distrust GNU. But
I /do/ distrust Adobe. I am confident of GNU's good intentions. I am not
confident of Adobe's good intentions.


Non sequitur and a proof that you have understood nothing of this issue.


I think we're talking about different issues. Feel free to continue
discussing the one that concerns you, if you must.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #106
Dan Pop wrote:

<snip>
These days, text means more than whatever can be expressed with the
ASCII character set.


Who said anything about ASCII?

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #107
On Wed, 11 Feb 2004 20:31:36 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
Yes, I could - using vim, or emacs, or ed, or less, or joe, or pico, or even
grep!
all of which are file readers.
Or I could simply write a simple cat:
and so is this one.

My point is that any argument based on the need of a special program to
read the file is flawed. Unless you can personally detect the bitpatterns
on the platters of the HDD, you can't read /any/ data on a computer without
some program's assistance.
You see, text fits in with the C model very well indeed. It's easy to write
text processors in C.


Its also easy to write tex to dvi to pcl processors in standard C. Its
also easy to write pdf readers in standard C.
And chinese text is useless to me. Your point is.... :-)


...that the fewer constraints one puts on one's intended audience, the wider
that audience can be.


And pdf imposes, IMHO, virtually no realistic constraints. Sure, there's no
pdf reader for my toaster. Neither is there a text reader. I do however
have a pdf reader for dos, windows, unix, macos, vms, palmos, etc.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #108
Mark McIntyre wrote:
On Wed, 11 Feb 2004 20:31:36 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
Yes, I could - using vim, or emacs, or ed, or less, or joe, or pico, or
even grep!


all of which are file readers.
Or I could simply write a simple cat:


and so is this one.

My point is that any argument based on the need of a special program to
read the file is flawed. Unless you can personally detect the bitpatterns
on the platters of the HDD, you can't read /any/ data on a computer
without some program's assistance.
You see, text fits in with the C model very well indeed. It's easy to
write text processors in C.


Its also easy to write pdf readers in standard C.


Really? Show me. 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.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #109
Richard Heathfield <do******@address.co.uk.invalid> wrote:
Richard Bos wrote:
Richard Heathfield <do******@address.co.uk.invalid> wrote:
Mark McIntyre wrote:

> But software Y, which
> coincidentally happens to be commercially produced, you don't trust,
> for precisely the same reason.

No. I trust gcc partly because of the million eyes, but mainly because I
firmly believe that GNU have the interests of the programming community
at heart.


You _have_ read the GCC man pages, haven't you?


Yes.
I refer in particular to their comments about -pedantic.


What about those comments? As long as they provide conformance, they can be
as rude as they like about it, can't they?


They can, but it does degrade my confidence in them having _my_
interests at heart. I don't want to be embraced-and-extended by them any
more than by M$, and they _do_ want to embrace-and-extend me.

Richard
Nov 14 '05 #110
Richard Bos wrote:
Richard Heathfield <do******@address.co.uk.invalid> wrote:
Richard Bos wrote:
> I refer in particular to their comments about -pedantic.


What about those comments? As long as they provide conformance, they can
be as rude as they like about it, can't they?


They can, but it does degrade my confidence in them having _my_
interests at heart. I don't want to be embraced-and-extended by them any
more than by M$, and they _do_ want to embrace-and-extend me.


That's a reasonable position for you to hold. Still, they /do/ provide
conformance, and at a price that's hard to beat. I agree that it would be
better if they could be a little more gracious about it, but one can't have
everything.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #111
Richard Heathfield <in*****@address.co.uk.invalid> wrote:
Richard Bos wrote:
Richard Heathfield <do******@address.co.uk.invalid> wrote:
Richard Bos wrote:

> I refer in particular to their comments about -pedantic.

What about those comments? As long as they provide conformance, they can
be as rude as they like about it, can't they?


They can, but it does degrade my confidence in them having _my_
interests at heart. I don't want to be embraced-and-extended by them any
more than by M$, and they _do_ want to embrace-and-extend me.


That's a reasonable position for you to hold. Still, they /do/ provide
conformance, and at a price that's hard to beat. I agree that it would be
better if they could be a little more gracious about it, but one can't have
everything.


Oh, I don't say that I trust them any less than the commercial
competition; in fact, I'm not even saying that I don't trust them
somewhat more. All I'm saying is that I certainly don't entirely trust
them either.

Richard
Nov 14 '05 #112
In <c0**********@hercules.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:
Dan Pop wrote:
In <c0**********@sparta.btinternet.com> Richard Heathfield
<do******@address.co.uk.invalid> writes:
Dan Pop wrote:

My claim is that gcc is the ideal target for such an attack. If, from
my claim you infer that you have no reason not to blindly trust gcc,
then
fine. But then, you'll look like the king of the hypocrites when
claiming that you distrust software you cannot check for malicious code
(an attacked gcc is a piece of software you cannot check for malicious
code, even if the sources are available, as long as you use gcc to
rebuild the program).

King of the hypocrites? No, not really. You see, I don't distrust GNU. But
I /do/ distrust Adobe. I am confident of GNU's good intentions. I am not
confident of Adobe's good intentions.


Non sequitur and a proof that you have understood nothing of this issue.


I think we're talking about different issues. Feel free to continue
discussing the one that concerns you, if you must.


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...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #113
In <c0**********@hercules.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:
Richard Bos wrote:
Richard Heathfield <do******@address.co.uk.invalid> wrote:
Mark McIntyre wrote:

> But software Y, which
> coincidentally happens to be commercially produced, you don't trust,
> for precisely the same reason.

No. I trust gcc partly because of the million eyes, but mainly because I
firmly believe that GNU have the interests of the programming community
at heart.


You _have_ read the GCC man pages, haven't you?


Yes.
I refer in particular to
their comments about -pedantic.


What about those comments? As long as they provide conformance, they can be
as rude as they like about it, can't they?


The problem is that, to the beginner, the name of the -pedantic flag is
very misleading. Which is why we seldom see such people using it, even
if they use -ansi. If the GNU C people were entirely honest, -ansi would
have included the functionality of -pedantic. There is no point in using
two flags for achieving exactly one goal and I'm not aware of any compiler
that requires more than one flag for becoming standard conforming.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #114
In <c0**********@hercules.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:
Dan Pop wrote:

<snip>
These days, text means more than whatever can be expressed with the
ASCII character set.


Who said anything about ASCII?


Your examples implied that the base character set of the implementation
is good enough for any text-based utility. Replace ASCII by EBCDIC or
any other character set used as the base character set of common C
implementations.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #115
In <c0**********@titan.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:
Mark McIntyre wrote:
Its also easy to write pdf readers in standard C.


Really? Show me. 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.


Your idea about "fair" comparisons is heavily screwed. He wrote "standard
C", not the subset of the language documented in the first 24 pages of
K&R2.

BTW, I chanllenge you to write a fully functional text reader
(e.g. having the basic features of the open source "less") using only
that subset of the language.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #116
In <40******@news2.power.net.uk> Richard Heathfield <in*****@address.co.uk.invalid> writes:
Richard Bos wrote:
Richard Heathfield <do******@address.co.uk.invalid> wrote:
Richard Bos wrote:

> I refer in particular to their comments about -pedantic.

What about those comments? As long as they provide conformance, they can
be as rude as they like about it, can't they?
They can, but it does degrade my confidence in them having _my_
interests at heart. I don't want to be embraced-and-extended by them any
more than by M$, and they _do_ want to embrace-and-extend me.


That's a reasonable position for you to hold. Still, they /do/ provide
conformance,


The past tense fits better here: they *did* provide conformace.
and at a price that's hard to beat. I agree that it would be
better if they could be a little more gracious about it, but one can't have
everything.


Apparently, not even conformance to the current C standard... Which
reinforces Richard Bos' statement about the GNU C people not having the
interests of the C programming community at heart.

For the record, I do consider GNU C better than any C standard. It
provides badly needed features that the standardisation committee
preferred to ignore (e.g. the concept of pure functions, typeof or blocks
returning/yielding a value). But this is no excuse for providing
improper support for standard C.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #117
Da*****@cern.ch (Dan Pop) writes:
Apparently, not even conformance to the current C standard... Which
reinforces Richard Bos' statement about the GNU C people not having the
interests of the C programming community at heart.
Not too surprisingly, the companies paying for GCC development have
primarily the interests of their customers at heart.
For the record, I do consider GNU C better than any C standard. It
provides badly needed features that the standardisation committee
preferred to ignore (e.g. the concept of pure functions, typeof or
blocks returning/yielding a value). But this is no excuse for
providing improper support for standard C.


If you paid for GCC, you should complain to the company from which you
bought GCC and/or GCC support. The timescale and order in which things
get implemented in GCC is definitely influenced by the wishes of the
customers, and apparently C99 conformance is not a priority to many
customers.

Although I regret this, I'm not in a position to complain (and the GCC
developers don't owe me an excuse), since I didn't pay for GCC.

Martin
Nov 14 '05 #118
Dan Pop wrote:
In <c0**********@titan.btinternet.com> Richard Heathfield
<do******@address.co.uk.invalid> writes:
Mark McIntyre wrote:
Its also easy to write pdf readers in standard C.
Really? Show me. 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.


Your idea about "fair" comparisons is heavily screwed. He wrote "standard
C", not the subset of the language documented in the first 24 pages of
K&R2.


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. If pdf processing is so
easy, he shouldn't find this to be a major challenge. But perhaps he has to
open a file or something, in which case I agree that the restriction would
be a bit harsh. But let's at least see a program written in "simple" C -
the kind a newbie can understand - that can process PDF files in some
relatively trivial way such as word-length histograms. I don't think this
is an unreasonable thing to ask if Mark's claim is accurate.
BTW, I chanllenge you to write a fully functional text reader
(e.g. having the basic features of the open source "less") using only
that subset of the language.


I have not claimed that I can do this (in fact, the absence of full screen
video in standard C makes it impossible to do portably, as any newbie ought
to know). But 1-13 is a different matter.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #119
Dan Pop wrote:
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 : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #120
Dan Pop wrote:

<snip>
King of the hypocrites? No, not really. You see, I don't distrust GNU.
But I /do/ distrust Adobe. I am confident of GNU's good intentions. I am
not confident of Adobe's good intentions.

Non sequitur and a proof that you have understood nothing of this issue.


I think we're talking about different issues. Feel free to continue
discussing the one that concerns you, if you must.


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?

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #121
In article <c0**********@sunnews.cern.ch>, Da*****@cern.ch says...
In <MP************************@news.verizon.net> Randy Howard <ra*********@FOOverizonBAR.net> writes:
In article <c0**********@sunnews.cern.ch>, Da*****@cern.ch says...
Please elaborate. Which other pieces of Adobe software have bitten you
with their malicious code?


Perhaps a reminder that recently Adobe has gotten some flack for
introducing some "malware" into Acrobat reader that makes it
absolutely refuse to render certain graphic images, such as
US currency. No warning, no disclosure, it's just there. It
makes it load much, much slower while it scans the file looking
for such on each "fopen()".

Here is an example of such discussions:

http://www.pdfzone.com/news/767-PDFzone_news.html


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.
--
Randy Howard
2reply remove FOOBAR

Nov 14 '05 #122
On Fri, 13 Feb 2004 01:21:10 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
Mark McIntyre wrote:
On Wed, 11 Feb 2004 20:31:36 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
You see, text fits in with the C model very well indeed. It's easy to
write text processors in C.
Its also easy to write pdf readers in standard C.


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
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #123
On Fri, 13 Feb 2004 19:38:11 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
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.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #124
Mark McIntyre wrote:
On Fri, 13 Feb 2004 01:21:10 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
Mark McIntyre wrote:
On Wed, 11 Feb 2004 20:31:36 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:

You see, text fits in with the C model very well indeed. It's easy to
write text processors in C.

Its also easy to write pdf readers in standard C.
Really?


Yes, really.
Show me.


Sure, for Eur 150/hour. :-)


Then it can hardly be as easy as you claim.

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.


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 : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #125
Mark McIntyre wrote:
On Fri, 13 Feb 2004 19:38:11 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
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.


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?
If pdf processing is so
easy, he shouldn't find this to be a major challenge.
Its not.


Prove it.

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.


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?

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #126
nrk
Richard Heathfield wrote:
Mark McIntyre wrote:
On Fri, 13 Feb 2004 19:38:11 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
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.


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?
If pdf processing is so
easy, he shouldn't find this to be a major challenge.


Its not.


Prove it.

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.


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.
--
Remove devnull for email
Nov 14 '05 #127
On Sat, 14 Feb 2004 05:46:00 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
Mark McIntyre wrote:

Sure, for Eur 150/hour. :-)
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... :-)
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.


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....
You need to think a little harder.
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"
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.


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
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #128
On Sat, 14 Feb 2004 05:55:59 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
Mark McIntyre wrote:
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?


*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
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/.


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
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #129
On Sat, 14 Feb 2004 21:35:07 GMT, in comp.lang.c , nrk
<ra*********@devnull.verizon.net> wrote:
Richard Heathfield wrote:
Mark McIntyre wrote:
RJH wrote
If pdf processing is so
easy, he shouldn't find this to be a major challenge.

Its not.


Prove it.

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.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #130
nrk wrote:
Richard Heathfield wrote:
Mark McIntyre wrote:
On Fri, 13 Feb 2004 19:38:11 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:

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.
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?

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

Its not.


Prove it.


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.


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.


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 : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #131
Mark McIntyre wrote:
On Sat, 14 Feb 2004 05:55:59 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
Mark McIntyre wrote:
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?


*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.

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?


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 : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #132
Mark McIntyre wrote:
On Sat, 14 Feb 2004 05:46:00 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
Mark McIntyre wrote:

Sure, for Eur 150/hour. :-)
Then it can hardly be as easy as you claim.


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.
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.


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.

You need to think a little harder.


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.


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.

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.


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.

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.


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 : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #133
Mark McIntyre wrote:
On Sat, 14 Feb 2004 21:35:07 GMT, in comp.lang.c , nrk
<ra*********@devnull.verizon.net> wrote:
Richard Heathfield wrote:
Mark McIntyre wrote:

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

Its not.

Prove it.
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...


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.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #134
nrk
Richard Heathfield wrote:
nrk wrote:
Richard Heathfield wrote:
Mark McIntyre wrote:

On Fri, 13 Feb 2004 19:38:11 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:

>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.

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?
> If pdf processing is so
>easy, he shouldn't find this to be a major challenge.

Its not.

Prove it.

>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.

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.


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.
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.


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

-nrk.
--
Remove devnull for email
Nov 14 '05 #135
On Sun, 15 Feb 2004 07:25:02 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
Mark McIntyre wrote:
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.


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.
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.


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.
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.


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
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #136
On Sun, 15 Feb 2004 07:29:16 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@address.co.uk.invalid> wrote:
Mark McIntyre wrote:
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.


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.
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,


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?
I'm sorry, I've been taking the p*ss.


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.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #137
In article <c0**********@hercules.btinternet.com>,
do******@address.co.uk.invalid says...
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.


It's clear that he's using K&R1, despite writing K&R2 above.
--
Randy Howard
2reply remove FOOBAR

Nov 14 '05 #138
In article <t5********************************@4ax.com>,
ma**********@spamcop.net says...
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.


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:
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.


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.

--
Randy Howard
2reply remove FOOBAR

Nov 14 '05 #139
Dan Pop <Da*****@cern.ch> scribbled the following:
The 1 to 1 correspondence between what you see on the screen and what you
get printed is a big bonus when selectively printing parts of the
document, which is what I often do. And high resolution screens are
commonly available these days (1050x1400 for laptops, 1200x1600 for
desktops) for people who want to enjoy the quality of a good PDF
renderer. Last but not least, having the complete document, which can be a thick
book, in a single file of reasonable size is extremely convenient. I don't like PDF for documents where plain text would do equally well,
like most of the C standard. But once multiple fonts are a *real* need,
as well as pictures and complex diagrams, not to mention *proper* support
for languages other than English and whatever can fit into Latin-1, I have
yet to see something better than PDF.


I agree with you, and may I add that one other reason for preferring
PDFs is that they're easy to generate from PostScript documents, which
can be made to include mathematical symbols not found in pretty much
any ISO-8859-x character set, by using LaTeX. I have found this a very
good thing when writing homework solutions in mathematics.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"You will be given the plague."
- Montgomery Burns
Nov 14 '05 #140
nrk
Joona I Palaste wrote:
Dan Pop <Da*****@cern.ch> scribbled the following:
The 1 to 1 correspondence between what you see on the screen and what you
get printed is a big bonus when selectively printing parts of the
document, which is what I often do. And high resolution screens are
commonly available these days (1050x1400 for laptops, 1200x1600 for
desktops) for people who want to enjoy the quality of a good PDF
renderer.

Last but not least, having the complete document, which can be a thick
book, in a single file of reasonable size is extremely convenient.

I don't like PDF for documents where plain text would do equally well,
like most of the C standard. But once multiple fonts are a *real* need,
as well as pictures and complex diagrams, not to mention *proper* support
for languages other than English and whatever can fit into Latin-1, I
have yet to see something better than PDF.


I agree with you, and may I add that one other reason for preferring
PDFs is that they're easy to generate from PostScript documents, which
can be made to include mathematical symbols not found in pretty much
any ISO-8859-x character set, by using LaTeX. I have found this a very
good thing when writing homework solutions in mathematics.


The LaTeX->dvi->ps->pdf is the correct way to generate butt-ugly PDF files.
They print fine, but viewing them on screen is torture and you can't copy
and paste normally. You should try pdflatex sometime.

-nrk.

--
Remove devnull for email
Nov 14 '05 #141
On Sun, 15 Feb 2004 20:33:43 GMT, in comp.lang.c , Randy Howard
<ra*********@FOOverizonBAR.net> wrote:
In article <t5********************************@4ax.com>,
ma**********@spamcop.net says...
>> 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.
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.


Indeed - I was looking in K&R, which is the one on my shelf at home. K&R2 s
in the office.
I'm not disagreeing with your arguments btw, I just don't see any
reason to try and cover up such a simple mistake.


I didn't realise till later in the thread that the examples were different,
and by then I'd decided that Richard was annoying me enough for me to use
the error to further obfuscate the "debate" if one can dignify if with such
a word.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #142
Randy Howard wrote:
In article <c0**********@hercules.btinternet.com>,
do******@address.co.uk.invalid says...
> 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.


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


That seems like a plausible explanation. I was beginning to wonder!

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #143
In <c0**********@titan.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:
Dan Pop wrote:
BTW, I chanllenge you to write a fully functional text reader
(e.g. having the basic features of the open source "less") using only
that subset of the language.


I have not claimed that I can do this (in fact, the absence of full screen
video in standard C makes it impossible to do portably, as any newbie ought
to know). But 1-13 is a different matter.


Remove any "less" features having anything to do with full screen support
and my challenge still stands. Simply assume a 25-line console with
scroll support when needing to display a new page of text.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #144
In <c0**********@sparta.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:
Dan Pop wrote:
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.


Not even in English, if complex mathematical formulas and foreign names
have to be properly included, much less in most other languages.
And obviously not if the clear communication would require pictures,
complex diagrams and screen shots.
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.


A file format with open specification and open source readers hardly
qualifies as an esoteric file format.

If you don't like PDF, that's fine with me, but there is no point in
publicly complaining about it.

What I don't like are the horribly formatted documents (especially the
ones requiring horizontal scrolling), but it would be downright idiotic
to blame PDF on that.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #145
In <c0**********@sparta.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:
Dan Pop wrote:

<snip>
>King of the hypocrites? No, not really. You see, I don't distrust GNU.
>But I /do/ distrust Adobe. I am confident of GNU's good intentions. I am
>not confident of Adobe's good intentions.

Non sequitur and a proof that you have understood nothing of this issue.

I think we're talking about different issues. Feel free to continue
discussing the one that concerns you, if you must.


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 were talking about not trusting tools whose source code is not
publicly available, because they could contain malicious code. And I
was pointing out that, if this is really your concern, open source tools
are no safer from this point of view, unless you're compiling them
yourself, with your hand made compiler.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #146
Dan Pop wrote:
In <c0**********@sparta.btinternet.com> Richard Heathfield
<do******@address.co.uk.invalid> writes:
I think we're talking about different issues. Feel free to continue
discussing the one that concerns you, if you must.

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 were talking about not trusting tools whose source code is not
publicly available, because they could contain malicious code.


I was talking about not trusting Adobe's tools whose source code is not
publicly available. I don't trust Adobe. Simple as that.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #147
Dan Pop wrote:
In <c0**********@titan.btinternet.com> Richard Heathfield
<do******@address.co.uk.invalid> writes:
Dan Pop wrote:
BTW, I chanllenge you to write a fully functional text reader
(e.g. having the basic features of the open source "less") using only
that subset of the language.


I have not claimed that I can do this (in fact, the absence of full screen
video in standard C makes it impossible to do portably, as any newbie
ought to know). But 1-13 is a different matter.


Remove any "less" features having anything to do with full screen support
and my challenge still stands. Simply assume a 25-line console with
scroll support when needing to display a new page of text.


There is no good answer to this challenge. The addition of interactivity
makes FILE * a necessity if the thing is to be done portably and
efficiently, and FILE * isn't introduced in the early part of K&R2. (Note
that my challenge to Mark McIntyre did not include an interactivity
requirement.)

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #148
Richard Heathfield wrote:
Dan Pop wrote:

.... snip ...

You were talking about not trusting tools whose source code is not
publicly available, because they could contain malicious code.


I was talking about not trusting Adobe's tools whose source code is
not publicly available. I don't trust Adobe. Simple as that.


You must have some concrete reasons. Are they shareable?

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #149
In <40******@news2.power.net.uk> Richard Heathfield <in*****@address.co.uk.invalid> writes:
Dan Pop wrote:
In <c0**********@titan.btinternet.com> Richard Heathfield
<do******@address.co.uk.invalid> writes:
Dan Pop wrote:

BTW, I chanllenge you to write a fully functional text reader
(e.g. having the basic features of the open source "less") using only
that subset of the language.

I have not claimed that I can do this (in fact, the absence of full screen
video in standard C makes it impossible to do portably, as any newbie
ought to know). But 1-13 is a different matter.


Remove any "less" features having anything to do with full screen support
and my challenge still stands. Simply assume a 25-line console with
scroll support when needing to display a new page of text.


There is no good answer to this challenge. The addition of interactivity
makes FILE * a necessity if the thing is to be done portably and
efficiently, and FILE * isn't introduced in the early part of K&R2. (Note
that my challenge to Mark McIntyre did not include an interactivity
requirement.)


How can I read a 10+ page document with a non-interactive file reader?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #150

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Rhino | last post by:
Can anyone point me to a good free XSLT Tutorial online? I looked for some a few months ago and didn't find anything very good. I'm hoping some of the experts here can point me to a good XSLT...
15
by: binnyva | last post by:
Hello Everyone, I have just compleated a JavaScript tutorial and publishing the draft(or the beta version, as I like to call it) for review. This is not open to public yet. The Tutorial is...
18
by: Xah Lee | last post by:
i've started to read python tutorial recently. http://python.org/doc/2.3.4/tut/tut.html Here are some quick critique: quick example: If the input string is too long, they don't truncate it,...
0
by: Joe Mayo | last post by:
I've recently updated the C# Tutorial at C# Station with a new addition, Lesson 17: Enums. The C# Tutorial may be found at http://www.csharp-station.com/Tutorial.aspx. Other updates include:...
10
by: Safalra | last post by:
When a poster in a forum I frequent said they were beginning to learn HTML, I thought I should direct them to a good HTML tutorial so that they wouldn't start using <blink> and the like....
11
by: Magnus Lycka | last post by:
While the official Python Tutorial has served its purpose well, keeping it up to date is hardly anyones top priority, and there are others who passionately create really good Python tutorials on...
7
by: Turbo | last post by:
I have a written a detailed html tutorial here:- http://sandy007smarty.seo.iitm.ac.in/2006/09/26/html-tutorial/ I know there are a couple of html tutorials out there. But its a tutorial without...
2
by: sara | last post by:
Hi All, I learned C++ long time ago and now I want to review all of its details in a short time like a week. I wonder if there is a good tutorial you know which I can read for this purpose....
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.