473,320 Members | 1,950 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,320 software developers and data experts.

Requesting advice how to clean up C code for validating string represents integer

I'm working on examples of programming in several languages, all
(except PHP) running under CGI so that I can show both the source
files and the actually running of the examples online. The first
set of examples, after decoding the HTML FORM contents, merely
verifies the text within a field to make sure it is a valid
representation of an integer, without any junk thrown in, i.e. it
must satisfy the regular expression: ^ *[-+]?[0-9]+ *$

If the contents of the field are wrong I want to diagnose as much
as reasonable what's wrong, not just say "syntax error".

Because perl and PHP include support for regular expressions, it
was obvious how to do it, and easy to accomplish:
http://www.rawbw.com/~rem/HelloPlus/...html#h4intperl
http://www.rawbw.com/~rem/HelloPlus/....html#h4intphp

Because Common Lisp has good utilities for scanning strings, mostly
using position, position-if, and position-if-not, it was equally
easy, and equally obvious, how to do it:
http://www.rawbw.com/~rem/HelloPlus/...html#h4intlisp

The Java API is missing some of the functions available in Common
Lisp, so I had to augment the API, but then it was as easy as in
Common Lisp, with nearly the same algorithm:
http://www.rawbw.com/~rem/HelloPlus/...html#h4intjava

Now we come to C: I presently have a horrible mess:
http://www.rawbw.com/~rem/HelloPlus/...4s.html#h4intc
I'm thinking of pulling out all the character-case testing into a
function that converts a character into a class-number (such as 1
for space, 2 for digit, 3 for sign, etc.), calling that all over
the place, and the using a SELECT statement on the result, which
won't change the logic of the code but might make it tidier.
Alternately I might hand-code replacements for the Lisp/Java
utilities for scanning strings, or find something in one of the C
libraries that would help, and then translate the Lisp or Java code
to C. Do any of you have any other ideas what I might do to clean
up the C code? Don't write my code for me, but just give hints what
library routines might do 90% of the work for me, or suggest
re-design of the algorithm? One thing I don't want to do is
download a REGEX package for C. I'm trying to give examples of how
to do things from scratch in C, not how to simply use somebody
else's program, even if the source for the REGEX module is
available. If something isn't in the a standard library for C, then
it doesn't exist for the purpose of this project. (The only
exception I made is the module for collecting and decoding HTML
FORM contents, which is a prerequisite for this whole project.)
Feb 11 '07
232 13038
From: "Malcolm McLean" <regniz...@btinternet.com>
In the C standard the term "object" has a very specific
definition. When most C programmers use the term "object" they
are not using it in this sense, probably even when specifically
discussing C.
Maybe. I'm still wondering what "region" means in the definition.
The standard is an important document,
In specifying behaviour of C programs and the syntax that generates
that behaviour, but:
so we can hardly hold that it is wrong to use its terminology,
Not necessarily so. I don't quite see how the ANSI/ISO standard
requires us to use terminology in any particular way when
discussing C in any context other than further work on the standard
itself.
even where it is somewhat eccentric.
Yeah. Now you're warming up.
However we cannot allow it to totally dictate our discourse.
There aren't enough words for that.
I.e. if all the words we would normally use are re-defined by the
government to be useless to us, and we are disallowed from using
the words in the old way or any other way, the we become unable to
carry on effective discussion. Orwell in 1984 predicted something
like that, and ANSI/ISO and IAU seems to have shown him correct.
(Not to mention the military too!)
Or in programming terms, they have polluted our namespace.
Ah, now you're at the top!! Perfect wording, even if a bit C++ish.
I'm usually one for fighting pollution, whether it be "military
intelligence" or "friendly fire" or "collateral damage" or
cigarette smoke or monosodium glutamate or nipponese/engrish. So
maybe this part of this thread is part of the war on pollutions.

But every so often one of these is rather humorous:

-- Babel Fish Translation of the Day (from Spanish):
I have an antenna of satellite in the roof, and a neighbor malafolla
me disoriented it whenever she raised to tend, until I greased it of
motor fat, random change in the design that was in an improvement of
the stability of the signal.
Feb 24 '07 #101
From: CBFalconer <cbfalco...@yahoo.com>
But I have no idea why the referenced web page applies the
"GNU-c" tag to the isblank() and strtoll() functions, both of
which are standard C (but both are new in C99).
I believe the referenced page is authored by Maas.
Yeah. The online documentation I was reading, about the GNU C
compiler, seemed to say those functions were additions to C.
Perhaps that documentation was written prior to the 1999 standard
and hasn't yet been updated. Now I wish there was a plain-ASCII
version of the 1999 standard accessible so I could refer to it
instead of having to collate various random documentation I find
elsewhere. Anyway, I've pretty much decided to distinguish between
pre-1999-standard functions which all existing C compilers would
have, and new-in-1999 functions which some compilers such as GNU C
may have had before then but might still be missing in some
compilers somebody might be trying to use to learn C. Unfortunately
without access to the 1999 standard, this decision will be
difficult to implement. Accordingly I plan to downplay the
distinction, pretend *all* functions I find *anywhere* are in fact
available *everywhere* except per footnote hardly anyone will
bother to read but which will cover my ass in case of dispute (like
that fine-print warning label on consumer products). Since I'm not
getting paid for any of this work, why should I care if somebody
asks for their money back? What money??
If Yevgen scans old posts in this newsgroup for Maas's posts
(google is handy for this), and the myriad corrections required,
he may be able to evaluate the accuracy of that page, at least as
far as it applies to C.
The real test of C understanding is the ability to get software
working, especially getting it safe against user input, especially
in this day of deliberate crafting of viruses/worms/trojans/bots
which take advantage of any possible memory leak/eavesdrop/overwrite.
Hmm, I wonder if MS-IE and MS-Windows are written in C and that's
part of why MS can never quite get them secure against trespass?
For example, buffer overflow is natural with pointer arithmetic,
all you need is a teensy programmer bug overlooked admist the
kilometers of source code that needs eyeballing to find anything,
but buffer overflow is impossible in Java or Common Lisp.
Is 20% speed gain really more important than security?
</flamebait>
^ attempting to close an element which was not open
(another thread, check on Google if you're curious)

But the test of participation in a newsgroup is whether people
learn new things, no matter how much they didn't know at the start.
I've learned several things so-far in this thread, perhaps nothing
useful [1], but still interesting.

[1] StarTrek-TOS reference: "It does not feed Vall ..."
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
That's a great quote to use in rebuttal to your comment about my
ignorance early in this thread. I've done a lot of research, which
involves trying a lot of bad ideas, but discarding most of them
quickly enough to still allow time for pursuing the better ideas
and thereby achieving lots of various successes. (Well, *technical*
successes anyway. I still haven't found a way to market any of my
major inventions, and since I passed 40 I haven't even been able to
find anybody willing to hire me for routine software work.)

To play a guessing game based on my many technical successes:
<http://shell.rawbw.com/~rem/cgi-bin/topscript.cgi>
Select: (*) Random words from file
Then click on: Start the demo of SegMat per above selections
To pick a different example, go back up and click Start the demo again.
Lather, rinse, repeat.
Feb 24 '07 #102
robert maas, see http://tinyurl.com/uh3t wrote:
From: CBFalconer <cbfalco...@yahoo.com>
But I have no idea why the referenced web page applies the
"GNU-c" tag to the isblank() and strtoll() functions, both of
which are standard C (but both are new in C99).
I believe the referenced page is authored by Maas.

Yeah. The online documentation I was reading, about the GNU C
compiler, seemed to say those functions were additions to C.
Perhaps that documentation was written prior to the 1999 standard
and hasn't yet been updated. Now I wish there was a plain-ASCII
version of the 1999 standard accessible so I could refer to it
instead of having to collate various random documentation I find
elsewhere. Anyway, I've pretty much decided to distinguish between
pre-1999-standard functions which all existing C compilers would
have, and new-in-1999 functions which some compilers such as GNU C
may have had before then but might still be missing in some
compilers somebody might be trying to use to learn C. Unfortunately
without access to the 1999 standard, this decision will be
difficult to implement.
You'll have to buy the actual Standard, but the latest working paper,
which includes two added Technical Corrigenda is available for free:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf>

CBFalconer has a pure text version of the final C99 draft at:

<http://cbfalconer.home.att.net/download/n869_txt.bz2>

<snip>

Feb 24 '07 #103
robert maas, see http://tinyurl.com/uh3t wrote, On 24/02/07 17:04:
>From: CBFalconer <cbfalco...@yahoo.com>
>>But I have no idea why the referenced web page applies the
"GNU-c" tag to the isblank() and strtoll() functions, both of
which are standard C (but both are new in C99).
I believe the referenced page is authored by Maas.

Yeah. The online documentation I was reading, about the GNU C
compiler, seemed to say those functions were additions to C.
Perhaps that documentation was written prior to the 1999 standard
and hasn't yet been updated. Now I wish there was a plain-ASCII
version of the 1999 standard accessible so I could refer to it
instead of having to collate various random documentation I find
elsewhere. Anyway, I've pretty much decided to distinguish between
pre-1999-standard functions which all existing C compilers would
have, and new-in-1999 functions which some compilers such as GNU C
may have had before then but might still be missing in some
compilers somebody might be trying to use to learn C. Unfortunately
without access to the 1999 standard, this decision will be
difficult to implement.
It's a good job you have access to it then, isn't it. If no one has
given you the details before, then go here
http://www.clc-wiki.net/wiki/c_standard and follow the links.
Accordingly I plan to downplay the
distinction, pretend *all* functions I find *anywhere* are in fact
available *everywhere* except per footnote hardly anyone will
bother to read but which will cover my ass in case of dispute (like
that fine-print warning label on consumer products). Since I'm not
getting paid for any of this work, why should I care if somebody
asks for their money back? What money??
So you want to make your page a pain for your intended audience. How
kind of you.
>If Yevgen scans old posts in this newsgroup for Maas's posts
(google is handy for this), and the myriad corrections required,
he may be able to evaluate the accuracy of that page, at least as
far as it applies to C.

The real test of C understanding is the ability to get software
working,
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.
especially getting it safe against user input, especially
in this day of deliberate crafting of viruses/worms/trojans/bots
which take advantage of any possible memory leak/eavesdrop/overwrite.
If you don't understand the language then how do you expect to be able
to develop anything that is robust?
Hmm, I wonder if MS-IE and MS-Windows are written in C and that's
part of why MS can never quite get them secure against trespass?
I would currently trust software from MS a lot more than I would trust
software from you.
For example, buffer overflow is natural with pointer arithmetic,
all you need is a teensy programmer bug overlooked admist the
kilometers of source code that needs eyeballing to find anything,
but buffer overflow is impossible in Java or Common Lisp.
I've never had to go back over all of any significantly complex program
I've written.
Is 20% speed gain really more important than security?
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.
</flamebait>
^ attempting to close an element which was not open
(another thread, check on Google if you're curious)

But the test of participation in a newsgroup is whether people
learn new things, no matter how much they didn't know at the start.
I've learned several things so-far in this thread, perhaps nothing
useful [1], but still interesting.
If you have learnt nothing useful then you have missed the point of a
lot of posts.
[1] StarTrek-TOS reference: "It does not feed Vall ..."
>"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA

That's a great quote to use in rebuttal to your comment about my
ignorance early in this thread. I've done a lot of research, which
involves trying a lot of bad ideas, but discarding most of them
quickly enough to still allow time for pursuing the better ideas
and thereby achieving lots of various successes. (Well, *technical*
successes anyway. I still haven't found a way to market any of my
major inventions, and since I passed 40 I haven't even been able to
find anybody willing to hire me for routine software work.)
Based on what I've seen so far I would not hire you. There are far too
many misconceptions in your web pages, such as being able to compare
unrelated pointers, right shifting a negative number 0 fills, * being
for dynamically allocated objects only, [] being for "static-allocated"
objects only.
--
Flash Gordon
Feb 24 '07 #104
From: Yevgen Muntyan <muntyan.removet...@tamu.edu>
I figured it'd better to ask instead of stating that something is
nonsense, this thread shows that the former is more likely to work.
The first lesson I learned when I first had access to newsgroups
(via mailing lists at the time, I didn't get direct newsgroup
access until about ten years later) was that asking a question
hardly ever results in anyone providing an answer whereas posting a
wrong guess usually does elicit corrections which thereby provide
an answer to the actual question.

Unfortunately I'm too shy to deliberately post guesses as if
answers, so most of the time I post a question and it never gets
answered. I have a large list of SQWA (Specific Questions Waiting
for a Answer) from long ago. Nowadays the net is slightly better at
getting questions answered, so maybe I should pull out my old SQWA
list and try asking some of them to see if I can finally get
answers. Unfortunately my diskettes where all my old files are
archived aren't readable lately, and this tiny "apartment" (smaller
than a motel room) doesn't have enough space near the computer to
plug in my SyQuest drive where I have a backup of the diskettes.
If this guy knows google-fu well enough,
I don't know that language. I did a Google search on that term, and
the first match told me it's a take-off from Kung Fu jargon: It
means mastery of picking effective Google search terms to find
desired information. Just about the first thing I learned from
doing searches (Lycos, Web Crawler, AltaVista, etc.) is that if I
know the specific jargon keyword for a topic, and that's a rare
word in ordinary usage, then I get results, but any time I have to
use common ordinary words as search terms I get dismal results.
It's not like Kung Fu where you can have great skill. It's more
like whether you are fortunate to know the specific jargon or not.

WikiPedia is helping by collecting together lots of various
references under an "umbrella" of some common everyday term,
including disambiguation pages, whereby you can be led to the
appropriate jargon, after which a regular search is likely to
succeed, except at that point WikiPedia has probably answered your
question already so you don't need to do the search now.
he can even get readers,
I have no idea how mastery of picking good search terms to get
answers to questions would help me find readers for my
multi-programming-language "cookbook".
and those readers might even read what he wrote out there.
Isn't that a bit redundant, like wet water?
Silly code pieces are not as bad as things like "GNU-c" or what
he says about character type.
Hmm, I looked it up in K&R just now to refresh my memory. It seems
type 'char' is a single byte of memory, but that might be signed or
unsigned, might be 8 bits or 9 bits, might be ASCII or EBCDIC, and
if signed might or might not sign-extend when cast to an integer
type. Did I miss anything? Let me check what I say that might need
fixing ... hmm, I cleaned up a few comments about characters,
including inserting warnings about IBM mainframes that use EBCDIC,
how does it look now?

What do you mean by "silly code pieces"?? Do you mean examples of
how to use the basic operations I've described, including live
CGI-runnable demo-applications? Except for the essential code to
interface to the CGI environment, which isn't explained, just
presented for everyone to copy/adapt/rewrite, I don't have any such
examples yet, at least nothing more complicated than adding 1,2,3
to the number you entered in the form and watching it wrap around
if you enter close to the maximum allowed value for that datatype.
(And watch it *not* wrap in the lisp example.)
The former won't be used by anyone,
I've actually started to use it myself on occasion. Sometimes when
I want to relate two data types it's easier to look in my Matrix
than to look in the regular documentation. I presume as I get it
more complete it'll be more useful in that way, not just to me
(somebody who knows what I've put in already, just can't remember
the details without looking back at it), but to others (who have no
idea what's included and what's missing and present would be rather
frustrated at the mere 5-10% coverage, like 50% of c, 40% of
equivalent c++, and only a tiny fraction of the other four
languages).

(No, that's not a *subtraction* minus there between 5 and 10, no
matter how you might feel. Should I have used .. instead?)
the latter will be memorized, unintentionally.
Why would anybody bother to memorize something that's available
online for reference any time they want?? Besides, by the time any
large number of peple see my work, you have spotted all the
mistakes and prodded me into fixing them, right?
Anyway, too tired to speak English.
Hey, maybe you can help me with my foreign-language translations?
BabelFish is giving me really weird results most of the time:
For example:
! the President congratulated to all those that have been able to remove
! in front of form consensuada la reform from the Statute de Baleares
or:
! the President emphasized in the plenary session of the Senate,
! where occurred Balearic to the approval to the new Statute of,
! which this reform has gone in 'better direcci{o'}n' and shows that
! is compatible el avance of our country con el increase of the
! self-government, of the competitions, of the proximity of the
! institutions to administered and with reconocimiento de the
! 'plural one, rich and singular' identity of the Balearic islands

