(which was true at the time I wrote it)
It's a good job you have access to it then, isn't it.
At the time you wrote that, I didn't yet have access. But as soon
as I saw your article the next day or so, things might have
changed. Let me check...
If no one has given you the details before, then go here
http://www.clc-wiki.net/wiki/c_standard and follow the links.
That WebPage doesn't have a links section, however when I first saw
your article, before I had time to post nor time to read the Web
pages linked, I did manage to find these two links that might be
useful, from somewhere in the Wiki page, I have no idea where,
although if I search for the Linkname text I might find them again:
Linkname: c standard - clc-wiki
URL:
http://www.clc-wiki.net/wiki/c_standard#Obtaining_the_Standard
Hmm, I seem to have bookmarked a section in that same Wiki page.
It says:
Neither the Standard nor its amendments are available free of charge,
I think that kills the issue for me.
Linkname: Standard C: ISO/IEC 9899:1999(E) + TCs
URL:
http://c0x.coding-guidelines.com/
I have no idea where I found that link. Neither the Linkname nor
any significant part of it is on the Wiki page. Blindly going
there... Oh yeah, I remember this site now. It's a flat HTML
version, where the table of contents has been totally linearized,
no structure at all, just a flat list of sections, with a link from
each TOC item to the corresponding actual Web page. For example:
Linkname: The New C Standard: 6.3.2.1
URL:
http://c0x.coding-guidelines.com/6.3.2.1.html
717 An lvalue is an expression with an object type or an incomplete
type other than void;^53)
So what's an "object type"??
Linkname: The New C Standard: 6.5.3.4
URL:
http://c0x.coding-guidelines.com/6.5.3.4.html
1108 The sizeof operator ...
1111 The result is an integer.
Huh? I thought it was supposed to be a size_t ??
1117 The value of the result is implementation-defined, and its type
(an unsigned integer type) is size_t, defined in <stddef.h> (and other
headers).
OK, that's better (phew!).
1119 EXAMPLE 2 Another use of the sizeof operator is to compute the
number of elements in an array:
sizeof array / sizeof array[0]
That's rather silly. After all, the only place sizeof works for
that is when the declaration of the array is lexically visible, in
which case the number of elements is lexically visible right there
inside the syntax of the declaration, and you can retrieve that
allocation size directly without bothering with that division
operation. Is this for programmers who are paranoid about macros to
emulate constants, so instead of saying:
#define ARRSIZ 14
int foo[ARRSIZ];
for (ix=0; ix<ARRSIZ; ix++) {...}
they write code like this:
int foo[14];
for (ix=0; ix<(sizeof(foo)/sizeof(foo[0])); ix++) {...}
1120 ...
That example is so contrived and frivolous as to degrade C.
Why not an example of how this feature in C can actually help solve
a useful problem, instead of just serve to produce an example of
obfuscated code for the sake of obfuscated code?
** Not a single mention of library functions, which is the major
topic of discussion/debate here (C90 vs. C99 vs. GNU C etc. such as
strtoll). In fact, with this entire document, it's not even
possible to learn what's needed to write a Hello World program.
Let me take a look at the **other** file, 1.3 megabytes, which I
downloaded the other day ... <verbose>shit, it took me a while to
find where I downloaded it to. It wasn't in my C directory, or in
my public_html directory, nor in my HelloWorld directory nor
CookBook directory nor in cgi-bin directory nor at toplevel in my
account nor in the temporary directory where I usually up/down-load
stuff. I finally guessed it might be in my Lisp directory, and
that's where it is, probably because I had been working in lisp
before I took some time off to start lynx, and I hadn't bothered to
change working directory before starting lynx, and after download I
didn't happen to have a good idea where I should move it, so I just
left it there</verbose> ... c9x-draft.txt is what I downloaded, and
chapter 7 is all about libraries, starting with general description
of what header files are used for, and a list of the standard
header files:
[#2] The standard headers are
<assert.h> <inttypes.h> <signal.h> <stdlib.h>
<complex.h> <iso646.h> <stdarg.h> <string.h>
<ctype.h> <limits.h> <stdbool.h> <tgmath.h>
<errno.h> <locale.h> <stddef.h> <time.h>
<fenv.h> <math.h> <stdint.h> <wchar.h>
<float.h> <setjmp.h> <stdio.h> <wctype.h>
[#1] Some of the functions below have branch cuts, across
which the function is discontinuous. For implementations
with a signed zero (including all IEC 60559 implementations)
that follow the specification of annex G, the sign of zero
distinguishes one side of a cut from another so the function
is continuous (except for format limitations) as the cut is
approached from either side. For example, for the square
This is a complete crock!!! To allow a function to have two
different values at exactly the same mathematical value of zero,
they pretend like there are two different zeroes, one zero that is
greater than zero, and another zero which is less than zero. This
stupid mess allows that trick to happen **only** if the branch cut
is at exactly zero. If for example you instead wanted a branch cut
at 3, you're out of luck, because there's no implementation of two
different 3's, one which is greater than 3 and another which is
less than three. Even for zero, hardly any implementation
distinguishes positive zero from negative zero for integers.
Accordingly this matter absolutely **must** be regarded as
"undefined behaviour", so why even bother to say in the spec what
it might be in one implemetation if it isn't even possible to make
it work that way in other implementations?
[#2] Implementations that do not support a signed zero (see
annex F) cannot distinguish the sides of branch cuts.
See what I mean? **UNDEFINED**BEHAVIOUR** !!!!
Why don't they just say that 99.9% of the machines, which use two's
complement arithmetic instead of sign-and-magnitude arithmetic,
can't possibly implement a conforming C using machine arithmetic??
By the way, this document is:
WG14/N869 Committee Draft -- January 18, 1999
That's the best I've found so-far online in ASCII text form.
I sorta hate to have my CookBook/Matrix conform to such a crockshit document.
But the final standard is no better on this matter, right?
According to that statement and your web page that means you do not
understand C. Your cookbook still has this prototype given in what is
meant to be C "int g2(int n1,n2);" despite it having been pointed out to
you and you having read the post and commented about it.
I don't recall either the critique of that nor my response.
Checking Google I see indeed somebody said something was wrong with
that but didn't say what was wrong, so I asked for clarification,
but nobody ever answered, so I still don't know what was supposed
to be wrong, nor even whether there is anything wrong in the first
place or you are just <cliche>pulling my leg</cliche>.
Regarding worms/viruses etc. via subtle hard-to-find bugs in C code:
If you don't understand the language then how do you expect to be
able to develop anything that is robust?
Is that the excuse MicroSoft is using for data-overrun bugs in
Interent Explorer, that not a single programmer in the whole
company knows C nor any other programming language that they might
have used instead of C to code IE?
I've never had to go back over all of any significantly complex program
I've written.
Hey, does the Pope know about you? He's always looking for another
good candidate for Sainthood, and if you have never made a mistake
in your whole life then I think he should seriously consider you,
even if you're not Catholic, after all Jesus wasn't Catholic
either, and the Church rates him even better than a saint.
Depends. Do you want to crash in to the car in front because your
breaks did not apply in time? There are times when speed (or
consistency of speed) is just as important a requirement as any
other.
Anybody who would design a passenger vehicle with the only path
between brake pedal and brake pads being through a complicated
computer program would IMO be a fool. IMO when you step on the
brake pedal, there should be a physical connection between brake
pedal and brake pads, via lever or fluid or whatever, but no
computer in the critical path. It's fine that there's a fluid-level
sensor that feeds into the computer, so if the fluid leaks the
computer has a very good chance of flashing a warning light, but
please don't have the brakes fail just because of a bug in the
program. At worst, the indicator light fails because of bug in
program. But monitoring fluid level to detect leak can be utterly
sssssslllllllllooooooowwwww and still be fast enough to turn on the
indicator within a day after the fluid level passes from totally
full to starting to get low, long before the fluid level get low
enough to affect brake function. A fortran program on an IBM 1620
would be fast enough, if you had a trunk big enough to carry it
around with you, and you didn't mind stopping every half hour to
reset the parity error and restart the program!!
There are far too many misconceptions in your web pages, such as
being able to compare unrelated pointers, ...
So long as the pointers are of the same type, there's nothing
impossible with comparing them, which will tell you whether the
objects pointed-at are this way or the opposite with respect to
each other in memory. If you think a program is not able to compare
the pointers, please explain your reasoning.
I believe it's in fact portable code, in the sense that on any
working implementation of C it'll tell you correctly which of the
two pointers points to lower address. Of course it will give
different results in different implementations, so it's not
portable in the sense of giving identical results in all
implementations, but the sizeof (int) gives different results in
different implementations, so that's hardly a reason to totally
reject that usage, to say being able to compare unrelated pointers
is impossible. It would likewise be impossible to call sizeof (int).
right shifting a negative number 0 fills
It depends on whether you are talking about arithetic shift or
logical shift. Can you cite the paragraph where I said something
confusing to that point?
* being for dynamically allocated objects only, [] being for
"static-allocated" objects only.
I'm sure I never said any such thing. You're misreading, or lying.
