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

From: Mark McIntyre <markmcint...@xxxxxxxxxxx>
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 *** 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???
.