At least this one is close enough that I can figure out what it means:
! Rodriguez Zapatero and the president of Korea South del commit
! themselves to favor greater commercial interchanges")

Hmm, maybe I should write a BabelFish converter for software!
Select the language pair:
[C to C++ ]
[C to Lisp ]
[C to Java ]
[C to Perl ]
[C++ to Lisp ]
[C++ to Java ]
[Java to Lisp]
[Perl to Lisp]
[Perl to Java]
[Perl to PHP ]
(Does anybody notice the deliberate directional bias?)
Feb 24 '07 #105
re*****@yahoo.com (robert maas, see http://tinyurl.com/uh3t) writes:
>From: "Malcolm McLean" <regniz...@btinternet.com>
In the C standard the term "object" has a very specific
definition. When most C programmers use the term "object" they
are not using it in this sense, probably even when specifically
discussing C.

Maybe. I'm still wondering what "region" means in the definition.
It's an ordinary English word for which the standard provides no
specialized definition. Do you also wonder about the meanings of
"of", "data", and "storage"? The standard does not attempt to be an
unabridged dictionary.

If the standard's definition of "object":

region of data storage in the execution environment, the contents
of which can represent values

confuses you, then this is the right place to ask for clarification.
I suspect that producing a definition for "region" won't make it any
clearer; any such definition must use other words, which themselves
need to be defined.
>The standard is an important document,

In specifying behaviour of C programs and the syntax that generates
that behaviour, but:
>so we can hardly hold that it is wrong to use its terminology,

Not necessarily so. I don't quite see how the ANSI/ISO standard
requires us to use terminology in any particular way when
discussing C in any context other than further work on the standard
itself.
The standard does not *require* us to use its terminology. In fact,
the standard doesn't require anybody to do anything. It's effectively
a contract between implementers and users, but no implementer or user
is *required* to accept it. You can write a non-conforming C compiler
if you like, and you can write non-portable C programs if you like;
nobody is going to arrest or sue you for doing so, unless perhaps you
fraudulently claim comformance. (There may be some externally imposed
requirements to conform to the standard; if so, it's up to you to meet
those requirements or not.)

*However*, this newsgroup, by general consensus of (most of) the
participants, discusses the C programming language as defined by
(various versions of) the C standard, and we find that using terms as
the standard defines them makes communication much easier.

If you choose to use terms defined by the standard in ways that
conflict with the way the standard defines them, nobody is going to
come pounding on your door in the middle of the night. You're just
going to have difficulty communicating in this newsgroup.

If you use a term that's defined by the standard, I (and probably
others) will assume that you meant to use it in accordance with the
way the standard defines it. If your usage is clearly inconsistent
with that, I (and probably others) will probably point it out as an
error on your part -- or we might not bother. That's the reality
here. Nobody is asking you to agree that it's a good thing; I'm
simply informing you of the way things are. You can deal with it, or
you can find yourself in a lot of killfiles -- because nobody requires
*us* to communicate with *you* if you're unwilling to follow a
reasonable set of guidelines.

You're perfectly free to use the term "object", for example, in its
OOP sense; if you do so, I advise you to make it explicit that you're
using it that way. It's really not difficult.

[snip]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 24 '07 #106
re*****@yahoo.com (robert maas, see http://tinyurl.com/uh3t) writes:
>From: CBFalconer <cbfalco...@yahoo.com>
But I have no idea why the referenced web page applies the
"GNU-c" tag to the isblank() and strtoll() functions, both of
which are standard C (but both are new in C99).
I believe the referenced page is authored by Maas.

Yeah. The online documentation I was reading, about the GNU C
compiler, seemed to say those functions were additions to C.
Perhaps that documentation was written prior to the 1999 standard
and hasn't yet been updated. Now I wish there was a plain-ASCII
version of the 1999 standard accessible so I could refer to it
instead of having to collate various random documentation I find
elsewhere.
Are you unable to read PDF files? I understand you're using an old
and limited computer system, but there are cost-free PDF viewers that
should work for you.

If you can't deal with PDF, search for "n869.txt"; it's a committee
draft dated Jan 18, 1999. There are a few significant differences
between n869 and the actual C99 standard.
Anyway, I've pretty much decided to distinguish between
pre-1999-standard functions which all existing C compilers would
have, and new-in-1999 functions which some compilers such as GNU C
may have had before then but might still be missing in some
compilers somebody might be trying to use to learn C. Unfortunately
without access to the 1999 standard, this decision will be
difficult to implement. Accordingly I plan to downplay the
distinction, pretend *all* functions I find *anywhere* are in fact
available *everywhere* except per footnote hardly anyone will
bother to read but which will cover my ass in case of dispute (like
that fine-print warning label on consumer products). Since I'm not
getting paid for any of this work, why should I care if somebody
asks for their money back? What money??
You're creating a reference work and making it generally available.
In my opinion, you have an ethical obligation to make it as accurate
as possible, for reasons that have nothing to do with money. That is,
as I said, merely my opinion.

[...]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 24 '07 #107
From: Chris Dollin <chris.dol...@hp.com>
Actually no. The idea was that an lvalue was the /value/ that was
obtained by evaluating an expression which was to be assigned to,
No wonder everyone is confused.
/I'm/ not confused. Not about this.
You can't assign to a value. You can only assign a value, to
something else, something not a value. It makes no sense to assign
*to* a value. I'm not talking about <jargon>dereferencing</jargon>
(actually indirect-address or index-register storing in more
sensical machine-language jargon) a pointer value. Now if you want
to make the claim that an lvalue in c is really a pointer, I'd be
willing to listen to your argument. But I'm not going to just
assume you mean that unless you say so and give some reasoable
argument that it covers all cases. (Hmm, if this were baseball, the
cliche would be covers all bases. You get it? Agreement of first
letter of word. Nah, that's just a coincidence.)
The /evaluation/ of the expression `x` will yield an lvalue,
which we can usefully think of as "the address of x".
I have no idea what "evaluation" means in c. In Lisp it means
passing a data-structure to the function EVAL and getting back the
'evaluation' of that expression. There's nothing like that in c,
and in Lisp you certainly don't get back the address of the
expression or anything equivalent or even close.

In fact what you said makes no sense. The address of the expression
is the location of the 'x' byte in the source code. That's the only
place the expression 'x' is located where it could be found later,
in the source file. There's a copy of that byte from the source
file momentarily during compilation, but not anywhere you could
post an address where to find it still there later. If it's
declared external, then there's a symbol-table entry for it in the
compiled object file, to be used by the linker/loader. But at run
time there's no access to either the source file or the linker
symbol table.

So let's back off a bit. This so-called 'evaluation' which you
claims happens in c, happens when/where? In the compiler during
compilation? Or at runtime?? Or some other time?
I admire your ability to produce a cogent and informed argument.
I worry about your ability to juggle junk jargon.
Expressions that "denote a place" are those that can be evaluated
for their lvalues. Those that don't, can't.
What does "evaluated" mean in the context of c?
An 'lvalue' is *not* any kind of value, right?
You can't pass an lvalue as an actual argument to a function,
nor return a lvalue as the result from a function,
nor read an lvalue from an input file,
nor write a lvalue to an output file,
nor store an lvalue somewhere,
nor define a struct to have an lvalue as one of its component slots,
nor define an array of lvalues,
right?
Consider something like
fun f( x ) = ... x := x + 1 ...
... f( 1 ) ...
in a language with pass-by-binding (the formal argument is
bound to the (l)value of the actual argument). The body of
`f` can dink around with `x`, even if the actual argument
is a literal, and without affecting /all/ the places where
the value of `1` is required.
That sounds to me more like the dreaded "undefined behaviour".
For example, suppose in some implemetation of that hypothetical
programming language, all literals are pooled. So wherever the
literal value 1 occurs in a program, that piece of code always
references that single memory-location where that 1 is located in
the pool. So when that f(1) call is executed, the code that gets
executed (assuming passing args via registers) is something like:

load ix1,adr1 ;Loads address of pool1, into index register 1
jsr f

f: load reg1,0(ix1) ;Loads value 1 from pool1, into general register 1
add reg1,pool1 ;Adds value 1 from pool1, getting value 2
store reg1,0(ix1) ;Stores value 2 to pool1
ret

adr1: address pool1 ;Address of pool1, which itself is also in the pool
pool1: integer 1 ;Initial value of 1 in the pool, changed by call to f

Now pool1 contains the integer 2, so if f is ever called again
it'll add 2 to its argument.
Your FORTRAN example demonstrates why it can be better for each
(l)evaluation of `1` to yield a /new/ lvalue, not the same one
every time.
You mean you'd actually be willing to write applications in a
programming language where every time you pass a literal to a
function it allocates more memory and copies the literal to the new
memory and tells the function where to find that newly-allocated
memory containing the copy of the literal?? Since the function
might keep a copy of the pointer, and store that pointer other
places, you can never release that memory, because you have no way
to know if somebody else is still referencing that allocated copy
of the literal. Talk about memory leak!!! (Don't you ever complain
that Lisp is slow or wastes memory after what you've just
advocated!!)

Alterately I suppose you could avoid the memory leak by allocating
a static or stack variable for each such constant-copy storage
location. Effectively it'd be as if you had written this instead:
{ int tmp = 1;
f(tmp); }

With that restriction, you can do that already in C, coding all
those call-by-address yourself:
{ int tmp = 1;
f(&tmp); }
And if you don't want to erase those side-effects each time you are
back at this same piece of code, write this instead:
{ static int tmp = 1;
f(&tmp); }
So just write a replacement for all the standard libraries where
all arguments are pointers to the actual argument, and write all
your own functions the same way, and always use & to pass addresses
of actual arguments, and the C compiler will already forbid you
from saying f(&1).

Now back to the original idea of allocating new memory for each
call: If you're talking about a system with automatic garbage
collection like lisp, then of course there's no memory leak. I
actually started work on a lisp-like system that always passed
addresses so that any function could modify the variable or array
element or structure slot or any other variable place that was
passed (and of course you'd be forbidden to pass literals or other
constants directly to a function that modifies its argument,
because the compiler would know they had the 'const' property like
in C++, so they can be passed only to parameters which also have th
'const' property).
To store a value
into a place you need to know what function to call to effect the
storage.
(`affect`, not `effect`)
Oops. Typo.
No; in fact you don't. You can have a uniform way of /updating/
the store, and different ways of computing the lvalue. Since
the update is "done" by an operation which is roughly
update( store, lvalue, rvalue )
The PDP-10 had something like this called a "byte pointer", which
provided as a unit all of:
- the machine address of the word containing the byte
- the offset of the byte within the word
- the number of bits in the byte
So if your storage units were always smaller than a 36-bit machine
word and never crossed a word boundary, you could specify a
"location" of a byte via a "byte pointer". The instructions LDB
(Load Byte) and DPB (Deposit Byte) did the obvious thing (loading a
byte and shifting into rightmost part of word, or shifting byte out
of rightmost part of word to desired part when storing).

So a single byte pointer could refer to anything from a single bit
(such as in an extremely large bit array where you have to pack the
bits rather than spread them one-per-word) up to a full 36-bit
word. Thus a byte pointer could be the 'lvalue' you speak of.

On virtually any other machine class, you'd need a struct to
represent an lvalue as a single unit of information. I don't see
that ever used in general, due to lower efficiency compared to
bypassing that level of abstraction to generate the specific
machine code needed directly from the parse tree of the source.

Also, I don't understand what that parameter 'store' is in your
call to the update function/macro. Is that an ENUM constant, to
select one of several types of update operation (the other value of
that ENUM perhaps being 'load'), or do you really have a parameter
called 'store' and if so what value do you pass as the 'store'
parameter??
Common Lisp clarifies the whole idea best with SETF.
That's a matter of opinion: whether it's a "clarification" to
make assignment depend on that systematic use of macros is ...
a choice.
All programming languages (except some assembly languages) have a
set of compiler rules, such as when the compiler sees anything of
the form
arr[index] = something
it generates code to compute the address of an array element and
the store some value into the memory location pointed-at. Whether
these are called rules or macros makes no difference in concept,
except that Common Lisp allows any old user to extend the set of
such compile-time interpretations of source code to work with new
user-defined structures just as well as it always worked with
language-defined structures such as arrays.

But that's not the point I was making. My point is that any
source-expression pattern that when used on the right side of a
assignment generates code to fetch a value from a slot within some
data structure, can in principle just as well be used on the left
side of a assignment to generate code to store a value in the same
place. The place where you fetch or store a value is *not* itself a
value, it's just a **place** (or slot). The data entity which you
fetch or store, *that* is a value. There's a difference between a
place, where values are located, and a value, which is stored at
some place. To use 'lvalue' to represent a place where a value is
stored, but to use 'rvalue' to represent the actual value, is
assymetric, and IMO midrot jargon. Better to have symmetric jargon.

Analagously there's difference between an address, such as "140
Main Street" (quotes because I'm talking about the address, what
you see on an envelope, not whatever is at that address), and
whatever is at that address, such as a vacant lot or a house or
office building. (Hmm, I checked with Google, and it's a three
bedroom house for sale, at least at that address in one town in CT
anyway.) I would never refer to the address as an lhouse, like
saying "be sure to write the lhouse on the envelope".

I suppose you could think of the so-called lvalue as a city lot, on
which at various times there might be a grassy pasture or a
Victorian house or a demolished house or a newly rebuilt Eichler
house or another demolished house or a block of apartment buildings.
I don't like calling the house a rvalue and the lot it's on an lvalue.

Gee, it's so easy to get sidetracked by Google. In another city
(namespace), the corresponding address has an antique shop, and in
another it's part of a hotel.

Or think of a toilet stall and whoever happens to be using that
stall at any particular time. Is the person an rperson and the
stall an lperson??
(I'm using c notation here to make it easier for you to understand):
Why do you think using C will do that? It's not as though I'm
unfamiliar with Lisp, after all.
Oh. Since most people here aren't familiar with lisp (after all,
why would anybody use c, except for writing operating systems such
as Linux), after they have seen the light of how much better lisp
is), and since you seem to dismiss all lisp jargon, I just assumed
you weren't as familar with lisp as you are with c. Also for the
benefit of the other "you"s, as in "you-all", all the readers of
this thread, not just you singular. So I thought in a c group it
would be polite to express an algorithm in c if it was easy.
You can do something very similar using Pop11's updaters. They
don't use macros to do it: they use functions plus one assignment
rewrite rule.
"assignment rewrite rule" sounds to me like another way of saying
"setf method". How are they in any way different conceptually?
You somehow tell the compiler what code to actually generate with
it sees function(args) on left side of assigment, by some kind of
rewriting it to call a different function that is used for storage,
or maybe the same function but with a different parameter
combination that invokes storage instead of fetch, right? Or did I
miss what "assignment rewrite rule" means? How is "rewrite" any
different from "macro" in general anyway?? A macro is nothing but a
way of rewriting the source code so something newly generated (the
result of the macro-expansion or source-rewrite) will be compiled,
right?

I tried a Google search on that, but couldn't find relevant info
before I got really tired and in need of a nap.
Feb 25 '07 #108
"robert maas, see http://tinyurl.com/uh3t" wrote:
From: CBFalconer <cbfalco...@yahoo.com>
>>
>>But I have no idea why the referenced web page applies the
"GNU-c" tag to the isblank() and strtoll() functions, both of
which are standard C (but both are new in C99).

I believe the referenced page is authored by Maas.

Yeah. The online documentation I was reading, about the GNU C
compiler, seemed to say those functions were additions to C.
Perhaps that documentation was written prior to the 1999 standard
and hasn't yet been updated. Now I wish there was a plain-ASCII
version of the 1999 standard accessible so I could refer to it
instead of having to collate various random documentation I find
elsewhere. ...snip ...
There is. See <http://cbfalconer.home.att.net/download/>

