C the complete nonsense

[Willem]

Malcolm McLean wrote:
)>
)> And what exactly is the common English meaning of "type" for which a
)> function can have type int?
)>
) The "type" of a "function" in non-C terms would be "real" or
) "integral", as well as other characteristics like "monotonic" or
) "differentiable".

Those are definitions from mathematics. I would hardly call that
'common English'. In common English, I expect things like
"has side effects", "works with filehandles" or "takes a long time".


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Seebs]

Yes, it is.

I think it depends a lot on context. In general, if it is a code *fragment*,
then I am usually willing to assume that the variables have the correct
type, but if it is offered as a sample function or program, it should have
all its declarations.

-s

 

[Tim Streater]

spinoza1111 wrote:


Rubbish. The order of evaluation is not "nondeterministic"; it is
unspecified. Implementations are free to choose the order that makes
sense for them, without that same choice being imposed on other
implementations - i.e. other implementations are free to choose a
different order. I have told you this before.


And if you had a clue, elephants would have blue trunks. You can follow
a false protasis with any apodosis you like. Doesn't make it true.

But it could still be clear though.

 

[Seebs]

But it could still be clear though.

I think we all win substantially from the discovery that, with more careful
reading, Schildt's writing isn't even clear in the sense in which "clear"
doesn't imply "true", so that particular illucidity is no longer relevant.

-s

 

[Seebs]

If that is true (and I don't think it is), by your own argument you are
far less able to be a trustworthy authority on Schildt. At least Seebs
actually has a copy of the book, which is certainly a good start.

Ahh, but I do not claim to be a "trustworthy authority on Schildt".

I claim to be a trustworthy authority on the C language -- not in that
everything I say is without error (HAH!), but in that I have a pretty good
chance of being right or close to right immediately, I know how to look
things up, and I take corrections well *when they make any sense at all*.

CTCN is (part of) his track record. You have yet to demonstrate that
there is anything fundamentally wrong with it. In fact, we have seen
that its biggest flaw is that it underestimates the badness of the book.

My track record includes, but is not limited to:

* Various participation in comp.lang.c over the last twenty years or so.
* Bug reports and fixes submitted to various groups and projects, ranging
from a bug fix for the SPE math library for IBM's Cell processor SDK,
to a gcc patch, to various commercial work.
* Dozens upon dozens of published articles, a couple of chapters of a book
on C, an entire book on shell scripting.
* Hundreds of posts in various message boards and forums discussing C in
various detail, answering questions, and suggesting solutions to problems.
* A decade or two of experience programming and writing for various employers,
and the associated performance reviews.
* A decade or so of participation in the C standards process, including
presenting papers, participating in discussions, and so on.

I am not a particularly private sort of person. I have been using the nym
"seebs" online since I was first able to obtain it, back in college, and I
have consistently used it whether discussing religion, physics, programming,
or World of Warcraft.

So far, the only people I've seen tell me that I don't know much about C
have been people who were manifestly incapable of understanding even simple
C programs.

-s

 

[Ben Bacarisse]

Malcolm McLean wrote:
)>
)> And what exactly is the common English meaning of "type" for which a
)> function can have type int?
)>
) The "type" of a "function" in non-C terms would be "real" or
) "integral", as well as other characteristics like "monotonic" or
) "differentiable".

Those are definitions from mathematics. I would hardly call that
'common English'. In common English, I expect things like
"has side effects", "works with filehandles" or "takes a long time".

Agreed. Moreover there is no need to use the word type to categorise
function like that -- there are other common English words that aren't
defined by the standard like "kind" and "sort":

What kind of function is that? It has side effects. Ah, that sort
of function usually has a return type of void.

 

[Keith Thompson]

The "type" of a "function" in non-C terms would be "real" or
"integral", as well as other characteristics like "monotonic" or
"differentiable".

In C terms, the type of a function is the type of the function.

Assuming that it means anything else *when discussing the C language*
is absurd.

Sheesh.

 

[Malcolm McLean]

CTCN is (part of) his track record. You have yet to demonstrate that
there is anything fundamentally wrong with it. In fact, we have seen
that its biggest flaw is that it underestimates the badness of the book.

The original version really didn't make its case. If you're going to
launch an invective with no attempt at balance, you have to make sure
that your first entry in the errata is accurate. In fact it was off-
target, because it relied on "In general" meaning "always".

The second one was a bit better. Technically it's nonsense to call a
static file scope variable a "global". However the term is in common
use, and you can't necessarily blame an author for using the jargon.

So two errata, two criticisms of Schildt which looked, at best, as
though someone was scratching around to find something bad to say. At
this point, it lost the sympathy of this reader.

 

[Nick Keighley]

As I said:


I have a Frequently Given Answer on this, a hyperlink to
which I have sent to you. The convention was entirely
an artifact of the C libraries.  The actual operating
system never required any such thing, and does not
treat character 26 specially in this regard.



The C libraries look for the character, and if they see it,
they set the same flag on a C stream that they set if they
encounter a zero byte read.  See the Frequently Given
Answer, which even shows you the source code of some C
libraries that do this.- Hide quoted text -

- Show quoted text -

 

[Nick Keighley]

On 10 Apr, 01:02, J de Boyne Pollard <[email protected]>
wrote:

please leave the attributions in

I thought by convention DOS textfiles were terminated with ^Z?

