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

[Keith Thompson]

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

rem642b@yahoo.c om (robert maas, see http://tinyurl.com/uh3t) writes:

>From: "Malcolm McLean" <regniz...@btin ternet.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_Keit h) kst-u@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.

[Keith Thompson]

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

rem642b@yahoo.c om (robert maas, see http://tinyurl.com/uh3t) writes:

>From: CBFalconer <cbfalco...@yah oo.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_Keit h) kst-u@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.

[robert maas, see http://tinyurl.com/uh3t]

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

From: Chris Dollin <chris.dol...@h p.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>derefer encing</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 "clarificat ion" 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.

[CBFalconer]

Re: Requesting advice how to clean up C code for validating stringrepresent s integer

"robert maas, see http://tinyurl.com/uh3t" wrote:

From: CBFalconer <cbfalco...@yah oo.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>

[Yevgen Muntyan]

Re: Requesting advice how to clean up C code for validating stringrepresent s integer

Flash Gordon wrote:

Yevgen Muntyan wrote, On 20/02/07 03:54:

>robert maas, see http://tinyurl.com/uh3t wrote:

>>>From: Yevgen Muntyan <muntyan.remove t...@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
>>implementatio ns 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
>>individuall y 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

[Keith Thompson]

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

rem642b@yahoo.c om (robert maas, see http://tinyurl.com/uh3t) writes:

>From: Chris Dollin <chris.dol...@h p.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_Keit h) kst-u@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.

[Yevgen Muntyan]

Re: Requesting advice how to clean up C code for validating stringrepresent s integer

robert maas, see http://tinyurl.com/uh3t wrote:

>From: Yevgen Muntyan <muntyan.remove t...@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

[CBFalconer]

Shorter Articles are better (was: Requesting advice how to clean up Ccode for validating string represents integer)

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

[Flash Gordon]

Re: Requesting advice how to clean up C code for validating stringrepresent s integer

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.remove t...@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
>>>implementati ons 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
>>>individual ly 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

[Flash Gordon]

Re: Requesting advice how to clean up C code for validating stringrepresent s integer

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

[Yevgen Muntyan]

Re: Requesting advice how to clean up C code for validating stringrepresent s integer

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.remove t...@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
>>>>implementat ions 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
>>>>individuall y 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
>>>>definitio n 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
>>bibliograph y 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

[Flash Gordon]

Re: Requesting advice how to clean up C code for validating stringrepresent s integer

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.remove t...@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
>>>>>implementa tions 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
>>>>>individual ly 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
>>>>>function s 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
>>>>>definiti on 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
>>>bibliograp hy 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

[Yevgen Muntyan]

C99 and before (Was: Requesting advice how to clean up C code forvalidating string represents integer)

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

[Flash Gordon]

Re: C99 and before (Was: Requesting advice how to clean up C codefor validating string represents integer)

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

[Chris Dollin]

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

robert maas, see http://tinyurl.com/uh3t wrote:

>From: Chris Dollin <chris.dol...@h p.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/