Please don't remove attributions for material you quote. And
please do not remove blank lines between paragraphs, quotes, etc.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Feb 25 '07 #109
Flash Gordon wrote:
Yevgen Muntyan wrote, On 20/02/07 03:54:
>robert maas, see http://tinyurl.com/uh3t wrote:
>>>From: Yevgen Muntyan <muntyan.removet...@tamu.edu>
Start at the top of:
<http://www.rawbw.com/~rem/HelloPlus/CookBook/Matrix.html>
What's "GNU-c" and why are some functions "GNU-c" while others
are "c"? Then some people read it and think they use GNU-c,
as some people use C/C++...

I'm trying to warn the reader about some functions which aren't
defined in the official standard, but *are* available in GNU C
which is perhaps the most popular implementation (of compiler and
loader-commands to use corresponding libraries), so the reader
won't be totally confused if he writes code relying on such a
library function but it's not available in the implementation he's
using.

Imagine your reader is Windows or *BSD or MacOSX or Solaris user.
Does he care about popular implementations? Just don't mention
GNU-only functions at all. Good news is that you won't have to,
there are not so many GNU-only, BSD-only, Whatever-only functions
of general use.

As a strong supporter of sticking to standard C where possibly I
strongly disagree. There are a vast number of system specific functions
which are extremely useful, it's just that they are not topical here.
"of general use" was meant to say something like "which do stuff
you'd need in your cookthing". How many useful functions
do you know which are GNU-only, BSD-only, Whatever-only,
and which are useful enough to write somewhat-portable
programs? Say, strndup() is GNU-only (at least man page
says so, and it's not available in FreeBSD). You use it,
and your program doesn't compile on *BSD. It is a useful
function, but it's one of those which help to produce
"unix" software which works only on linux.
Anyway, of course there is lot of system-specific functions
which do lot of good. Do you not agree this guy should not
put those in his cooksomething?
I'd still be interesting to see *vast* number of functions
like that which do something of interest in that cookthing.
>>If you can suggest a better way to note this distinction
between functions guaranteed to be available in all conforming
implementations and those "extras" provided by major vendors,
please do. I don't like the idea of just having a caveat at the top
of the document saying "some of the c functions described below
aren't available in all implemetations of c". I'd rather
individually flag those very few which might not be available.

Now if the particular function is in the C99 spec, that would be
better to mention, but again I'd need some way of annotating those
functions which aren't in older C but are in C99 without confusing
the reader.

Better don't even try. Given that you don't know what's C99 and what's
GNU implementation of C library, imagine what reader will know after
reading your stuff. Just stick to C99.

Very poor advice. You will leave all the poor users of Visual Studio
Express wondering why they don't have snprintf (only _snprintf IIRC
which has significant differences) etc.
Then those poor people will learn their implementation sucks. Have
you seen swprintf function from microsoft? Should we avoid talking
about swprintf() because microsoft users will wonder why the function
is there but produces compilation errors? Anyway, the key part was
"imagine what reader will know after reading your stuff". "stick to C99"
is better than "provide random information like 'GNU-c'".
>
>[snip]
>>By the way, I hope my readers will look up the complete definition
of the function, using Google for example, any place my quickie
definition isn't quite complete in all details.

Is this how *you* get the documentation? You should consider something
better, like C libraries manuals, man pages, C standard. man pages
are pretty good, they tell you about the standards given function
conforms to.

When did you last look at the man pages on SCO, AIX, IRIX etc... I'm
sure some of them do what you say, but you do not know that all man
pages do not that the versions installed on the OPs system do. The
bibliography of the comp.lang.c FAQ references some good books and the
comp.lang.c FAQ is good.
I'll be surprised if that guy is reading man pages on SCO, AIX, IRIX.
Anyway, I wasn't telling the "How you should write documentation".
I have no idea how to write good documentation. But I *do* know
that man pages he will be reading are most likely better than
what he has.
Now, FAQ is just great, but FAQ is not a reference. Standard
is the best, but somehow I think that if one can read the standard
he simply won't consult man pages (except to check if implementation
agrees with the standard). If man pages suck, it's unfortunate.
Perhaps it'd be better to specify, read GNU or FreeBSD or (insert
something) man pages.
The best would be to shut down sites like that. If it's not
possible, then it's better if it contains stuff copied from better
sources than some made-up-cause-it-seems-so junk.

Dear newbie reading this stuff and thinking I am right: no way,
forget and ignore all I say.

Is this better now?

Yevgen
Feb 25 '07 #110
re*****@yahoo.com (robert maas, see http://tinyurl.com/uh3t) writes:
>From: Chris Dollin <chris.dol...@hp.com>
>Actually no. The idea was that an lvalue was the /value/ that was
obtained by evaluating an expression which was to be assigned to,
No wonder everyone is confused.
/I'm/ not confused. Not about this.
You're seriously messing up the attributions. Your news client should
handle this for you. Attribution lines shouldn't start with "From:";
some software inserts a '>' character in front of the word "From" at
the beginning of a line.

The block starting with "Actually, no.", and the one starting with
"/I'm/ not confused. Not about this.", were both written by Chris
Dollin. "No wonder everyone is confused." was written by robert maas.
You can't assign to a value. You can only assign a value, to
something else, something not a value.
An "lvalue", in the sense that Chris is using the word (which is not
the way the C standard defines it) is a value to which you can assign.
You can think of it as an address, or as a location. For example, given:

x = y + 1;

the expression x is evaluated for its lvalue (which indicates where to
assign the result of the RHS, without looking at the current
*contents* of x), and the expressions y, 1, and y + 1 are evaluated
for their rvalues (just ordinary values).

As has already been mentioned, though, the C standard uses a different
definition of "lvalue"; it's basically an expression that designates
an object.
>The /evaluation/ of the expression `x` will yield an lvalue,
which we can usefully think of as "the address of x".

I have no idea what "evaluation" means in c.
Evaluation is what happens when a value is computed from an
expression. It generally happens during program execution.

[huge snip]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 25 '07 #111
robert maas, see http://tinyurl.com/uh3t wrote:
>From: Yevgen Muntyan <muntyan.removet...@tamu.edu>
I figured it'd better to ask instead of stating that something is
nonsense, this thread shows that the former is more likely to work.

[snip why and how]
If you don't know something, just don't write docs about it.
If you don't know an answer for something, you may have
zillion reasons why you can't get an answer, but it doesn't
let you write guesses in form of documentation.
>If this guy knows google-fu well enough,

I don't know that language. I did a Google search on that term, and
the first match told me it's a take-off from Kung Fu jargon: It
means mastery of picking effective Google search terms to find
desired information.
There are two sides of it. One is searcher side, how to find something;
and another one is provider side, how to make google pick your
site. Hope you won't get to the other side ;)

[snip]
>he can even get readers,

I have no idea how mastery of picking good search terms to get
answers to questions would help me find readers for my
multi-programming-language "cookbook".
>and those readers might even read what he wrote out there.

Isn't that a bit redundant, like wet water?
It is.

[snip]
>The former won't be used by anyone,

I've actually started to use it myself on occasion.
You don't count. Writing notes for yourself is totally normal.
Claiming your notes is a textbook or a reference of some sort
isn't. (You may say that you don't claim anything, but there
is no clear disclaimer "BEWARE" cross the pages, and people
searching internet to get information tend to trust web pages
they read)

[snip]
>the latter will be memorized, unintentionally.

Why would anybody bother to memorize something that's available
online for reference any time they want??
This is the point! Simple things get memorized easily without
any effort. One may see "GNU-c", and then in months after that
make wrong decision because "hm, I recall it's not portable, let's
go other way". The danger of sites like yours is not that a careful
skeptical reader will trust it. No, it's some poor guy who just needs
to get some work done will read it, and later be beaten by it.
Besides, by the time any
large number of peple see my work, you have spotted all the
mistakes and prodded me into fixing them, right?
Of course not. You didn't notice warm feelings from many people
here to you? Regardless if you understand why they feel and think
this way or not, and regardless if they are right or not. Only
positive-minded careful critical review may help.

[snip]
Select the language pair:
[C to C++ ]
[C to Lisp ]
[C to Java ]
[C to Perl ]
[C++ to Lisp ]
[C++ to Java ]
[Java to Lisp]
[Perl to Lisp]
[Perl to Java]
[Perl to PHP ]
(Does anybody notice the deliberate directional bias?)
Maybe you should call your page "C and other funny languages
for LISP'ers"? Would help to avoid some confusion perhaps.

Yevgen
Feb 25 '07 #112
"robert maas, see http://tinyurl.com/uh3t" wrote:
>
.... snip ...
>
The first lesson I learned when I first had access to newsgroups
(via mailing lists at the time, I didn't get direct newsgroup
access until about ten years later) was that asking a question
hardly ever results in anyone providing an answer whereas posting a
wrong guess usually does elicit corrections which thereby provide
an answer to the actual question.
.... snip 100 lines on various subjects ...

You might do better with short, to the point, articles, rather than
your present rambling largely incoherent style. You are also
allowed to match the subject line with the article.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Feb 25 '07 #113
Yevgen Muntyan wrote, On 25/02/07 03:31:
Flash Gordon wrote:
>Yevgen Muntyan wrote, On 20/02/07 03:54:
>>robert maas, see http://tinyurl.com/uh3t wrote:
From: Yevgen Muntyan <muntyan.removet...@tamu.edu>
>Start at the top of:
><http://www.rawbw.com/~rem/HelloPlus/CookBook/Matrix.html>
What's "GNU-c" and why are some functions "GNU-c" while others
are "c"? Then some people read it and think they use GNU-c,
as some people use C/C++...

I'm trying to warn the reader about some functions which aren't
defined in the official standard, but *are* available in GNU C
which is perhaps the most popular implementation (of compiler and
loader-commands to use corresponding libraries), so the reader
won't be totally confused if he writes code relying on such a
library function but it's not available in the implementation he's
using.

Imagine your reader is Windows or *BSD or MacOSX or Solaris user.
Does he care about popular implementations? Just don't mention
GNU-only functions at all. Good news is that you won't have to,
there are not so many GNU-only, BSD-only, Whatever-only functions
of general use.

As a strong supporter of sticking to standard C where possibly I
strongly disagree. There are a vast number of system specific
functions which are extremely useful, it's just that they are not
topical here.

"of general use" was meant to say something like "which do stuff
you'd need in your cookthing". How many useful functions
do you know which are GNU-only, BSD-only, Whatever-only,
and which are useful enough to write somewhat-portable
programs? Say, strndup() is GNU-only (at least man page
says so, and it's not available in FreeBSD). You use it,
and your program doesn't compile on *BSD. It is a useful
function, but it's one of those which help to produce
"unix" software which works only on linux.
It is a useful function, but one easy to replicate on other systems so
hardly critical.
Anyway, of course there is lot of system-specific functions
which do lot of good. Do you not agree this guy should not
put those in his cooksomething?
I'd still be interesting to see *vast* number of functions
like that which do something of interest in that cookthing.
Functions for networking (getting MACs for NICs is very useful but IIRC
you need to go beyond POSIX on nix boxes to do it), functions for
graphics, functions for threads etc.

If a "CookBook" is going to cover such things, which is not
unreasonable, then it will need to cover system specifics. Of course, it
should clearly mark what is system specific.
>>>If you can suggest a better way to note this distinction
between functions guaranteed to be available in all conforming
implementations and those "extras" provided by major vendors,
please do. I don't like the idea of just having a caveat at the top
of the document saying "some of the c functions described below
aren't available in all implemetations of c". I'd rather
individually flag those very few which might not be available.

Now if the particular function is in the C99 spec, that would be
better to mention, but again I'd need some way of annotating those
functions which aren't in older C but are in C99 without confusing
the reader.

Better don't even try. Given that you don't know what's C99 and what's
GNU implementation of C library, imagine what reader will know after
reading your stuff. Just stick to C99.

Very poor advice. You will leave all the poor users of Visual Studio
Express wondering why they don't have snprintf (only _snprintf IIRC
which has significant differences) etc.

Then those poor people will learn their implementation sucks. Have
you seen swprintf function from microsoft?
If you tell them it is only in the latest standard and they find it is
not in the latest and greatest from <insert provider of dislikethen
they will not only learn that provider as not kept up but also what it
is the provider is not doing.
Should we avoid talking
about swprintf() because microsoft users will wonder why the function
is there but produces compilation errors? Anyway, the key part was
"imagine what reader will know after reading your stuff". "stick to C99"
is better than "provide random information like 'GNU-c'".
Providing random information about system specific stuff is bad for one
set of reasons (although non-random clearly marked system specifics is
not). Sticking to C99 only is bad for different reasons.
>>[snip]

By the way, I hope my readers will look up the complete definition
of the function, using Google for example, any place my quickie
definition isn't quite complete in all details.

Is this how *you* get the documentation? You should consider something
better, like C libraries manuals, man pages, C standard. man pages
are pretty good, they tell you about the standards given function
conforms to.

When did you last look at the man pages on SCO, AIX, IRIX etc... I'm
sure some of them do what you say, but you do not know that all man
pages do not that the versions installed on the OPs system do. The
bibliography of the comp.lang.c FAQ references some good books and the
comp.lang.c FAQ is good.

I'll be surprised if that guy is reading man pages on SCO, AIX, IRIX.
Anyway, I wasn't telling the "How you should write documentation".
I have no idea how to write good documentation. But I *do* know
that man pages he will be reading are most likely better than
what he has.
This chap has given the impression that he is using some form of remote
system which he probably does not own or control. Therefore, for all we
know, it *could* be one of those systems and it may or may not have the
man pages installed and they may or may not be any good.
Now, FAQ is just great, but FAQ is not a reference.
The bibliography for the FAQ mentions a number of good books as I said.
Standard
is the best, but somehow I think that if one can read the standard
he simply won't consult man pages (except to check if implementation
agrees with the standard). If man pages suck, it's unfortunate.
Perhaps it'd be better to specify, read GNU or FreeBSD or (insert
something) man pages.
The best would be to shut down sites like that. If it's not
possible, then it's better if it contains stuff copied from better
sources than some made-up-cause-it-seems-so junk.
I don't disagree with that, but unless you know what system someone has
access to then just recommending the man-pages is not quite a safe
option. Had you recommended a web site with man-pages (which do exist)
that you had checked were of decent quality, or had you known he was
using a system with decent man-pages it would be different.
Dear newbie reading this stuff and thinking I am right: no way,
forget and ignore all I say.

Is this better now?
Currently that warning belongs on Robert's site!
--
Flash Gordon
Feb 25 '07 #114
Yevgen Muntyan wrote, On 25/02/07 03:59:
robert maas, see http://tinyurl.com/uh3t wrote:
<snip>
>Besides, by the time any
large number of peple see my work, you have spotted all the
mistakes and prodded me into fixing them, right?
You have not fixed all of the errors that have been pointed out to you.
Of course not. You didn't notice warm feelings from many people
here to you? Regardless if you understand why they feel and think
this way or not, and regardless if they are right or not. Only
positive-minded careful critical review may help.
The only was to get people to fully review it is to fix the problems
already pointed out and then ask for further review.
>Select the language pair:
[C to C++ ]
[C to Lisp ]
[C to Java ]
[C to Perl ]
[C++ to Lisp ]
[C++ to Java ]
[Java to Lisp]
[Perl to Lisp]
[Perl to Java]
[Perl to PHP ]
(Does anybody notice the deliberate directional bias?)

Maybe you should call your page "C and other funny languages
for LISP'ers"? Would help to avoid some confusion perhaps.
Adding, "written by someone inexperienced in C and other languages"
might help.
--
Flash Gordon
Feb 25 '07 #115
Flash Gordon wrote:
Yevgen Muntyan wrote, On 25/02/07 03:31:
>Flash Gordon wrote:
>>Yevgen Muntyan wrote, On 20/02/07 03:54:
robert maas, see http://tinyurl.com/uh3t wrote:
>From: Yevgen Muntyan <muntyan.removet...@tamu.edu>
>>Start at the top of:
>><http://www.rawbw.com/~rem/HelloPlus/CookBook/Matrix.html>
>What's "GNU-c" and why are some functions "GNU-c" while others
>are "c"? Then some people read it and think they use GNU-c,
>as some people use C/C++...
>
I'm trying to warn the reader about some functions which aren't
defined in the official standard, but *are* available in GNU C
which is perhaps the most popular implementation (of compiler and
loader-commands to use corresponding libraries), so the reader
won't be totally confused if he writes code relying on such a
library function but it's not available in the implementation he's
using.