[...]
The convention was entirely
an artifact of the C libraries.

sounds odd. So a text file written in say pascal wouldn't do this? So
why did C libraries do it?

 The actual operating
system never required any such thing, and does not
treat character 26 specially in this regard.

I never said it did

The C libraries look for the character, and if they see it,
they set the same flag on a C stream that they set if they
encounter a zero byte read.

as I said

 

[Nick Keighley]

That's a much, much, harder problem -- I'd have to search the entire book
for stuff, and it's very hard to figure out what things ought to be covered
but aren't, especially because he could always cover something in an
unexpected place.

and, of course, what "should" be in a book is ratherf a matter of
opinion

 

[Tim Streater]

The original version really didn't make its case. If you're going to
launch an invective with no attempt at balance, you have to make sure
that your first entry in the errata is accurate. In fact it was off-
target, because it relied on "In general" meaning "always".

The second one was a bit better. Technically it's nonsense to call a
static file scope variable a "global". However the term is in common
use, and you can't necessarily blame an author for using the jargon.

So two errata, two criticisms of Schildt which looked, at best, as
though someone was scratching around to find something bad to say. At
this point, it lost the sympathy of this reader.

That was no excuse for *giving up* at that particular point, after you
been asked to review the document (by Spinny) and had announced this. I
lost sympathy with your review at that point, and with your conclusion.
If you'd gone though the whole thing, I might not have.

 

[Nick Keighley]

Malcolm McLean wrote:

)>
)> And what exactly is the common English meaning of "type" for which a
)> function can have type int?
)>
) The "type" of a "function" in non-C terms would be "real" or
) "integral", as well as other characteristics like "monotonic" or
) "differentiable".

Those are definitions from mathematics.  I would hardly call that
'common English'.  In common English, I expect things like
"has side effects", "works with filehandles" or "takes a long time".

the mathematical meaning of "type" isn't that far from the english
meaning. It's a collection of things that share a common property.
"those trees are deciduous" "those numbers are all positive"

 

[Willem]

Nick Keighley wrote:
)> Malcolm McLean wrote:
)>
)> )>
)> )> And what exactly is the common English meaning of "type" for which a
)> )> function can have type int?
)> )>
)> ) The "type" of a "function" in non-C terms would be "real" or
)> ) "integral", as well as other characteristics like "monotonic" or
)> ) "differentiable".
)>
)> Those are definitions from mathematics. ?I would hardly call that
)> 'common English'. ?In common English, I expect things like
)> "has side effects", "works with filehandles" or "takes a long time".
)
) the mathematical meaning of "type" isn't that far from the english
) meaning. It's a collection of things that share a common property.
) "those trees are deciduous" "those numbers are all positive"

However, the properties "real", "integral", "monotonic" and
"differentiable" are from mathematics and do not apply to C functions.

Furthermore, the things I described are also properties that are common
to some functions, so I guess you're not disagreeing with me.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Willem]

Richard Harter wrote:
) On Sat, 10 Apr 2010 20:04:56 +0000 (UTC), Willem
)>Those are definitions from mathematics. I would hardly call that
)>'common English'. In common English, I expect things like
)>"has side effects", "works with filehandles" or "takes a long time".
)>
)
) Your common English is uncommon.

sez you.

Or, to put it more civilly: Without argument, what you say is
simply an unfounded assertion which holds no weight as is.

Although I like 'sez you' better, it being more terse and all.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Nick Keighley]

Anyone can make a mistake. However, the antonyms of lucid are
interesting. Which of these do you think applies to Ed Nilges?

 http://www.synonym.com/antonym/lucid/

Answers on a postcard.


Like unidexter, perhaps.

I'm ambisinisterous

 

[Phil Carmody]

[...]
The key is that, in an expression, a function yields a value of its
return type.

I would like to contribute to this game of finding the smallest nit.
*Calling* a function yields a value of its return type. The function
name itself (without the function call operator) yields a pointer to
the function.

Right you are. My sentence, as written, was indeed incorrect. Good
catch!

Oh, you had weasel-room in just defining 'yield' to include invoking.

Phil

 

[Seebs]

Oh, you had weasel-room in just defining 'yield' to include invoking.

Obviously I meant "when invoked", but I really did say it wrong. And
of course, "yield" can't include invoking, because in:
int (*foo)(const char *, const char *) = strcmp;
it is quite clear that strcmp "yields" a pointer to a function.

-s

 

[Seebs]

I don't have my copies of K&R handy, but ...

Given
int foo(void) { /* ... */ }
int *is* the only type-specifier in sight. That doesn't imply that
int, rather than ``int(void)'' is the type of foo. The type-specifier
int specifies the type of the expression ``foo()'', not the type of
foo.

Right. Similarly, in "int *a;", the type specifier is "int", but the type
of a is "pointer to int".

-s

 

[Keith Thompson]

In Appendix A, Section 10, function definitions,
K&R1 has the sentence "Here int is the type-specifier;"
in reference to a complete example of a function definition.

The same part of K&R2 says
"Here int is the declaration specifier;".

I don't have my copies of K&R handy, but ...

Given
int foo(void) { /* ... */ }
int *is* the only type-specifier in sight. That doesn't imply that
int, rather than ``int(void)'' is the type of foo. The type-specifier
int specifies the type of the expression ``foo()'', not the type of
foo.