A C tutorial

[Dan Pop]

Yes, I could - using vim, or emacs, or ed, or less, or joe, or pico, or even
grep! Or I could simply write a simple cat:

#include <stdio.h>
int main(void)
{
int ch;
while((ch = getchar()) != EOF)
{
putchar(ch);
}
return 0;
}

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

Especially if they're not supposed to work when the text file doesn't
match the author's assumptions. As a trivial example, your program
blisfully ignores character set issues, something that PDF readers usually
get right.

These days, text means more than whatever can be expressed with the
ASCII character set. Or even with any of the ISO-8859 8-bit character
sets.

Dan

 

[Martin Dickopp]

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

 

[Michael Wojcik]

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.

 

[Dan Pop]

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]

^^^^^^^^^^^^^^^^^^^^^^^

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

 

[Richard Heathfield]

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?

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]

In <[email protected]> Richard Heathfield


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]

Dan Pop wrote:

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

Who said anything about ASCII?

 

[Mark McIntyre]

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.

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

 

[Richard Heathfield]

all of which are file readers.


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.


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 Bos]

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

 

[Richard Heathfield]

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 Bos]

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

 

[Dan Pop]

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]

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]

Dan Pop wrote:



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]

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]

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

 

[Martin Dickopp]

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

 

[Richard Heathfield]

In <[email protected]> Richard Heathfield


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.