Imagine your reader is Windows or *BSD or MacOSX or Solaris user.
Does he care about popular implementations? Just don't mention
GNU-only functions at all. Good news is that you won't have to,
there are not so many GNU-only, BSD-only, Whatever-only functions
of general use.

As a strong supporter of sticking to standard C where possibly I
strongly disagree. There are a vast number of system specific
functions which are extremely useful, it's just that they are not
topical here.

"of general use" was meant to say something like "which do stuff
you'd need in your cookthing". How many useful functions
do you know which are GNU-only, BSD-only, Whatever-only,
and which are useful enough to write somewhat-portable
programs? Say, strndup() is GNU-only (at least man page
says so, and it's not available in FreeBSD). You use it,
and your program doesn't compile on *BSD. It is a useful
function, but it's one of those which help to produce
"unix" software which works only on linux.

It is a useful function, but one easy to replicate on other systems so
hardly critical.
>Anyway, of course there is lot of system-specific functions
which do lot of good. Do you not agree this guy should not
put those in his cooksomething?
I'd still be interesting to see *vast* number of functions
like that which do something of interest in that cookthing.

Functions for networking (getting MACs for NICs is very useful but IIRC
you need to go beyond POSIX on nix boxes to do it), functions for
graphics, functions for threads etc.

If a "CookBook" is going to cover such things, which is not
unreasonable, then it will need to cover system specifics.
"If", huh? Not unreasonable? Indeed, networking cookbook by OP is hardly
unreasonable. And, could you show vast number of GNU-only, SomeBSD-only,
Whatever-only functions, not just some random portablish POSIX,
Unix98, BSD functions?
Of course, it
should clearly mark what is system specific.
>>>>If you can suggest a better way to note this distinction
between functions guaranteed to be available in all conforming
implementations and those "extras" provided by major vendors,
please do. I don't like the idea of just having a caveat at the top
of the document saying "some of the c functions described below
aren't available in all implemetations of c". I'd rather
individually flag those very few which might not be available.
>
Now if the particular function is in the C99 spec, that would be
better to mention, but again I'd need some way of annotating those
functions which aren't in older C but are in C99 without confusing
the reader.

Better don't even try. Given that you don't know what's C99 and what's
GNU implementation of C library, imagine what reader will know after
reading your stuff. Just stick to C99.

Very poor advice. You will leave all the poor users of Visual Studio
Express wondering why they don't have snprintf (only _snprintf IIRC
which has significant differences) etc.

Then those poor people will learn their implementation sucks. Have
you seen swprintf function from microsoft?

If you tell them it is only in the latest standard and they find it is
not in the latest and greatest from <insert provider of dislikethen
they will not only learn that provider as not kept up but also what it
is the provider is not doing.
Which shows you did *not* see it. It is in microsoft C libs, signature
is different. Now, you're saying "if you tell them...". Do you mean
one must inspect all implementations out there (or maybe only Microsoft
one?) and then post information about their conformance wherever one
posts very name of a single function? It would be good but
not realistic. The original advice "don't even try" *for the OP* holds,
I think.
Should we avoid talking
about swprintf() because microsoft users will wonder why the function
is there but produces compilation errors? Anyway, the key part was
"imagine what reader will know after reading your stuff". "stick to C99"
is better than "provide random information like 'GNU-c'".

Providing random information about system specific stuff is bad for one
set of reasons (although non-random clearly marked system specifics is
not). Sticking to C99 only is bad for different reasons.
Which alternative is better? Better not for ultimate truth or something,
but for people who can obtain wrong information from the site.
>>>[snip]

By the way, I hope my readers will look up the complete definition
of the function, using Google for example, any place my quickie
definition isn't quite complete in all details.

Is this how *you* get the documentation? You should consider something
better, like C libraries manuals, man pages, C standard. man pages
are pretty good, they tell you about the standards given function
conforms to.

When did you last look at the man pages on SCO, AIX, IRIX etc... I'm
sure some of them do what you say, but you do not know that all man
pages do not that the versions installed on the OPs system do. The
bibliography of the comp.lang.c FAQ references some good books and
the comp.lang.c FAQ is good.

I'll be surprised if that guy is reading man pages on SCO, AIX, IRIX.
Anyway, I wasn't telling the "How you should write documentation".
I have no idea how to write good documentation. But I *do* know
that man pages he will be reading are most likely better than
what he has.

This chap has given the impression that he is using some form of remote
system which he probably does not own or control. Therefore, for all we
know, it *could* be one of those systems and it may or may not have the
man pages installed and they may or may not be any good.
"Could", indeed. It *could* be that man pages on the system he's using
are worse than what he's writing. While I can't deny such a possibility,
I doubt it's the case.
>Now, FAQ is just great, but FAQ is not a reference.

The bibliography for the FAQ mentions a number of good books as I said.
Which aren't read, if you didn't get it.
Standard
is the best, but somehow I think that if one can read the standard
he simply won't consult man pages (except to check if implementation
agrees with the standard). If man pages suck, it's unfortunate.
Perhaps it'd be better to specify, read GNU or FreeBSD or (insert
something) man pages.
The best would be to shut down sites like that. If it's not
possible, then it's better if it contains stuff copied from better
sources than some made-up-cause-it-seems-so junk.

I don't disagree with that, but unless you know what system someone has
access to then just recommending the man-pages is not quite a safe
option.
I do claim man pages OP has access to (if any) are better than his
writing. I am not saying "could not be worse", I am saying "they are".
You can speculate what you want about possibilities, it won't change
a thing.
Had you recommended a web site with man-pages (which do exist)
that you had checked were of decent quality, or had you known he was
using a system with decent man-pages it would be different.
It would be different. If I were a real C specialist and corrected
everything, it'd be even more different.
But, to my best knowledge, my above statement is right. Could be wrong,
indeed, perhaps. But you better present an example of man pages set
(OP could have access to as you say) which are worse than the
cookbook thing.

I am not sure what we are arguing about though. Did my advices
constitute a nice set of nice advices for folks writing docs?
Absolutely no. Did I recommend better stuff than the present content
of OP's site? Oh yes.

Yevgen
Feb 25 '07 #116
Yevgen Muntyan wrote, On 25/02/07 07:57:
Flash Gordon wrote:
>Yevgen Muntyan wrote, On 25/02/07 03:31:
>>Flash Gordon wrote:
Yevgen Muntyan wrote, On 20/02/07 03:54:
robert maas, see http://tinyurl.com/uh3t wrote:
>>From: Yevgen Muntyan <muntyan.removet...@tamu.edu>
>>>Start at the top of:
>>><http://www.rawbw.com/~rem/HelloPlus/CookBook/Matrix.html>
<snip>
>>>>>If you can suggest a better way to note this distinction
>between functions guaranteed to be available in all conforming
>implementations and those "extras" provided by major vendors,
>please do. I don't like the idea of just having a caveat at the top
>of the document saying "some of the c functions described below
>aren't available in all implemetations of c". I'd rather
>individually flag those very few which might not be available.
>>
>Now if the particular function is in the C99 spec, that would be
>better to mention, but again I'd need some way of annotating those
>functions which aren't in older C but are in C99 without confusing
>the reader.
>
Better don't even try. Given that you don't know what's C99 and what's
GNU implementation of C library, imagine what reader will know after
reading your stuff. Just stick to C99.

Very poor advice. You will leave all the poor users of Visual Studio
Express wondering why they don't have snprintf (only _snprintf IIRC
which has significant differences) etc.

Then those poor people will learn their implementation sucks. Have
you seen swprintf function from microsoft?

If you tell them it is only in the latest standard and they find it is
not in the latest and greatest from <insert provider of dislikethen
they will not only learn that provider as not kept up but also what it
is the provider is not doing.

Which shows you did *not* see it. It is in microsoft C libs, signature
is different. Now, you're saying "if you tell them...". Do you mean
one must inspect all implementations out there (or maybe only Microsoft
one?) and then post information about their conformance wherever one
posts very name of a single function? It would be good but
not realistic. The original advice "don't even try" *for the OP* holds,
I think.
No, I meant if you tell your *readers* that function X is C99 only and
your *reader* finds that is is not available in MS VC++, or whatever
other implementation, then your *reader* can judge on that basis whether
the company in question sucks.
> Should we avoid talking
about swprintf() because microsoft users will wonder why the function
is there but produces compilation errors? Anyway, the key part was
"imagine what reader will know after reading your stuff". "stick to C99"
is better than "provide random information like 'GNU-c'".

Providing random information about system specific stuff is bad for
one set of reasons (although non-random clearly marked system
specifics is not). Sticking to C99 only is bad for different reasons.

Which alternative is better? Better not for ultimate truth or something,
but for people who can obtain wrong information from the site.
It is better to specify anything that is not C89 is not C89 and what it
actually is, be it C99, POSIX, MS, GNU or whatever. The only standard
fully implemented by most compilers is C89, in particular gcc document
that their C99 implementation is not complete and MS VC++ does not even
attempt it, and that covers the bulk of new users who are not using
something written before C99 was even published. So stick to C89 (not
C99) as the base and then specify things in C99 or whatever as
appropriate and appropriately documented.
>>>>[snip]
>
>By the way, I hope my readers will look up the complete definition
>of the function, using Google for example, any place my quickie
>definition isn't quite complete in all details.
>
Is this how *you* get the documentation? You should consider something
better, like C libraries manuals, man pages, C standard. man pages
are pretty good, they tell you about the standards given function
conforms to.

When did you last look at the man pages on SCO, AIX, IRIX etc... I'm
sure some of them do what you say, but you do not know that all man
pages do not that the versions installed on the OPs system do. The
bibliography of the comp.lang.c FAQ references some good books and
the comp.lang.c FAQ is good.

I'll be surprised if that guy is reading man pages on SCO, AIX, IRIX.
Anyway, I wasn't telling the "How you should write documentation".
I have no idea how to write good documentation. But I *do* know
that man pages he will be reading are most likely better than
what he has.

This chap has given the impression that he is using some form of
remote system which he probably does not own or control. Therefore,
for all we know, it *could* be one of those systems and it may or may
not have the man pages installed and they may or may not be any good.

"Could", indeed. It *could* be that man pages on the system he's using
are worse than what he's writing. While I can't deny such a possibility,
I doubt it's the case.
I would expect that if there are man pages installed then they are
infinitely better than what he is writing. However, they may be no
better (or even worse than) what he finds when searching the net at
random. You just do not know.
>>Now, FAQ is just great, but FAQ is not a reference.

The bibliography for the FAQ mentions a number of good books as I said.

Which aren't read, if you didn't get it.
I was suggesting that he *should* read the bibliography and get some of
those books and read them. If someone fails to follow advice that is not
a fault in the advice!
> Standard
is the best, but somehow I think that if one can read the standard
he simply won't consult man pages (except to check if implementation
agrees with the standard). If man pages suck, it's unfortunate.
Perhaps it'd be better to specify, read GNU or FreeBSD or (insert
something) man pages.
The best would be to shut down sites like that. If it's not
possible, then it's better if it contains stuff copied from better
sources than some made-up-cause-it-seems-so junk.

I don't disagree with that, but unless you know what system someone
has access to then just recommending the man-pages is not quite a safe
option.

I do claim man pages OP has access to (if any) are better than his
writing. I am not saying "could not be worse", I am saying "they are".
You can speculate what you want about possibilities, it won't change
a thing.
I thought you were referring to the sorts of documentation the OP should
read. I agree that his site is far worse than useless.
>Had you recommended a web site with man-pages (which do exist) that
you had checked were of decent quality, or had you known he was using
a system with decent man-pages it would be different.

It would be different. If I were a real C specialist and corrected
everything, it'd be even more different.
But, to my best knowledge, my above statement is right. Could be wrong,
indeed, perhaps. But you better present an example of man pages set
(OP could have access to as you say) which are worse than the
cookbook thing.

I am not sure what we are arguing about though. Did my advices
constitute a nice set of nice advices for folks writing docs?
Absolutely no. Did I recommend better stuff than the present content
of OP's site? Oh yes.
I think in this sub-thread we have been arguing at cross purposes. So to
summarise some of the points:

1) I think we both agree that the OPs site currently has negative value
2) We both agree that there are good man pages on some systems.
3) I think that rather than saying "read the man pages" one should
either recommend a good book or a site one *knows* is good (man pages
are in general not designed to teach).
--
Flash Gordon
Feb 25 '07 #117
Flash Gordon wrote:
Yevgen Muntyan wrote, On 25/02/07 07:57:
>Flash Gordon wrote:
>>Yevgen Muntyan wrote, On 25/02/07 03:31:
[snip]
>Which shows you did *not* see it. It is in microsoft C libs, signature
is different. Now, you're saying "if you tell them...". Do you mean
one must inspect all implementations out there (or maybe only Microsoft
one?) and then post information about their conformance wherever one
posts very name of a single function? It would be good but
not realistic. The original advice "don't even try" *for the OP* holds,
I think.

No, I meant if you tell your *readers* that function X is C99 only and
your *reader* finds that is is not available in MS VC++, or whatever
other implementation, then your *reader* can judge on that basis whether
the company in question sucks.
swprintf *is* available in MS libs. It's not compatible with C standard.
I somehow missed the importance of this fact (was satisified with "MS
sucks"). So now I completely agree with "stick to C89". There is a
question though: what C99 stuff is safe to use (safe meaning
either works fine or doesn't compile)?

Yevgen
Feb 25 '07 #118
Yevgen Muntyan wrote, On 25/02/07 09:59:
Flash Gordon wrote:
>Yevgen Muntyan wrote, On 25/02/07 07:57:
>>Flash Gordon wrote:
Yevgen Muntyan wrote, On 25/02/07 03:31:
[snip]
>>Which shows you did *not* see it. It is in microsoft C libs, signature
is different. Now, you're saying "if you tell them...". Do you mean
one must inspect all implementations out there (or maybe only Microsoft
one?) and then post information about their conformance wherever one
posts very name of a single function? It would be good but
not realistic. The original advice "don't even try" *for the OP* holds,
I think.

No, I meant if you tell your *readers* that function X is C99 only and
your *reader* finds that is is not available in MS VC++, or whatever
other implementation, then your *reader* can judge on that basis
whether the company in question sucks.

swprintf *is* available in MS libs. It's not compatible with C standard.
You find the same problem with the MS implementation of snprintf,
although they generally call it _snprintf. I was not aware they had some
where they used the standard name.
I somehow missed the importance of this fact (was satisified with "MS
sucks"). So now I completely agree with "stick to C89". There is a
question though: what C99 stuff is safe to use (safe meaning
either works fine or doesn't compile)?
Only the common subset of C99 and C89 unfortunately. Well, that is a
slight exaggeration, intermixing declarations and statements is likely
to either work or not compile, although I would not guarantee there were
no edge cases using goto an initialisers which would behave incorrectly
in a C89+extensions compiler. The gcc team provide documentation on the
status of their C99 support (although library issues are outside their
control) MS does not because it is not attempting to provide any C99
conformance.
--
Flash Gordon
Feb 25 '07 #119
robert maas, see http://tinyurl.com/uh3t wrote:
>From: Chris Dollin <chris.dol...@hp.com>
>Actually no. The idea was that an lvalue was the /value/ that was
obtained by evaluating an expression which was to be assigned to,
No wonder everyone is confused.
/I'm/ not confused. Not about this.

You can't assign to a value.
There are only values, so if assignment assigns to something,
it must be a value.
Now if you want
to make the claim that an lvalue in c is really a pointer,
I don't. (But is has some of the same behaviours.)
I'd be
willing to listen to your argument. But I'm not going to just
assume you mean that unless you say so and give some reasoable
argument that it covers all cases.
This is not the time nor the place for a tutorial on the
fundamental concepts of programming languages. So I won't
give one. Do your own homework.
>The /evaluation/ of the expression `x` will yield an lvalue,
which we can usefully think of as "the address of x".

I have no idea what "evaluation" means in c.
Not my problem.
In Lisp it means
passing a data-structure to the function EVAL and getting back the
'evaluation' of that expression. There's nothing like that in c,
and in Lisp you certainly don't get back the address of the
expression or anything equivalent or even close.
Not all languages are Lisp. Not all languages need the concept
of lvalue. Most people don't find these facts to be a problem.
In fact what you said makes no sense.
I think you misread it.
The address of the expression
.... is nothing to do with it. It's a red herring.
So let's back off a bit. This so-called 'evaluation' which you
claims happens in c
It's not /my/ claim. It's not "so-called" evaluation, either.
Can we dispense with the verbal smearing?
, happens when/where? In the compiler during
compilation? Or at runtime?? Or some other time?
It doesn't matter when, so long as the right [defined by specification]
answer is arrived at.
>I admire your ability to produce a cogent and informed argument.

I worry about your ability to juggle junk jargon.
Don't worry. It's bad for one.
>Expressions that "denote a place" are those that can be evaluated
for their lvalues. Those that don't, can't.

What does "evaluated" mean in the context of c?
See the C standard for details.
An 'lvalue' is *not* any kind of value, right?
Wrong.
You can't pass an lvalue as an actual argument to a function,
nor return a lvalue as the result from a function,
nor read an lvalue from an input file,
nor write a lvalue to an output file,
nor store an lvalue somewhere,
nor define a struct to have an lvalue as one of its component slots,
nor define an array of lvalues,
right?
Correct.
>Consider something like
fun f( x ) = ... x := x + 1 ...
... f( 1 ) ...
in a language with pass-by-binding (the formal argument is
bound to the (l)value of the actual argument). The body of
`f` can dink around with `x`, even if the actual argument
is a literal, and without affecting /all/ the places where
the value of `1` is required.

That sounds to me more like the dreaded "undefined behaviour".
It isn't. UB allows /any/ implementation.
For example, suppose in some implemetation of that hypothetical
programming language, all literals are pooled. So wherever the
literal value 1 occurs in a program, that piece of code always
references that single memory-location where that 1 is located in
the pool.
That would be an incorrect implementation of pass-by-binding
as described.
You mean you'd actually be willing to write applications in a
programming language
My willingness to write code in a language I'm describing is
not at issue, nor do I see why it should be; descriptive
techniques should be capable of handling languages I dislike
as well as ones I like.
Since the function
might keep a copy of the pointer, and store that pointer other
places, you can never release that memory, because you have no way
to know if somebody else is still referencing that allocated copy
of the literal. Talk about memory leak!!!
Garbage. Collection. Which I /know/ you know about.
(Don't you ever complain
that Lisp is slow or wastes memory after what you've just
advocated!!)
I /advocated/ nothing. You're fabulating.
The PDP-10 had something like this called a "byte pointer",
Yes, I know. I've known about the PDP-10 and its byte pointers
for years.
On virtually any other machine class, you'd need a struct to
represent an lvalue as a single unit of information.
You're confusing semantics with implementation.
Also, I don't understand what that parameter 'store' is in your
call to the update function/macro.
It's the store, the place where values live:

update( store, lvalue, rvalue )

delivers a new store which is the same as `store` except the
value at `lvalue` is now `rvalue`. Perfectly straightforward
denotational semantics. There are books.
Common Lisp clarifies the whole idea best with SETF.

But that's not the point I was making.
(snip some interestingly exotic/bizarre inventions of metaphors
for lvalues. lvalues are identifiers for places to put things,
as I think has been obvious since I opened my mouth on this
subject.)
(I'm using c notation here to make it easier for you to understand):
Why do you think using C will do that? It's not as though I'm
unfamiliar with Lisp, after all.

Oh. Since most people here aren't familiar with lisp
I don't know how you'd know that.
(after all,
why would anybody use c, except for writing operating systems such
as Linux), after they have seen the light of how much better lisp
is), and since you seem to dismiss all lisp jargon,
I haven't dismissed /any/ Lisp jargon.
>You can do something very similar using Pop11's updaters. They
don't use macros to do it: they use functions plus one assignment
rewrite rule.

"assignment rewrite rule" sounds to me like another way of saying
"setf method". How are they in any way different conceptually?
There's only one rewrite rule, not one per "setf method".
You somehow tell the compiler what code to actually generate with
it sees function(args) on left side of assigment,
[Actually the right-hand-side, since Pop11's assignments run
left-to-right.]
by some kind of rewriting it to call a different function that
Yes: by calling that function's updater. The expression

V -F(X) is compiled as (F.updater)(V, X)

[well, really, ->F(X) is compiled as (F.updater)(X), but we'll
leave aside the open stack for now.]
How is "rewrite" any different from "macro" in general anyway??
The rewrite is built in to the compiler. I would say "not user
redefinable", but Pop11's pretty open; given enough effort you
can pretty much redefine whatever you like. More to the point,
you don't change any rewrite rules and you don't create any
macros when you define Pop11's updaters.

And I'm done.

--
Chris "electric hedgehog" Dollin
"Never ask that question!" Ambassador Kosh, /Babylon 5/

Feb 26 '07 #120
Chris Dollin <ch**********@hp.comwrote:
robert maas, see http://tinyurl.com/uh3t wrote:
From: Chris Dollin <chris.dol...@hp.com>
Actually no. The idea was that an lvalue was the /value/ that was
obtained by evaluating an expression which was to be assigned to,
No wonder everyone is confused.
/I'm/ not confused. Not about this.
You can't assign to a value.

There are only values,
C&V, please.

Richard
Feb 26 '07 #121
Richard Bos wrote:
Chris Dollin <ch**********@hp.comwrote:
>robert maas, see http://tinyurl.com/uh3t wrote:
>From: Chris Dollin <chris.dol...@hp.com>
Actually no. The idea was that an lvalue was the /value/ that was
obtained by evaluating an expression which was to be assigned to,
No wonder everyone is confused.
/I'm/ not confused. Not about this.

You can't assign to a value.

There are only values,

C&V, please.
I'm not talking about C. That's why I ended "And I'm done.".

[And the lvalue stuff fed into what became denotational semantics,
in which the meaning of constructs is given by equations over values;
hence "there are only values".]

--
Chris "electric hedgehog" Dollin
"I just wonder when we're going to have to sit down and re-evaluate
our decision-making paradigm." /Sahara/

Feb 26 '07 #122
From: Keith Thompson <k...@mib.org>
Does the C99 standard say anywhere whether a value is or is not
assigned in case of overflow? That is, does it say either of these:
- In case of overflow, assignment must be suppressed.
- In case of overflow, a truncated value must be assigned.
If it says neither (modulo wording of course, anything close would
suffice to define which behaviour is required), then I agree with:
Unfortunately, sscanf() with "%d" invokes undefined behavior if the
number can't be represented as an int (i.e., on overflow).
As I already told you, it invokes undefined behavior. That means
the standard imposes no requirements.
Clearly this makes it totally useless for validating input.
I'll stick with my use of strscn etc. for semi-manual validation of input.
I suggest you get your own copy of
http://www.open-std.org/jtc1/sc22/wg...docs/n1124.pdf
so you can look these things up yourself rather than depending on the
rest of us to do it for you.
I'd be glad to do that if and when you please tell me how to view
such a file in a meaningful way over a VT100 terminal emulator.
In case of further questions as to my situation here, please study:
<http://www.rawbw.com/~rem/NewPub/mySituation.html>
There will be a test on that material the next time you post here.
Mar 10 '07 #123
re*****@yahoo.com (robert maas, see http://tinyurl.com/uh3t) writes:
>From: Keith Thompson <k...@mib.org>
Does the C99 standard say anywhere whether a value is or is not
assigned in case of overflow? That is, does it say either of these:
- In case of overflow, assignment must be suppressed.
- In case of overflow, a truncated value must be assigned.
If it says neither (modulo wording of course, anything close would
suffice to define which behaviour is required), then I agree with:
Unfortunately, sscanf() with "%d" invokes undefined behavior if the
number can't be represented as an int (i.e., on overflow).
As I already told you, it invokes undefined behavior. That means
the standard imposes no requirements.
These attributions are messed up. I wrote the block of text starting
with "Unfortunately, sscanf()," and the one starting with "As I
already told you". I don't remember who wrote the other stuff.

I think the problem is that you seem to be writing your own
attribution lines. You write, for example:

From: So-and-So <fo*@bar.com>
Text that So-and-So wrote ...

The standard form for attribution lines and quoted text is:

So-and-So <fo*@bar.comwrites:
Text that So-and-So wrote ...
Any decent newsreader will do this for you automatically.
Clearly this makes it totally useless for validating input.
I'll stick with my use of strscn etc. for semi-manual validation of input.
I think you're right. You *might* be able to do the job with sscanf()
if you can find out how your implementation handles overflow *and* if
you don't care too much about portability. It's not something I'd
recommend.

There may also be open-source implementations of sscanf() that behave
sensibly on overflow. If you can grab one of them, and if it's
implemented in portable C, you can rename it and use it in your own
code.
>I suggest you get your own copy of
http://www.open-std.org/jtc1/sc22/wg...docs/n1124.pdf
so you can look these things up yourself rather than depending on the
rest of us to do it for you.

I'd be glad to do that if and when you please tell me how to view
such a file in a meaningful way over a VT100 terminal emulator.
In case of further questions as to my situation here, please study:
<http://www.rawbw.com/~rem/NewPub/mySituation.html>
There will be a test on that material the next time you post here.
Sorry, I don't think I'll bother reading that, and I'm not going to
take your test. However much I might sympathize with your situation,
this really isn't the place to discuss it.

I'm posting this through a VT100 terminal emulator, but I'm able to
download and view PDF files on the computer where I'm running the
emulator. You may or may not be able to do something similar.

But perhaps you should try reading this:
<http://groups.google.com/group/comp.lang.c/msg/268fb3f0e9caa789>
It's an article I posted here two weeks ago, and it was a direct
followup to something you posted. In it, I wrote:
| Are you unable to read PDF files? I understand you're using an old
| and limited computer system, but there are cost-free PDF viewers that
| should work for you.
|
| If you can't deal with PDF, search for "n869.txt"; it's a committee
| draft dated Jan 18, 1999. There are a few significant differences
| between n869 and the actual C99 standard.

At least one of the regulars here uses n869.txt as his primary
reference.

Also, Adobe Reader is able to export a PDF file as plain text, and
I've just created an ASCII copy of n1124.pdf (n1124.txt). If you're
interested, let me know so we can figure out how to get it to you.
It's about a megabyte of text, or about 25% of that if I compress it.
The formatting isn't as nice as n869.txt; it's up to you to decide
which one you want to use.

I've dropped alt.support.shyness from the Newsgroups line.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mar 10 '07 #124
"robert maas, see http://tinyurl.com/uh3t" wrote:
>From: Keith Thompson <k...@mib.org>
.... snip ...
>
>I suggest you get your own copy of
http://www.open-std.org/jtc1/sc22/wg...docs/n1124.pdf
so you can look these things up yourself rather than depending on the
rest of us to do it for you.

I'd be glad to do that if and when you please tell me how to view
such a file in a meaningful way over a VT100 terminal emulator.
.... snip ...

You can get a bz2 compressed version of N869.TXT from:

<http://cbfalconer.home.att.net/download/>

FX-Mozilla-Status: 0009
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
--
Posted via a free Usenet account from http://www.teranews.com

Mar 11 '07 #125
CBFalconer wrote:
"robert maas, see http://tinyurl.com/uh3t" wrote:
>>From: Keith Thompson <k...@mib.org>
.... snip ...
>>I suggest you get your own copy of
http://www.open-std.org/jtc1/sc22/wg...docs/n1124.pdf
so you can look these things up yourself rather than depending on the
rest of us to do it for you.
I'd be glad to do that if and when you please tell me how to view
such a file in a meaningful way over a VT100 terminal emulator.
.... snip ...

You can get a bz2 compressed version of N869.TXT from:

<http://cbfalconer.home.att.net/download/>

FX-Mozilla-Status: 0009
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
There's also a program called pdftotext that I used once to
convert n1124.pdf to txt. If one doesn't mind some strange
characters that remain in the txt file after the conversion then
it does a pretty good job.

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Mar 11 '07 #126
Keith Thompson wrote:
>
.... snip ...
>
I've dropped alt.support.shyness from the Newsgroups line.
I had to do likewise, since the news server doesn't recognize that
group and rejects the whole post. This just illustrates the
foolishness of untrammelled cross-posting.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

--
Posted via a free Usenet account from http://www.teranews.com

Mar 11 '07 #127
From: Mark McIntyre <markmcint...@spamcop.net>
This is comp.lang.c, where we discuss the C programming language,
which is defined by the ISO C standard, which has a perfectly
good technical definition for the word "object".
Is it anything like last year's new technical definition of "planet"
by the IAU (International Astronom... Union)? :-(
It defines it as "a region of data storage... the contents of which
can represent values". This seems an entirely reasonable definition to
me. As someone has already said, the word has a wide variety of exact
meanings in many walks of life, so being precise is /not/
inappropriate.
Let me check if I understand you correctly: You're saying that it's
perfectly good, even desireable, to use a word (in a supposed
technical definition of a programming language) which in ordinary
usage has a "wide variety of exact meanings in many walks of life",
and to utterly fail to specify **which** of those wide variety of
meanings is intended, thereby leaving that part of the
specification [cough, cough] grossly ambiguous?

My opinion on this matter is the exact opposite of that. That
whenever a word in ordinary usage has a wide variety of different
meanings, then such a word should *not* be used in any technical
specification without first defining which of the various meanings
is intended.

For example, do you see any introductory mathematical text on
"group theory" starting off by saying "a group is whatever you
thought it meant when you were in sensitivity training or whereever
your vibes are" and then trying to derive any useful mathematical
conseuence from such a starting point?

If a "region" can mean something like the Western USA, or the Great
Plains of the USA, which partly overlap with the former, or the
Mississippi River drainage area, which greatly overlaps with the
great plains, or the midwest, which overlaps with the drainage
area, or the "south" which overlaps with both the great plains and
the drainage area, or the East Coast which overlaps with the
"south", or New England which is a part of the East Coast, or the
USA which includes disconnected states Alaska and Hawaii plus
various disconnected islands such as Catalina, or the British
Empire at its hight which included disconnected parts all around
the Globe, then how can that be of any value in pinning down
whether some random set of memory cells in a C core image, not
necessarily contiguous, not necessarily having any bearing on any
formal C constructs such as arrays or structs, is or is not a
"region" for the purpose of the specification [cough cough] of
"lvalue"? Is an "lvalue" just any random subset of physical or
virtual memory?? The spec, as you interepret it, seems to be like
that, totally useless.
OK, then given your instance, I'd be glad to try very hard to
always qualify my use of the word "object" with one of:
- In the original lisp sense, any distinctly allocated block of
memory with a single handle on it, which would include c structs
allocated with malloc or calloc.
This is pretty close to the C definition,
What the fuck C definition are you talking about? It's not in the
formal spec we've been discussing here.
if you think it through.
Please explain what thinking can convert what you've been saying
about "lvalue" (refers to any "region" which can be "anything that
might be called a 'region' in ordinary informal
usage outside the field of programming languages")
into anything even remotely similar to the original lisp sense I
cited.
I don't think Lisp required the block of memory to be complex.
I agree, but that's not relevant. The point is that the memory
associated with an object has a single toplevel "handle" by which a
user-level program can gain access to exactly that memory occupied
by that object and nothing else.
(At the machine level, and in MacLisp, it's possible to convert a
handle into a number representing the machine address of the entry
point of that object, then perform arithmetic to get any other
random numeric value, then convert that number back into a "handle"
onto some random new starting point where a user-level program may
or may not find something resembling a consistent object. That's
not what counts for user-level program getting access via the handle.)

Now in C you are allowed to do exactly that sort of machine-level
manipulation of pointers, and thereby gain access to places in
memory that really aren't properly accessible via formal definition
of the pointer as pointing to an *object*. But if you write code
that performs such hackery, it won't necessarily produce consistent
results on different implementations, or even at different times
within the same implementation.

Now if the C standard were to state clearly what constitutes
"reasonably accessible" per staying within a single allocation unit
(simple variable, array, struct, malloc-block, etc.) plus any
additional allocation units you can get by following pointers from
your starting unit, and define both objects and lvalues
consistently with respect to that understanding, and thus
guaranteeing (as much as possible) that programs restricted to such
access would be portable, I would like that. But the "new and
wonderful" ANSI/ISO C standard we've been discussing doesn't do
that, so I rate it as crap in this respect.
The standard itself doesn't define region. You would have to check
back in ISO/IEC 2832-1:1993 "Information Technology - Vocabulary
Part1: Fundamental Terms" to see what ISO defined it as.
Your browser may not have a PDF reader available. Google recommends
visiting our text version of this document.
Clicking on the link "text version" doesn't work. It just takes me
to another listing of search results. Google appears to be broken today.

I looked through the first two groups of search results, but the
only plain-text documents I could find were FAA regulations and
fisheries, so obviously Google is giving me partial matches which
are totally unrelated to what I asked for.

If you know where there's a text version available please post the URL.
if a particular compiler optimizes space by moving the long int
array ahead of either of the short int arrays to reduce amount of
padding needed to respect long boundaries, so that
a[7] a[8] c[0] c[1] c[2]
form a contiguous block of memory, is that considered a "region"
hence an "object"??
There's nothing which requires these to be contiguous, so I can't
see how they can be considered either an object or a single region.
The San Francisco Bay Area is considered a region, despite that
fact that the parts West of the San Andreas Fault are slowly moving
north-west relative to the rest of the Bay Area. There's nothing
requring the SF Bay Area to be contiguous, even though at the
moment it's contiguous, more or less anyway. So your appeal to
ordinary common usage outside the field of programming languages,
whereby a bunch of land that is merely temporarily and incidentally
contiguous, neither permanently nor required to be contiguous,
contradicts your claim that my example above wouldn't count as a
"region" hence an "object" per the shoddy ANSI/ISO spec [cough
cough].
I suspect that ISO hasn't defined the meaning of "region" any more
than the IAU defined the meaning of "clearing the neighborhood".
FWIW, the IAU had no need to define that since it can be inferred from
an amazing property known as "common sense".
Common Sense says that Neptune hasn't cleared its neighborhood of
Pluto, and the Earth hasn't cleared its neighborhood of Luna, and
Jupiter hasn't cleared its neighborhood of Io or Europa or Ganymede
or Calisto. So none of those is a planet per IAU's 2006 definition???
Mar 18 '07 #128
Robert Maas, see http://tinyurl.com/uh3t said:
If a "region" can mean something like the Western USA, or the Great
Plains of the USA, which partly overlap with the former, or the
Mississippi River drainage area, which greatly overlaps with the
great plains, or the midwest, which overlaps with the drainage
area, or the "south" which overlaps with both the great plains and
the drainage area, or the East Coast which overlaps with the
"south", or New England which is a part of the East Coast, or the
USA which includes disconnected states Alaska and Hawaii plus
various disconnected islands such as Catalina, or the British
Empire at its hight which included disconnected parts all around
the Globe,
How many of these, are regions of data storage, the contents of which
can represent values? If any of them are, then they are objects as far
as the C Standard is concerned. (And I don't have a problem with that.)

<snip>
(At the machine level, and in MacLisp, it's possible to convert a
handle into a number representing the machine address of the entry
point of that object, then perform arithmetic to get any other
random numeric value, then convert that number back into a "handle"
onto some random new starting point where a user-level program may
or may not find something resembling a consistent object. That's
not what counts for user-level program getting access via the
handle.)

Now in C you are allowed to do exactly that sort of machine-level
manipulation of pointers,
No, you're not. You can do the first bit - converting a pointer value
into an integer - but the result of doing so is implementation-defined
and need not be meaningful in terms of object locations. But the rest?
No, as soon as you do that, you're firmly in Undefined Behaviour
territory. Yes, sure, on some machines you can get away with it. On
others, however, you can't. C doesn't offer any guarantees in that
regard.
Now if the C standard were to state clearly what constitutes
"reasonably accessible" per staying within a single allocation unit
(simple variable, array, struct, malloc-block, etc.) plus any
additional allocation units you can get by following pointers from
your starting unit, and define both objects and lvalues
consistently with respect to that understanding, and thus
guaranteeing (as much as possible) that programs restricted to such
access would be portable, I would like that.
Then you'll like the C Standard, because it does state this very
clearly, provided you know what you're talking about...
But the "new and
wonderful" ANSI/ISO C standard we've been discussing doesn't do
that, so I rate it as crap in this respect.
....and, from the above statement, I deduce that you don't.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 18 '07 #129
From: Keith Thompson <k...@mib.org>
And what exactly do you mean by "ANSI"?
Whatever is the **current** (latest official) standard.
At the moment, that seems to be C99.

Or whatever the GNU C compiler uses when the -ansi switch is turned
on. From the man pages here:
-ansi Support all ANSI standard C programs.
This turns off certain features of GNU C that are incompatible
with ANSI C, such as the asm, inline and typeof keywords, and
predefined macros such as unix and vax that identify the type of
system you are using. It also enables the undesirable and
rarely used ANSI trigraph feature, and disallows `$' as part of
identifiers.
-pedantic
Issue all the warnings demanded by strict ANSI standard C; re-
ject all programs that use forbidden extensions.
Valid ANSI standard C programs should compile properly with or
without this option (though a rare few will require `-ansi').
However, without this option, certain GNU extensions and tradi-
tional C features are supported as well. With this option, they
are rejected. There is no reason to use this option; it exists
only to satisfy pedants.
Please tell me whether GNU C MAN pages are referring to C99 or what?

Can you forgive me for reading the GNU C MAN pages and thinking the
jargon used in them was in any way acceptable here in the
newsgroup? (Especially after somebody here suggested that I use
both the -ansi and -pedantic switches, and somebody here suggested
I read the man pages?) I suspect you-all here have deliberately
baited me into looking at those man pages and using the jargon
therein, just so you could the slap me down for using it.
The current official C standard, C99, was issued by ISO (and
later adopted by ANSI).
So it would seem reasonable, in articles posted any time from about
2000 to the present and for a while in the fiture, to call it "ANSI
C", no??
The previous standard, which is still in wide use, is C90, also
issued by ISO (and adopted by ANSI).
I would consider that "old ANSI C", specifically "previous ANSI C".
I suggest avoiding the use of "ANSI" as an adjective; many people
still use "ANSI C" to refer to the language defined by the ANSI
C89 and ISO C90 standard documents, but strictly speaking that
usage is incorrect.
So you're forbidding me to use perfectly correct jargon, just
because some other people use the same jargon in an incorrect way?
So I'm not allowed to refer to this newsgroup as "comp.lang.c"
because some other people call it by some incorrect name instead?
I'm not allowed to refer to this country where California is
located as "The United States of America", because somebody else
uses the same term for something entirely different?
If you instead refer to "C90" or "C99", you avoid the ambiguity.
What about C89 as an alternate designation for C90?
(ISO standardized it in 1989, but ANSI didn't join in approving it
until 1990, right. So from ISO's point of view, it's really C89?)

What term should I use to refer to the part of C that hasn't
changed from C89/C90 to C99, such as that if M and N are short
integers then M+N is an expression, of type short integer, that
results from adding M and N while discarding overflow (thus
wraparound)? For the most part, it's *that* language, the common
subset of C89/C90 and C99, that I want to describe in my
Cookbook/Matrix WebTree.
On the web page, I saw, there were two functions marked "GNU-c",
both of them incorrectly. Both functions are defined by C99, but
not by C90.
Ah, that was because those functions were in both the original K&R
and also in C89/C90, and prior to 1999 were also in GNU C as a
nonstandard add-on, and I wasn't aware that C99 existed at the time
I wrote that. How do those paragraphs in my Matrix look now? Should
I perhaps flag them as C99, to warn users of older C systems?

As a more general question, which paragraphs of my Matrix document
currently define something that is in C99 but not C89/C90, such
that a warning about that would be appropriate?
<OT>
The phrase "the GNU C version of the stdlib library" doesn't make much
sense, unless you're referring to glibc. I use gcc on Linux, where
the C runtime library is glibc. I also use gcc on Solaris, where the
C runtime library is the one provided by Solaris. gcc is a compiler,
not a complete implementation.
</OT>
How is that off-topic for comp.lang.c or for discussion of errata
in my Cookbook/Matrix WebTree?

In any case, when I issue a gcc command on FreeBSD Unix, or on
RedHat Linux, in either case the gnu compiler goes ahead and links
in various library modules based on headers that I've specfied. I
have *not* specfied which version of the library is to be used,
such as specifing the directory-path in quotes. Rather I've
specified the generic header name in pointy-brockets. Somehow gcc
picks one particular library to load form, without me having to
tell it. Apparently gcc is pre-configured (by whoever originally
installed it on that machine) to automatically use one particular
library, whether it's glibc or something else. From the point of
view of the application programmer, the compiler and whatever
loader the compiler selects and whatever libraries the compiler
selects are all part of the compiler system which is used
transparently to compile source files and build executables.

What jargon would *you* use to include the compiler and the loader
and the libraries together as a transparent unit??
I had the impression they were not in original c but are in GNU c,
so that was the distinction I was making. But if they're in C99 as
you claim, then I'd rather change that to show they're in C99
(instead of GNU c) but not in original c.
Be careful with the term "original c" (or, preferably, "original C").
Versions of C existed long before the first ANSI standard.
I thought it was clear already: "original c" means K&R.
Yes, that was long before any ISO or ANSI standard C.
Nobody disputes that fact. (Well, except for somebody like |-|erc.)
n1124.pdf, referenced above, is the C99 standard with two
Technical Corrigenda merged into it. Any post-C99 chanages are
marked with change bars.
I have no way to view that here:
<http://www.rawbw.com/~rem/NewPub/mySituation.html>
I don't suppose you know of a plain-text or HTML version?
Why is it that the Common Lisp folks (well one of them, KMP,
anyway) have produced a nice HTML version of the ANSI standard:
<http://www.lispworks.com/documentation/HyperSpec/Front/>
and Sun Microsystems has produced equally good HTML documentation
for all their API, which is the default standard for Java, but the
idiots who have access to the ANSI standard (1999) C haven't
figured out how to do a similar thing for it? Is it really that
hard for somebody with PDF access to copy the text from the ANSI
C99 standard into a Web framework?
Mar 18 '07 #130
Robert Maas, see http://tinyurl.com/uh3t wrote:
>The current official C standard, C99, was issued by ISO (and
later adopted by ANSI).

So it would seem reasonable, in articles posted any time from about
2000 to the present and for a while in the fiture, to call it "ANSI
C", no??
ANSI is an American standard (not that there is anything wrong with
that :-)) but since this is an international newsgroup, the
international ISO standard should probably take precedence.
>The previous standard, which is still in wide use, is C90, also
issued by ISO (and adopted by ANSI).

I would consider that "old ANSI C", specifically "previous ANSI C".
How about "ISO C90 standard"?

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"So if you were to say 'Microsoft,' I'd say 'Where? Let me grab
me my stake and crucifix!'." -- Bridget Kulakauskas
Mar 18 '07 #131
"Robert Maas, see http://tinyurl.com/uh3t" wrote:
>
.... snip ...
>
>n1124.pdf, referenced above, is the C99 standard with two
Technical Corrigenda merged into it. Any post-C99 chanages are
marked with change bars.

I have no way to view that here:
<http://www.rawbw.com/~rem/NewPub/mySituation.html>
I don't suppose you know of a plain-text or HTML version?
Of course you conveniently ignore that I gave you a URL for a
suitable text version over a week ago.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Mar 18 '07 #132
Robert Maas, see http://tinyurl.com/uh3t wrote, On 18/03/07 06:52:
>From: Keith Thompson <k...@mib.org>
And what exactly do you mean by "ANSI"?

Whatever is the **current** (latest official) standard.
At the moment, that seems to be C99.
Was making that clear really so difficult?
Or whatever the GNU C compiler uses when the -ansi switch is turned
on. From the man pages here:
<snip>
Please tell me whether GNU C MAN pages are referring to C99 or what?
If you read the rest of the GCC documentation you will find one of two
things:
1) It tells you that it is referring to C89
2) It is a version pre-dating C99 which would therefore obviously not be
referring to C99.

Try reading enough of the documentation to know how to use the tools you
are using, i.e. most of it.
Can you forgive me for reading the GNU C MAN pages and thinking the
jargon used in them was in any way acceptable here in the
newsgroup? (Especially after somebody here suggested that I use
both the -ansi and -pedantic switches, and somebody here suggested
I read the man pages?) I suspect you-all here have deliberately
baited me into looking at those man pages and using the jargon
therein, just so you could the slap me down for using it.
If you keep suggesting people are out to get you then it is quite likely
to become self fulfilling.

The suggestion to read the documentation for GCC was simply so that you
know how to use the tools you are using. Nothing more and nothing less.
Do you think it is a bad idea to know the tools you are using?
>The current official C standard, C99, was issued by ISO (and
later adopted by ANSI).

So it would seem reasonable, in articles posted any time from about
2000 to the present and for a while in the fiture, to call it "ANSI
C", no??
It is reasonable to allow for historic usage and be clear when it matters.
>The previous standard, which is still in wide use, is C90, also
issued by ISO (and adopted by ANSI).

I would consider that "old ANSI C", specifically "previous ANSI C".
It is also old ISO C.
>I suggest avoiding the use of "ANSI" as an adjective; many people
^^^^^^^^^
>still use "ANSI C" to refer to the language defined by the ANSI
C89 and ISO C90 standard documents, but strictly speaking that
usage is incorrect.

So you're forbidding me to use perfectly correct jargon, just
because some other people use the same jargon in an incorrect way?
Since when does the word "suggest" mean forbid?

<snip rantings>
>If you instead refer to "C90" or "C99", you avoid the ambiguity.

What about C89 as an alternate designation for C90?
Accept when referring to specific section numbers, yes.
(ISO standardized it in 1989, but ANSI didn't join in approving it
until 1990, right. So from ISO's point of view, it's really C89?)
Wrong, and I'm sure that Keith would not have made that mistake.
What term should I use to refer to the part of C that hasn't
changed from C89/C90 to C99, such as that if M and N are short
integers then M+N is an expression, of type short integer, that
results from adding M and N while discarding overflow (thus
wraparound)? For the most part, it's *that* language, the common
subset of C89/C90 and C99, that I want to describe in my
Cookbook/Matrix WebTree.
Where it does not matter which standard using the terms ANSI C or by
preference in an international setting ISO C is not unreasonable. Where
it matters that it is the common subset, which *does* matter when
writing reference documentation (and sometimes matters here) you should
be specific about it.u

<snip>
In any case, when I issue a gcc command on FreeBSD Unix, or on
RedHat Linux, in either case the gnu compiler goes ahead and links
in various library modules based on headers that I've specfied. I
<snip more ranting>

Stop talking complete and utter rubbish. It has been pointed out to your
more than once already that the headers do NOT control what happens when
you link. I have NEVER come across a compiler where including a header
causes the relevant library to be linked in.
>n1124.pdf, referenced above, is the C99 standard with two
Technical Corrigenda merged into it. Any post-C99 chanages are
marked with change bars.

I have no way to view that here:
<http://www.rawbw.com/~rem/NewPub/mySituation.html>
Your situation is your problem.
I don't suppose you know of a plain-text or HTML version?
<snip ranting>

Such things have been posted here during the time you have been here.
--
Flash Gordon
Mar 18 '07 #133
Robert Maas, see http://tinyurl.com/uh3t wrote:
What term should I use to refer to the part of C that hasn't
changed from C89/C90 to C99, such as that if M and N are short
integers then M+N is an expression, of type short integer, that
results from adding M and N while discarding overflow (thus
wraparound)?
The term you should use is:
"I make so many mistakes that they almost cancel each other out"

If M and N are short integers,
then M+N is an expression of type int and not of type short.

If (M+N) overflows, then the result is undefined.

ISO/IEC 9899:1999 (E)
6.3.1 Arithmetic operands
6.3.1.1 Boolean, characters, and integers
2 The following may be used in an expression
wherever an int or unsigned int may be used:
— An object or expression with an integer type whose integer
conversion rank is less than the rank of int and unsigned int.
If an int can represent all values of the original type,
the value is converted to an int;
otherwise, it is converted to an unsigned int.
These are called the integer promotions.48)
48) The integer promotions are applied only:
as part of the usual arithmetic conversions,
to certain argument expressions,
to the operands of the unary +, -, and ~ operators,
and to both operands of the shift operators,
as specified by their respective subclauses.
6.3.1.8 Usual arithmetic conversions
1 Many operators that expect operands of arithmetic type
cause conversions and yield result types in a similar way.
The purpose is to determine a common real type for the operands
and result. For the specified operands, each operand is converted,
without change of type domain, to a type whose corresponding
real type is the common real type.
Unless explicitly stated otherwise,
the common real type is also the corresponding real type of
the result, whose type domain is the type domain of the operands if
they are the same, and complex otherwise.
This pattern is called the usual arithmetic conversions:

Otherwise, the integer promotions are performed on both operands.

6.5.6 Additive operators
Semantics
4 If both operands have arithmetic type,
the usual arithmetic conversions are performed on them.

3.4.3
1 undefined behavior
behavior, upon use of a nonportable or erroneous program construct
or of erroneous data,
for which this International Standard imposes no requirements
2 NOTE Possible undefined behavior ranges from ignoring the situation
completely with unpredictable results,
to behaving during translation or program execution in a documented
manner characteristic of the environment
(with or without the issuance of a diagnostic message),
to terminating a translation or execution
(with the issuance of a diagnostic message).
3 EXAMPLE An example of undefined behavior is the behavior on integer
overflow.

/* BEGIN new.c */

#include <stdio.h>

int main(void)
{
printf("sizeof ((char)0 + (char)0) is %u.\n",
(unsigned)sizeof ((char)0 + (char)0));
return 0;
}

/* END new.c */
--
pete
Mar 18 '07 #134
pete wrote:
>
Robert Maas, see http://tinyurl.com/uh3t wrote:
What term should I use to refer to the part of C that hasn't
changed from C89/C90 to C99, such as that if M and N are short
integers then M+N is an expression, of type short integer, that
results from adding M and N while discarding overflow (thus
wraparound)?

The term you should use is:
"I make so many mistakes that they almost cancel each other out"

If M and N are short integers,
then M+N is an expression of type int and not of type short.

If (M+N) overflows, then the result is undefined.

ISO/IEC 9899:1999 (E)
I will now provide references from ISO/IEC 9899: 1990

3 Definitions and conventions
Examples
2. An example of undefined behavior
is the behavior on integer overflow.

5.1.2.3 Program execution
2. In executing the fragment
char c1, c2;
/*...*/
c1 = c1 + c2;
the “integral promotions” require that the abstract machine
promote the value of each variable to int size
and then add the two ints and truncate the sum.
Provided the addition of two chars can be done without creating
an overflow exception, the actual execution need only produce
the same result, possibly omitting the promotions.

/* BEGIN new.c */

#include <stdio.h>

int main(void)
{
char c1 = 0;
char c2 = 0;

printf("sizeof(c1 + c2) is %u.\n", (unsigned)sizeof(c1 + c2));
return 0;
}

/* END new.c */
--
pete
Mar 18 '07 #135
On Sat, 17 Mar 2007 22:43:04 -0700, in comp.lang.c , re*****@yahoo.com
(Robert Maas, see http://tinyurl.com/uh3t) wrote:

(I wrote, some weeks ago)
>The standard itself doesn't define region. You would have to check
back in ISO/IEC 2832-1:1993 "Information Technology - Vocabulary
Part1: Fundamental Terms" to see what ISO defined it as.

Your browser may not have a PDF reader available. Google recommends
visiting our text version of this document.
Clicking on the link "text version" doesn't work. It just takes me
to another listing of search results. Google appears to be broken today.
Apparently you wrote this in response to something I wrote. I have no
clue what the above refers to, or why google pointed you at some
random text link.
>If you know where there's a text version available please post the URL.
A text version of ISO/IEC 2832 ? No idea. Buy one from ISO?
>The San Francisco Bay Area is considered a region,
You're pretty much making my point by this bollocks. the Bay Area may
be a postal region or tax region (for all I know) but its not a
geological region, nor yet a weather region.
>FWIW, the IAU had no need to define that since it can be inferred from
an amazing property known as "common sense".

Common Sense says that Neptune hasn't cleared its neighborhood of
Pluto, and the Earth hasn't cleared its neighborhood of Luna, and
Jupiter hasn't cleared its neighborhood of Io or Europa or Ganymede
or Calisto. So none of those is a planet per IAU's 2006 definition???
Apparently you're unfamilar with the meaning of yet another phrase...
:-)
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 19 '07 #136
re*****@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>From: Keith Thompson <k...@mib.org>
And what exactly do you mean by "ANSI"?

Whatever is the **current** (latest official) standard.
At the moment, that seems to be C99.
Ok. You need to be aware, though, that a lot of people use the term
"ANSI C" to refer to the language defined by the 1989 ANSI standard.
Which is why I refer to "C90" or "C99", to avoid the potential
ambiguity.
Or whatever the GNU C compiler uses when the -ansi switch is turned
on. From the man pages here:
[snip]

gcc's "-ansi" option is equivalent to "-std=c90" or
"std=iso9899:1990". (I've suggested that "std=c89" should also be
accepted.) So, as you can see, the term "ANSI C" is ambiguous.
Please tell me whether GNU C MAN pages are referring to C99 or what?
The gcc documentation refers to C89 when it discusses the "-ansi"
option.
Can you forgive me for reading the GNU C MAN pages and thinking the
jargon used in them was in any way acceptable here in the
newsgroup?
Forgive you? Sure, whatever, it's an easy mistake to make.
(Especially after somebody here suggested that I use
both the -ansi and -pedantic switches, and somebody here suggested
I read the man pages?) I suspect you-all here have deliberately
baited me into looking at those man pages and using the jargon
therein, just so you could the slap me down for using it.
Paranoid nonsense. I don't think anybody here cares enough to bait
you like that.
>The current official C standard, C99, was issued by ISO (and
later adopted by ANSI).

So it would seem reasonable, in articles posted any time from about
2000 to the present and for a while in the fiture, to call it "ANSI
C", no??
It would *seem* reasonable, but as I've explained, it does cause
problems.
>The previous standard, which is still in wide use, is C90, also
issued by ISO (and adopted by ANSI).

I would consider that "old ANSI C", specifically "previous ANSI C".
Or you could call it "ANSI C89".
>I suggest avoiding the use of "ANSI" as an adjective; many people
still use "ANSI C" to refer to the language defined by the ANSI
C89 and ISO C90 standard documents, but strictly speaking that
usage is incorrect.

So you're forbidding me to use perfectly correct jargon, just
because some other people use the same jargon in an incorrect way?
Forbidding you? What the hell are you talking about? I am not
"forbidding" you to do anything. I am offering you advice, as you can
tell by my use of the word "suggest" above.

[...]
>If you instead refer to "C90" or "C99", you avoid the ambiguity.

What about C89 as an alternate designation for C90?
(ISO standardized it in 1989, but ANSI didn't join in approving it
until 1990, right. So from ISO's point of view, it's really C89?)
Not quite. ANSI issued a C standard (the first one) in 1989. ISO
adopted it, with some non-substantive changes, in 1990; ANSI then
adopted the 1990 ISO standard as an ANSI standard.

The 1989 ANSI standard and the 1990 ISO standard describe the same
language. You can sensibly refer to that langauge as either C89 or
C90. (Or you can call it Ralph Kramden if you want to; you don't need
my permission.)
What term should I use to refer to the part of C that hasn't
changed from C89/C90 to C99, such as that if M and N are short
integers then M+N is an expression, of type short integer, that
results from adding M and N while discarding overflow (thus
wraparound)? For the most part, it's *that* language, the common
subset of C89/C90 and C99, that I want to describe in my
Cookbook/Matrix WebTree.
I don't know of a name for the common subset (i.e., the intersection)
of C90 and C99.

Incidentally, I'm not sure what the stuff about M and N is supposed to
mean.
>On the web page, I saw, there were two functions marked "GNU-c",
both of them incorrectly. Both functions are defined by C99, but
not by C90.

Ah, that was because those functions were in both the original K&R
and also in C89/C90, and prior to 1999 were also in GNU C as a
nonstandard add-on, and I wasn't aware that C99 existed at the time
I wrote that. How do those paragraphs in my Matrix look now? Should
I perhaps flag them as C99, to warn users of older C systems?
I think you mean that they *weren't* in C89/C90. I don't remember
where your Matrix is.
As a more general question, which paragraphs of my Matrix document
currently define something that is in C99 but not C89/C90, such
that a warning about that would be appropriate?
I'm afraid that would require more of my time than I'm currently
willing to spend on this.
><OT>
The phrase "the GNU C version of the stdlib library" doesn't make much
sense, unless you're referring to glibc. I use gcc on Linux, where
the C runtime library is glibc. I also use gcc on Solaris, where the
C runtime library is the one provided by Solaris. gcc is a compiler,
not a complete implementation.
</OT>

How is that off-topic for comp.lang.c or for discussion of errata
in my Cookbook/Matrix WebTree?
It's off-topic for comp.lang.c because it concerns specific
implementations, not the actual language.

[...]
What jargon would *you* use to include the compiler and the loader
and the libraries together as a transparent unit??
"The implementation".
I had the impression they were not in original c but are in GNU c,
so that was the distinction I was making. But if they're in C99 as
you claim, then I'd rather change that to show they're in C99
(instead of GNU c) but not in original c.
Be careful with the term "original c" (or, preferably, "original C").
Versions of C existed long before the first ANSI standard.

I thought it was clear already: "original c" means K&R.
Yes, that was long before any ISO or ANSI standard C.
Nobody disputes that fact. (Well, except for somebody like |-|erc.)
There were versions of C *before* K&R1. See
<http://cm.bell-labs.com/cm/cs/who/dmr/chist.html>. (Versions of C
prior to K&R1 are now almost entirely of only historical interest.
K&R itself is nearly so; support for at least the C89/C90 standard is
now almost, but not quite, universal.)
>n1124.pdf, referenced above, is the C99 standard with two
Technical Corrigenda merged into it. Any post-C99 chanages are
marked with change bars.

I have no way to view that here:
<http://www.rawbw.com/~rem/NewPub/mySituation.html>
I don't suppose you know of a plain-text or HTML version?
This has already been answered several times. Please pay attention.
Once again:

<http://cbfalconer.home.att.net/download/n869_txt.bz2is a compressed
(with bzip2) plain-text draft. It's from not long before the final
C99 standard; there are a few significant differences, but not many.
(No, I don't have a list.)

n1124.pdf is what I use. Adobe Reader is able to translate it to
plain text. The result isn't as nicely formatted as n869.txt, but it
has the advantage that it includes the full C99 standard plus the two
Technical Corrigenda. I already offered to send you a copy; you'll
need to contact me and let me know how to get it to you (compressed?
if so, how? e-mail? ftp? www?). I reserve the right to withdraw this
offer at some indefinite point in the future.
Why is it that the Common Lisp folks (well one of them, KMP,
anyway) have produced a nice HTML version of the ANSI standard:
<http://www.lispworks.com/documentation/HyperSpec/Front/>
and Sun Microsystems has produced equally good HTML documentation
for all their API, which is the default standard for Java, but the
idiots who have access to the ANSI standard (1999) C haven't
figured out how to do a similar thing for it? Is it really that
hard for somebody with PDF access to copy the text from the ANSI
C99 standard into a Web framework?
Most of us find the PDF version sufficiently useful. Most of those
who prefer something other than PDF probably use n869.txt. If you
don't find either of those usable, alternatives have already been
offered.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mar 19 '07 #137
Keith Thompson wrote:
I would consider that "old ANSI C", specifically "previous ANSI C".

Or you could call it "ANSI C89".
Or "Australian Rules C"!!!

AS 3955—1991
ISO/IEC 9899: 1990
Australian Standard
Programming languages—C

--
pete
Mar 19 '07 #138
From: Yevgen Muntyan <muntyan.removet...@tamu.edu>
Just don't mention GNU-only functions at all.
I'd like to do that, but I don't know of any search engine where I
type in the name of a C library function and get back the status of
that particular function and the various standards (C99, C89/C90,
K&R) and implementations. So occasionally I will read about some
function, try it, find it works, and describe it in my document,
without any to know it isn't standard.
By the way, I hope my readers will look up the complete definition
of the function, using Google for example, any place my quickie
definition isn't quite complete in all details.
Is this how *you* get the documentation? You should consider something
better, like C libraries manuals, man pages, C standard. man pages
are pretty good, they tell you about the standards given function
conforms to.
I'm not aware of any man pages that tell whether a given function
in c is standard and if so which standard. The C libraries manuals
are precisely what I intended the reader to consult after using
Google to find it in the first place. In some cases I have direct
links from my document to individual sections of an online C
library manual, where the chapter/section of the manual closely
matches the way I have the material organized. For example, with
the trigonometric functions I just have a general description of
the typical functions available in most programming languages, with
direct links to Common Lisp and C manual section on that topic.
Don't write documentation about stuff you don't know.
There's no such thing as knowing a subject absolutely and
completely. If everyone waited until they knew *everything* about a
topic before they wrote *any* documentation about that topic, no
documetation would ever get written.
Mar 20 '07 #139
From: Keith Thompson <k...@mib.org>
Overflow in sscanf() for any numeric type invokes UB (which, of
course, includes the possibility of raising a signal).
Yet another reason not to use sscanf to validate user input from
Web forms, <cliche>as if the camel's back weren't already broken by
previous straws</cliche>.
Mar 20 '07 #140
re*****@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>From: Yevgen Muntyan <muntyan.removet...@tamu.edu>
Just don't mention GNU-only functions at all.

I'd like to do that, but I don't know of any search engine where I
type in the name of a C library function and get back the status of
that particular function and the various standards (C99, C89/C90,
K&R) and implementations. So occasionally I will read about some
function, try it, find it works, and describe it in my document,
without any to know it isn't standard.
You can find out by looking it up in a copy of the standard, or a
draft of the standard. You've been told several times how you can get
one in plain text form.

[...]
I'm not aware of any man pages that tell whether a given function
in c is standard and if so which standard.
I've seen man pages that have a "CONFORMING TO" section or something
similar. Look around.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mar 20 '07 #141
From: "santosh" <santosh....@gmail.com>
You'll have to buy the actual Standard, ...
That's rather rude of you to tell a person who is totally broke and
appx. $64,000 in debt to credit cards (just for basic living
expenses to stay alive for nearly 7 years before I got into
subsidized housing) that the person "will have to buy" something. I
suggest strongly that you find a lawyer who will very quickly track
down who sent me two hundred spam just in one day, worth two
hundred thousand dollars per California law if we can find who they
are and serve court papers on them. Then I'll be able to afford to
hire a large team of private detectives to track down the rest of
the spammers who have been flooding my mailbox with two hundred
spam per day for the past three years, worth 219 million dollars
so-far. Hey, if you personally know how to track down spammers,
maybe you could make a buck by helping me track down the first of
the spammers? You get paid as soon as we collect from the spammer,
OK? Or as soon as we get court judgement we sell it to a collection
agency at a discount, for example fifty spam from one spammer,
judgement of $50,000, we sell to collection agency for %10,000,
which should give us enough seed money to re-invest in suing more
spammers?
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf>
Since I have no way to view PDF here, I'll ignore that pointer.
CBFalconer has a pure text version of the final C99 draft at:
<http://cbfalconer.home.att.net/download/n869_txt.bz2>
Sorry, I read only English. When I copy&paste that URL into the Web
browser (lynx) and fetch the Web page, I see something that ain't English:

BZh91AY&SYgZy#EpDT{ c]>=+v" NzUm<s;<rntx/jhm`u{>|sKk}aYiE
S m9[A]%2 r*m-%TP`(kUR "^:*@$W}x:;o`z"Jo}pm1tcO,lz;G=^_{asAtV>@$")hVZ 5>[(ZV!4
P44V"Ed}[6
%hI&$ZQLI) 5-P hU
HkI *
6RX0TIFm#6)6Hk i]
u] Q)IT4u'n<[@7KWw|=uH>0v:}o3>}oW<]o;I^;v`{J:Zf>j+3
O>{^{F4=T+t.@iBMj9,.h nc22ZgY.AVSlh_7:[FGv=YhIR0iU.#}uNrUV snNAST)RL_Wwf4E;5[+6
FM6kv55mU-}L9t\CUhYEqEu'Y]mRN_}NZ1t%3>=TPRJ$LU>H@rV_ppwwY>{'+;k)mE4-lK -:pvy8wp
w=8`WOZahh$SwnWaFRQXV=:{q]ide%{7''j_f)TERZ/LUVvE:mg\RSinEM0T=skTXmuK\Z(l)JyjRTm
` 5 ( D6U#lia^F`o`.mQ!"kR{=XRmbv5#&osK_l;7'1nlt-d_MM,,cmsor|"d5P%5K7ptw=`}zT4
SJP2AwJ8pkUN{]djn]p$@XPLXRT
aM7[]6vto^ou\0N=N9XVe]0#hMWpo0zw_9>s^>+>wt}us@pxu8WG]]^vr{:h@,zv]:;XzW!unXfW:i$
Q>0VuX
wU\3n()[A;7p>mP.<>{;T@{9e<tw0l6D6N7g|^5U${yJY.
@Y QQAR[ee]e]U@@i]Lazbg<tJu9j
h).B[ll{nF5*N]"LttHl v`]W/: U]d5%jz4'ZvRD *pig\uv|z/]&nw{;\)AEim9l<gN]\xxthI@
&( 4[\D"*FZYwYa@64+iGv"U34P=F1@R(mj
k.
w\}fmwR}iP:;|>

Now if you would be so kind as to translate that to English...

Via Google search, after somebody posted the correct search term to
try, I found something which is English, but it's nearly two
thousand VT100 screens, more than 1.3 megabytes (I downloaded it to
my shell account), so it'll take some time to browse it. What I
might do is hyperize it, i.e. write a CGI script that extracts
sections of text from it to emulate Web pages with links. Then I
would have for C99 virtually something roughly equivalent to
Pitman's Common Lisp HyperSpec. I'm rather dismayed that nobody has
bothered to do that in the 8 years since it was published, that I
would have to be the first to do that if it's ever to be done.
<OT>Why does that last sentence give me the feeling that I'm almost
quoting from Alice's Adventures in Wonderland? Does anybody
recognize the passage?</OT>
Mar 20 '07 #142
Robert Maas, see http://tinyurl.com/uh3t said:
>From: "santosh" <santosh....@gmail.com>
You'll have to buy the actual Standard, ...

That's rather rude of you
Please bear in mind that English is almost certainly not Santosh's first
language, and it is very possible - even likely - that you have
misinterpreted him. I believe that what he intended to say was: "if you
want the actual Standard itself, you'll have to buy it" (which is true,
because it's not available for free). Why do I believe this? I'll tell
you. It's because of the rest of what he said in that very sentence,
which you appear to have deliberately ignored:

"You'll have to buy the actual Standard, but the latest working paper,
which includes two added Technical Corrigenda is available for free".
to tell a person who is totally broke
I sympathise, but that's your problem, not his.
><http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf>
Since I have no way to view PDF here, I'll ignore that pointer.
Again, I sympathise. PDF is no substitute for a portable document
format. Unfortunately, that's ISO's release format, and there's no
helping it. Yes, you can get text conversions, but you tend to lose
some important format information (e.g. subscript and superscript info
is lost, so you see sillinesses such as 232 - 1 on occasion).
>CBFalconer has a pure text version of the final C99 draft at:
<http://cbfalconer.home.att.net/download/n869_txt.bz2>

Sorry, I read only English. When I copy&paste that URL into the Web
browser (lynx) and fetch the Web page, I see something that ain't
English:
At this point, either you're just being silly for the sake of being
silly, or you're saying you don't recognise bzip2 format.
Now if you would be so kind as to translate that to English...
You can do it yourself, using bunzip2. Furrfu.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 20 '07 #143
re*****@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>From: "santosh" <santosh....@gmail.com>
You'll have to buy the actual Standard, ...

That's rather rude of you to tell a person who is totally broke and
appx. $64,000 in debt to credit cards (just for basic living
[15 lines deleted]
which should give us enough seed money to re-invest in suing more
spammers?
My sympathy for your situation is wearing thin. This newsgroup is for
discussion of the C programming language, not a forum for you to whine
about your misfortune. We've all got problems, dude.
><http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf>
Since I have no way to view PDF here, I'll ignore that pointer.
>CBFalconer has a pure text version of the final C99 draft at:
<http://cbfalconer.home.att.net/download/n869_txt.bz2>

Sorry, I read only English. When I copy&paste that URL into the Web
browser (lynx) and fetch the Web page, I see something that ain't English:
[snip]

The ".bz2" suffix means it's compressed with the "bzip2" compression
program.
[...]
Via Google search, after somebody posted the correct search term to
try, I found something which is English, but it's nearly two
thousand VT100 screens, more than 1.3 megabytes (I downloaded it to
my shell account), so it'll take some time to browse it.
Yes, that's about right. My copy of n869.txt (uncompressed from
n869_txt.bz2) is 1128 kbytes; n1124.txt (exported from n1124.pdf) is
1040 kbytes.
What I
might do is hyperize it, i.e. write a CGI script that extracts
sections of text from it to emulate Web pages with links. Then I
would have for C99 virtually something roughly equivalent to
Pitman's Common Lisp HyperSpec. I'm rather dismayed that nobody has
bothered to do that in the 8 years since it was published, that I
would have to be the first to do that if it's ever to be done.
I've never felt the need for a "hyperized" version of the standard; I
suspect few others have either. Good luck generating one yourself.

Now that you have a copy of a draft of the standard, perhaps you'll
stop complaining that you don't have one.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mar 20 '07 #144
From: Flash Gordon <s...@flash-gordon.me.uk>
Unfortunately
without access to the 1999 standard, this decision will be
difficult to implement.
(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_stand...g_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?
For example, buffer overflow is natural with pointer arithmetic,
all you need is a teensy programmer bug overlooked admist the
kilometers of source code that needs eyeballing to find anything,
but buffer overflow is impossible in Java or Common Lisp.
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.
Is 20% speed gain really more important than security?
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.
Mar 20 '07 #145
From: Keith Thompson <k...@mib.org>
You're seriously messing up the attributions. Your news client
should handle this for you.
I don't know why you would think such a thing. My HTTP client is
lynx, and then Google Groups is the HTTP server, which is a
database server, which might loosely be considered a news server.
It shows me the original text of the article I've found using the
GG search engine to find it.
some software inserts a '>' character in front of the word "From"
at the beginning of a line.
Well, there's a keyboard driver on my Macintosh which detects that
I've pressed those two keys, then a callback routine in a text
editor (McSink) which treats them logically as characters to
insert, then a system call which actually inserts them into the
edit buffer, which is seen by the screen-refresh loop. Is that what
you are inquiring about?

Later on, I use mouse actions to mark the section of the edit
buffer that I want to copy, then clover-C to invoke the system COPY
function, then mouse action to click over to the VT100 emulator,
then clover-apostophe to "paste" to modem. At the other end, on the
FreeBSD Unix host, TELNET to a NNTP server is accepting that
incoming data and passing it across a TCP/IP connection to that
NNTP server, after a POST command was previously sent manually
(keyboard driver to callback in VT100 emulator to system call to
output characters to modem, and however Unix collects data from the
other modem and passes it to stdin of whatever program is in
foreground, in this case TELNET).
An "lvalue", in the sense that Chris is using the word (which is
not the way the C standard defines it) is a value to which you can
assign.
That makes no sense at all. A value is the thing assigned, not the
variable that gets assigned to.
You can think of it as an address, or as a location.
At the machine level, yes an address can specify a variable, a
place where values can be stored. More generally, a location (in
computer memory, not in my apartment nor anywhere else in real
space) is where values can be stored. An address can specify both:
- places where new/different values can be stored, and
- places where the data is enforced constant so that no new values
can be stored there.
An "lvalue", in the sense that Chris is using the word (which is not
the way the C standard defines it) is a value to which you can assign.
You can think of it as an address, or as a location. For example, given:
x = y + 1;
the expression x is evaluated for its lvalue (which indicates where to
assign the result of the RHS, without looking at the current
*contents* of x),
Note that "evaluation" is done at compile time, to get a relative
address, then the address is adjusted at load time to get a
absolute user-space address (which is relative to page-mapping at
the system level, transparent to user programs except when you jump
around too much and cause paging to thrash).

(Above is for the example you cite, x a simple variable. In the
case of an array element with runtime-variable index, part of the
address adjustment is done at runtime also.)
The /evaluation/ of the expression `x` will yield an lvalue,
which we can usefully think of as "the address of x".
I have no idea what "evaluation" means in c.
Evaluation is what happens when a value is computed from an
expression. It generally happens during program execution.
In the case of simple variables that are static-allocated, even
fixed elements of static-allocated structs, that simply is not
true. *NONE* of the "lvalue-evaluation" (address
calculation/adjustment) happens at run time. To prove it, you could
burn the compiled program into a ROM, whereby the machine address
of x is built right into the machine instruction in the ROM.

Now for stack-allocated simple variables, the machine instruction
is a fixed-offset relative to the stack pointer as an index
register, so in that sense I suppose you could say machine address
calculation (add compiled constant offset to current value of stack
pointer) is done at runtime. Is that what you were babbling about??
So the so-called 'lvalue' is really what in machine language jargon
is called the "effective address". Maybe we should convince the
ISO committee working on C2009 to use that term??
Mar 20 '07 #146
From: Yevgen Muntyan <muntyan.removet...@tamu.edu>
You didn't notice warm feelings from many people here to you?
That's correct, not any warm feelings whatsoever apparent here.
If somebody meant to convey warm feelings toward me, said person
utterly failed at said conveyance.
Only positive-minded careful critical review may help.
I agree. I've seen such very very rarely mixed in with orders of
magnitude more demeaning remarks and vague nearly worthless
critique. Accordingly, not much anybody said has been of help, just
those few tidbits (analagous to gems in a low-yield mine).
Select the language pair:
[C to C++ ]
[C to Lisp ]
[C to Java ]
[C to Perl ]
[C++ to Lisp ]
[C++ to Java ]
[Java to Lisp]
[Perl to Lisp]
[Perl to Java]
[Perl to PHP ]
(Does anybody notice the deliberate directional bias?)
Maybe you should call your page "C and other funny languages for
LISP'ers"? Would help to avoid some confusion perhaps.
Well if and when I ever pull that joke, set up the CGI script that
translates programs from C to other languages, ending up as either
PHP or Common Lisp, never back the other way, your suggestion for
a title might be appropriate. But for now, I don't plan to implement
any such translation. In the short term I'm not even working on
my original idea, which was to have a language-independent workbench
for constructing algorithms, plus automatic translations from the
abstract tree of the workbench to each of the six languages
equally. Both the current matrix document, and the proposed
original workbench for building algorithms interactively, would be
symmetric with respect to the six programming languages. (At the
moment, as a practical matter of covering all the material, I'm
starting by completely covering the least-expressive language,
namely C, together with equivalents in all the other
more-expressive languages, and if that's ever done then I'll move
to completing the second-least expressive language (C++) with
translations to all the other languages except C, etc. until
eventually I try to cove 100% of the most expressive language.)
(Caveat: By "expressive" I'm referring to expressing high-level
abstractions of use to application programming. I'm not referring
to the ability to hack any machine language construct you may
choose to shoot close to your foot and just take your chances
whether a simple mistake shoots a hole right through your foot. In
that category, C is most expressive of the six, only slightly less
expressive than Pocket Forth or Sesame C or assembly language or
pressing the machine-language debugger button on the Macintosh
or ResEdit etc.)
Mar 20 '07 #147
"Robert Maas, see http://tinyurl.com/uh3t" wrote:
>From: Yevgen Muntyan <muntyan.removet...@tamu.edu>
>Just don't mention GNU-only functions at all.

I'd like to do that, but I don't know of any search engine where I
type in the name of a C library function and get back the status of
that particular function and the various standards (C99, C89/C90,
K&R) and implementations. So occasionally I will read about some
function, try it, find it works, and describe it in my document,
without any to know it isn't standard.
You are a complete fake. You have been told time after time where
to get the C standard at zero cost, after which detecting that the
function is standard is at most a matter of using grep. Yet you
persist in this silly moaning. No wonder you are unemployable.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Mar 20 '07 #148
"Robert Maas, see http://tinyurl.com/uh3t" <re*****@yahoo.comwrote in
message news:re***************@yahoo.com...
>From: Yevgen Muntyan <muntyan.removet...@tamu.edu>
Just don't mention GNU-only functions at all.

I'd like to do that, but I don't know of any search engine where I
type in the name of a C library function and get back the status of
that particular function and the various standards (C99, C89/C90,
K&R) and implementations. So occasionally I will read about some
function, try it, find it works, and describe it in my document,
without any to know it isn't standard.
Well, the authoritative way is to download the standard (e.g. n1124.pdf) and
search for the function you're curious about. If it's there, it's standard
:)
By the way, I hope my readers will look up the complete definition
of the function, using Google for example, any place my quickie
definition isn't quite complete in all details.
>Is this how *you* get the documentation? You should consider something
better, like C libraries manuals, man pages, C standard. man pages
are pretty good, they tell you about the standards given function
conforms to.

I'm not aware of any man pages that tell whether a given function
in c is standard and if so which standard.
If you're on a unix-ish system, try "man func" and look for a "Conforming
To" section. If you're on some other type of system, or if your local man
pages suck, Google for "func man page". For instance, the first hit I see
for 'strlen man page' is:
http://www.die.net/doc/linux/man/man3/strlen.3.html
and that page explicitly says the function is in C89 and C99.

If you work with a lot of unix-ish code, you'll see that a lot of functions
you're used to will be listed as conforming to POSIX and _not_ C89/99. For
example, compare the man pages for open() and fopen().

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

Mar 20 '07 #149
re*****@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>From: Flash Gordon <s...@flash-gordon.me.uk>
Unfortunately
without access to the 1999 standard, this decision will be
difficult to implement.
(which was true at the time I wrote it)
Once again, you post hundreds of lines, only a fraction of it relevant.
Please try to restrain yourself.

And once again, *please* learn to quote properly. I've told you this
before. You seem to be constructing your own attribution lines, like this:
From: John Doe <jd**@example.com>
... stuff that John Doe wrote ...
The standard form is like this, or something similar

John Doe <jd**@example.comwrites;
... stuff that John Doe wrote ...
Putting an extra "" in front of the attribution line is very
confusing. It's possible that the "" is being added by your
software because you use the word "From".

Just let your newsreading software construct the attribution lines for
your.

[...]
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"??
You'll find the answer in 6.2.3p1, the section on "Types".
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!).
So you were able to answer your own question. Why did you find it
necessary to share that with us?
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.
No, it isn't; it's a common and useful technique.

[...]
** 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.
Huh? Did you look at section 7, which fully describes the standard
library?
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.
[...]

Nobody cares where you downloaded the file; please don't waste our
time telling us the boring details.

[...]
[#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??
Two's-complement applies to integer arithmetic, not to floating-point
arithmetic. Most systems these days use IEEE floating-point, which
does support signed zeros.

[...]
Hey, does the Pope know about you?
*Try* to stay on-topic. I'm about to give up on wading through all
the irrelevant crap you post. I'm probably one of the very few who
didn't give up some time ago.

[...]
>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.
Section 6.5.8, "Relational operators", describes the behavior of the
<, <=, >, and >= operators. You'll find that applying such an
operator to two pointers that don't point into the same object (or
just past it) invokes undefined behavior.

[...]
>* 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.
Don't throw around accusations of dishonesty unless you're very sure
of yourself.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mar 20 '07 #150

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

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.