Pointer before array proposal
Daniel Vallstrom
an array.
IMO allowing pointers just beyond an array, acting as sentinels, is enormously
useful. Likewise, pointers just before an array would also be very useful,
even though not quite as useful.
AFAICS the reason for allowing pointers beyond an array is that it at worst
costs only one byte while allowing pointers before an array might cost too
much. E.g. if the elements in an array a, which could consist of only one
element, are enormous, guaranteeing that a-1 works by making sure that there
is enough space before the array a could very well be too wasteful and
inefficient. This was the reason given by at least Francis Glassborow in
this lengthy thread:
http://groups.google.com/groups?q=g:thl1386348651d&dq=&hl=en&lr=&ie=UTF-8&as_
drrb=b&as_mind=29&as_minm=3&as_miny=1995&as_maxd=29&as_maxm=5&as_maxy=2000&se
lm=vOR%2BfrAs89L5EwRr%40robinton.demon.co.uk
But AFAICS that's also the only reason for not allowing pointers before an
array.
So why not allow pointers before an array in cases where it would cost almost
nothing like in the beyond case? Exactly how big elements that are guaranteed
to work might be an implementation limit but ideally the standard would
guarantee that obvious cases that cost virtually nothing like array of
integers, array of pointers etc. would work. This would make almost all cases
occurring in practice work at negligible cost.
It's my experience and belief that there exist fairly much code that use
pointers before arrays (as sentinels) because
1) the coder is unaware of that it's undefined behavior in general; or
2) the coder doesn't recognize that the pointer can in fact point before
the array; or
3) the coder vaguely recognizes that there can be a pointer before an
array and on some level is aware of that having a pointer before an
array is UB but doesn't connect the two, e.g. because she is focused on
more algorithmic issues; or
4) the coder is aware of the undefined behavior but feels it's too much
trouble to bother for too little benefit.
The direct reason why I'm writing this is that I recently, after perhaps
the third careful read-through of a piece of code I had written, realized
that a sentinel pointer could in fact, on some inputs, point to one place
before an array (some layered stack). This sentinel pointer is used a lot
in many blocks and loops and may also change and any fix is going to be
messy and far from changing a for-loop into an if-do-while construction.
The alternative, allocating a dummy element before the actual array start,
feels ugly and unnecessary, and there is (re)allocation code for the array
in several places. Still, the dummy element fix will probably be the one
preferred.
Daniel Vallstrom
Derk Gwen
# nothing like in the beyond case? Exactly how big elements that are guaranteed
# to work might be an implementation limit but ideally the standard would
# guarantee that obvious cases that cost virtually nothing like array of
# integers, array of pointers etc. would work. This would make almost all cases
# occurring in practice work at negligible cost.
I doubt most people if extra space is allocated after an array, especially if
they take care not to store or load outside array bounds. But extra space in
front of an array risk making some programs impossible. There are times when
you need to address a specific address, such as memory mapped I/O registers
or mapped in virtual memory. You know exactly where the address begins, so you
can't bump the start of the array back a bit, and the memory mapping does not
permit anything to be addressed just in front of it, so it can't guarentee
addressable bytes in front of the start address.
--
Derk Gwen http://derkgwen.250free.com/html/index.html
OOOOOOOOOO! NAVY SEALS!
pete
>
> Here is some sort of proposal for allowing some
> form of pointers just before an array.
>
> IMO allowing pointers just beyond an array, acting as sentinels,
> is enormously useful. Likewise, pointers just before an
> array would also be very useful,
> even though not quite as useful.
> AFAICS the reason for allowing pointers beyond an array
> is that it at worst costs only one byte while allowing pointers
> before an array might cost too much.
It doesn't have to cost one byte of memory.
The byte after an array,
may or may not be the first byte of another object.
When decrementing down through an array, sometimes you can
avoid the illegal subaddress by using the prefix decrement
or by decrementing the pointers at the begining of the loop:
/*
** Mergesort Function Fragment
** base is the base of an array.
** after1 and after2 are both "one past" sentinels.
*/
static void merge(e_type *base, e_type *arr1, size_t nmemb)
{
if (nmemb > SMALL_MERGE) {
e_type *arr2;
size_t const half = nmemb / 2;
e_type *const middle = base + half;
e_type *const after1 = arr1 + half;
e_type *const after2 = base + nmemb;
merge(base, arr1, half);
merge(middle, arr1, nmemb - half);
arr1 = after1;
arr2 = middle;
do {
*--arr1 = *--arr2;
} while (base != arr2);
E. Robert Tisdale
Daniel,
Nobody cares about this problem because it isn't a problem.
There are no viable computer architectures
and there probably never will be any viable computer architectures
where "out of bounds pointers" cause problems
unless you actually attempt to access the object to which they point.
Forget about the superstitions beliefs of our religious zealots.
Believe me.
There are more important things that you need to be concerned about.
Pray that, eventually, more rational heads will prevail
in the ANSI and/or ISO standards committees and a more complete
description of memory space and pointers will evolve.
CBFalconer
>
... snip ...
>
> Nobody cares about this problem because it isn't a problem.
> There are no viable computer architectures
> and there probably never will be any viable computer architectures
> where "out of bounds pointers" cause problems
> unless you actually attempt to access the object to which they point.
> Forget about the superstitions beliefs of our religious zealots.
> Believe me.
> There are more important things that you need to be concerned about.
> Pray that, eventually, more rational heads will prevail
> in the ANSI and/or ISO standards committees and a more complete
> description of memory space and pointers will evolve.
Kindly stop spouting this ridiculous theme, and forcing other
people to post corrections to your misinformation. You have been
given examples aplenty. Or do you enjoy portraying yourself as a
sedulously mewling idiot?
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Douglas A. Gwyn
> The alternative, allocating a dummy element before the actual array start,
So you'd insist that *every* C implementation, for *every*
program, *always* itself allocate such a dummy element?
This is not a notion that will succeed.
Douglas A. Gwyn
> There are no viable computer architectures
> and there probably never will be any viable computer architectures
> where "out of bounds pointers" cause problems
> unless you actually attempt to access the object to which they point.
That's certainly not true.
Keith Thompson
[...]
> Nobody cares about this problem because it isn't a problem.
Even if you're right and the rest of are wrong, it is manifestly
untrue that "nobody cares about this problem".
[...]
> Pray that, eventually, more rational heads will prevail
> in the ANSI and/or ISO standards committees and a more complete
> description of memory space and pointers will evolve.
By all means, write one for us.
--
Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Francis Glassborow
<DAG...@null.net> writes
Even more so when we remember that single variables are also valid
arrays of one and have the same one past the end guarantee.
--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow ACCU
Daniel Vallstrom
> Daniel Vallstrom wrote:
> > The alternative, allocating a dummy element before the actual array start,
> > feels ugly and unnecessary, ...
>
> So you'd insist that *every* C implementation, for *every*
> program, *always* itself allocate such a dummy element?
No, that is not what I proposed, just as I don't insist that *every* C
implementation, for *every* program, *always* itself allocate such a
dummy element after an array.
> This is not a notion that will succeed.
Are you then advocating not allowing pointers beyond an array since
that imposes roughly the same amount of work for implementations as
allowing some pointers before an array AFAICS?
Daniel Vallstrom
Francis Glassborow
Vallstrom <Daniel.V...@safelogic.se> writes
No it does not. On many architectures with proper memory management the
process must own the memory if it loads an address register with an
address within that memory block. The one beyond the end rule simply
requires that, at most, the process owns one more byte. One before the
beginning requires that the process own sufficient memory prior to the
first byte of the object (all objects behave as arrays, even if only
arrays of 1) so the address of one before the start is valid.
Not only is this potentially very expensive but it is also impossible
for the compiler to provide in the presence of dynamic resources. For
example a consequence of your proposal is that I would have to rewrite
something such as:
int * array = malloc(n * sizeof int);
with:
int * array =( (int *) malloc((n+1) * sizeof(int)) + 1)
I would also have to make the reverse adjustment when freeing the block.
And malloc() simply does not have the necessary information to do that
for me. However, note that in systems where it matters, malloc can
always overallocate by 1 byte in order to meet the current guarantee of
the address of one past the end being a valid address, though not
dereferenceable.
Arthur J. O'Dwyer
Francis Glassborow has given an excellent technical answer to your
question, but I have a different objection. It seems that nobody else
really considers your proposal to solve any problem with the current
language. What problem are you trying to solve that can't be done
as simply in C99? Code would be nice, but a coherent explanation in
pseudocode would probably be fine.
-Arthur
Daniel Vallstrom
> In message <3ED5881A...@null.net>, Douglas A. Gwyn
> <DAG...@null.net> writes
> >Daniel Vallstrom wrote:
> >> The alternative, allocating a dummy element before the actual array start,
> >> feels ugly and unnecessary, ...
> >
> >So you'd insist that *every* C implementation, for *every*
> >program, *always* itself allocate such a dummy element?
> >This is not a notion that will succeed.
>
> Even more so when we remember that single variables are also valid
> arrays of one and have the same one past the end guarantee.
And not at all so when we remember that the only thing
needed is that *some* implementations *might* have to on
some *very uncommon* platforms reserve say 4 bytes at the
beginning of data space in contrast to the single byte at
the end for the pointer beyond array concept.
Daniel Vallstrom
Francis Glassborow
Vallstrom <Daniel.V...@safelogic.se> writes
You obviously are not listening so I do not intend to further this
dialogue. Just accept that what you are proposing will not happen.
Keith Thompson
> Francis Glassborow <francis.g...@ntlworld.com> wrote in
> message news:<ipQteSC0...@robinton.demon.co.uk>...
> > Even more so when we remember that single variables are also valid
> > arrays of one and have the same one past the end guarantee.
>
> And not at all so when we remember that the only thing
> needed is that *some* implementations *might* have to on
> some *very uncommon* platforms reserve say 4 bytes at the
> beginning of data space in contrast to the single byte at
> the end for the pointer beyond array concept.
Your proposal is to allow creating a pointer to one before the
beginning of an array for some (sufficiently small) types. The
programming technique you propose that takes advantage of this feature
makes as much sense for larger types as for smaller ones. Programmers
would have to figure out whether the technique can be used with a
given implementation for a given type -- and if they guess wrong, the
only consequence will be undefined behavior (i.e., it's likely to work
as expected 99% of the time, until the moment when it can cause the
greatest possible damage).
For something this subtle, it's best to keep the rules as simple as
possible.
CBFalconer
> Francis Glassborow <francis.g...@ntlworld.com> wrote:
> > <DAG...@null.net> writes
> > >Daniel Vallstrom wrote:
>
> > >> The alternative, allocating a dummy element before the actual
> > >> array start, feels ugly and unnecessary, ...
> > >
> > > So you'd insist that *every* C implementation, for *every*
> > > program, *always* itself allocate such a dummy element?
> > > This is not a notion that will succeed.
> >
> > Even more so when we remember that single variables are also
> > valid arrays of one and have the same one past the end guarantee.
>
> And not at all so when we remember that the only thing
> needed is that *some* implementations *might* have to on
> some *very uncommon* platforms reserve say 4 bytes at the
> beginning of data space in contrast to the single byte at
> the end for the pointer beyond array concept.
Many systems arrange their data space starting at zero, with a
non-assigned page at the beginning. This allows simple trapping
of a NULL dereference, or of any pointer value that is below the
size of a page. It also allows a simple method of uncovering most
invalid pointers even before they have been dereferenced. Please
explain how such a system can reserve any space before the first
item in the data area. Or do you consider an X86 based machine a
"*very uncommon* platform"? How about a 360 or 370 architecture?
Barry Margolin
CBFalconer <cbfal...@worldnet.att.net> wrote:
>Many systems arrange their data space starting at zero, with a
>non-assigned page at the beginning. This allows simple trapping
>of a NULL dereference, or of any pointer value that is below the
>size of a page. It also allows a simple method of uncovering most
>invalid pointers even before they have been dereferenced. Please
>explain how such a system can reserve any space before the first
>item in the data area. Or do you consider an X86 based machine a
>"*very uncommon* platform"? How about a 360 or 370 architecture?
Locate the text segment at low memory (e.g. starting at the first page
after that initial unassigned page), and the data segment in high memory.
And in the case of data objects in the text segment (i.e. variables
declared const), they could be located at the high end of the text segment;
the low end would be reserved for code.
The result of this memory layout is that no data objects would be adjacent
to that unassigned page.
--
Barry Margolin, barry.m...@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
pete
> It's my experience and belief that there exist fairly much
> code that use pointers before arrays (as sentinels) because
Once you know the rules, it's very easy to write code
which doesn't use an (array - 1) sentinel.
Then, it seems like the only purpose to your proposal
is to legitimize old bad code.
But there's no end to the amount and variety of old bad code.
I think your proposal is pointless.
--
pete
Douglas A. Gwyn
> Are you then advocating not allowing pointers beyond an array since
> that imposes roughly the same amount of work for implementations as
> allowing some pointers before an array AFAICS?
No, I'm telling you that you don't understand the problem.
In fact the C standards committee considered this issue
long ago, and found it imposed too much of a burden on
otherwise perfectly reasonable implementations. The only
reason the one-past-the-end address computation was
required to be supported universally was that we knew how
to make it work relatively cheaply, and it was a common
idiom that needed full support. Down-addressing was
much rarer (for good reason!) and had already had to be
changed in the course of porting older software, since in
fact it did/does cause problems on many platforms.
Daniel Vallstrom
> Daniel.V...@safelogic.se (Daniel Vallstrom) writes:
> > Francis Glassborow <francis.g...@ntlworld.com> wrote in
> > message news:<ipQteSC0...@robinton.demon.co.uk>...
> [...]
> > > Even more so when we remember that single variables are also valid
> > > arrays of one and have the same one past the end guarantee.
> >
> > And not at all so when we remember that the only thing
> > needed is that *some* implementations *might* have to on
> > some *very uncommon* platforms reserve say 4 bytes at the
> > beginning of data space in contrast to the single byte at
> > the end for the pointer beyond array concept.
>
> Your proposal is to allow creating a pointer to one before the
> beginning of an array for some (sufficiently small) types. The
> programming technique you propose that takes advantage of this feature
> makes as much sense for larger types as for smaller ones. Programmers
> would have to figure out whether the technique can be used with a
> given implementation for a given type -- and if they guess wrong, the
> only consequence will be undefined behavior (i.e., it's likely to work
> as expected 99% of the time, until the moment when it can cause the
> greatest possible damage).
While that is true, I think that supporting pointers before arrays
for small types would cover almost all situations occurring in
practice. If the standard would guarantee the behavior for
those small types, programmers could ignore the exact
implementation limits and revert back to safe old style for the
rare situation when the type isn't small. Exactly what small types
that would be guaranteed to work by the standard would be clearly
listed by the standard.
> For something this subtle, it's best to keep the rules as simple as
> possible.
While that is a respectable view, I think that the benefits of
allowing pointers before arrays for small types far outweigh
the slightly more complicated rules defining what pointers
that would be allowed before arrays.
You say that there is a risk of people introducing undefined
behavior when their types aren't small but you also have to
weight in all the code that would go from undefined behavior
to defined and intended behavior by allowing pointers before
arrays. I think that the latter case would be more frequent
than the former.
Daniel Vallstrom
Daniel Vallstrom
> Daniel Vallstrom wrote:
> > Francis Glassborow <francis.g...@ntlworld.com> wrote:
> > > <DAG...@null.net> writes
> > > >Daniel Vallstrom wrote:
>
> > > >> The alternative, allocating a dummy element before the actual
> > > >> array start, feels ugly and unnecessary, ...
> > > >
> > > > So you'd insist that *every* C implementation, for *every*
> > > > program, *always* itself allocate such a dummy element?
> > > > This is not a notion that will succeed.
> > >
> > > Even more so when we remember that single variables are also
> > > valid arrays of one and have the same one past the end guarantee.
> >
> > And not at all so when we remember that the only thing
> > needed is that *some* implementations *might* have to on
> > some *very uncommon* platforms reserve say 4 bytes at the
> > beginning of data space in contrast to the single byte at
> > the end for the pointer beyond array concept.
>
> Many systems arrange their data space starting at zero, with a
> non-assigned page at the beginning. This allows simple trapping
> of a NULL dereference, or of any pointer value that is below the
> size of a page. It also allows a simple method of uncovering most
> invalid pointers even before they have been dereferenced. Please
> explain how such a system can reserve any space before the first
> item in the data area.
The solution is obvious. If there could be a problem, start handing
out space say 4 bytes after the place where you would start handing
out space from if you wouldn't want to support pointers before
arrays for small types.
Daniel Vallstrom
Daniel Vallstrom
It seems that you have not read my original post. You are just
restating more or less things I have said in the proposal. The
reasons you give are the reasons why I'm only proposing
allowing pointers before arrays for *small types*.
Daniel Vallstrom
pete
> You say that there is a risk of people introducing undefined
> behavior when their types aren't small but you also have to
> weight in all the code that would go from undefined behavior
> to defined and intended behavior by allowing pointers before
> arrays.
You think that's a good (or even real) way to fix code ?
Q: How many Microsoft engineers does it take to change a light bulb?
A: None. Bill Gates will just redefine Darkness(TM)
as the new industry standard.
http://paul.merton.ox.ac.uk/computing/gates.html
--
pete
Christian Bau
Daniel.V...@safelogic.se (Daniel Vallstrom) wrote:
> The solution is obvious. If there could be a problem, start handing
> out space say 4 bytes after the place where you would start handing
> out space from if you wouldn't want to support pointers before
> arrays for small types.
The "solution" creates extra work and nobody except you thinks it has
any benefit. A "solution" that works only for small types would be
something that I would find absolutely disgusting. There is lots of work
involved for such a proposal which I am sure _you_ will not be willing
to do; it has no chance to get past a public commenting period of the
next C Standard; it has no chance to get past a vote of the members of
the C Standard committee.
Believe me, I can come up with ten suggestions every day that would be
more of an improvement to the C Standard, and none of them would have a
chance.
Daniel Vallstrom
> > Francis Glassborow <francis.g...@ntlworld.com> wrote in
> > message news:<ipQteSC0...@robinton.demon.co.uk>...
> [...]
> > > Even more so when we remember that single variables are also valid
> > > arrays of one and have the same one past the end guarantee.
> >
> > And not at all so when we remember that the only thing
> > needed is that *some* implementations *might* have to on
> > some *very uncommon* platforms reserve say 4 bytes at the
> > beginning of data space in contrast to the single byte at
> > the end for the pointer beyond array concept.
>
> Your proposal is to allow creating a pointer to one before the
> beginning of an array for some (sufficiently small) types. The
> programming technique you propose that takes advantage of this feature
> makes as much sense for larger types as for smaller ones. Programmers
> would have to figure out whether the technique can be used with a
> given implementation for a given type -- and if they guess wrong, the
> only consequence will be undefined behavior (i.e., it's likely to work
> as expected 99% of the time, until the moment when it can cause the
> greatest possible damage).
>
> For something this subtle, it's best to keep the rules as simple as
> possible.
Perhaps you specifically mean that the pointer-before concept
would be complicated for user defined types like
struct SmallUserType1{ char c; } or more realistically
struct SmallUserType2{ char c1; char c2; }? I think that
most cases where a pointer before an array would be useful
involve only basic types. But if you want to cover all types
you'll give the basic types some rank-size, e.g.
rank-size(char)=1 say. Then inductively extend rank-size by
summing so that the rank-size of a type would be the sum of
the rank-sizes of its basic types and e.g.
rank-size(struct SmallUserType2) = 2.
Admittedly all this strengthen you criticism that allowing
before-pointers for small types would complicate the
language, but not excessively so IMO and I still think that
it would be well worth it to allow pointers before arrays
for small types.
Daniel Vallstrom
Alan Balmer
Vallstrom) wrote:
>you also have to
>weight in all the code that would go from undefined behavior
>to defined and intended behavior by allowing pointers before
>arrays.
I don't recall ever seeing any such code, and I've certainly never
written any. I don't think changing the standard is a good way to fix
broken code.
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
Barry Margolin
Daniel Vallstrom <Daniel.V...@safelogic.se> wrote:
>It seems that you have not read my original post. You are just
>restating more or less things I have said in the proposal. The
>reasons you give are the reasons why I'm only proposing
>allowing pointers before arrays for *small types*.
I just reread your original message, and it doesn't say this. It proposed
that the maximum size would be implementation-dependent, and suggested that
"ideally" the standard would mandate that this include some of the common
built-in types.
In the cases where the programmer has an array of structs, how is he
supposed to make use of this feature portably? Is he supposed to sprinkle
his code with 'if (sizeof(*myarray) > MAX_PTR_BEFORE_ARRAY_SIZE)
report_error()'? If he has to go to this trouble, wouldn't it be simpler
for him to just fix the algorithm to avoid the need?
pete
>
> On 29 May 2003 17:17:44 -0700, Daniel.V...@safelogic.se (Daniel
> Vallstrom) wrote:
>
> >you also have to
> >weight in all the code that would go from undefined behavior
> >to defined and intended behavior by allowing pointers before
> >arrays.
>
> I don't recall ever seeing any such code,
It's out there.
http://s2k-ftp.cs.berkeley.edu:8000/sequoia/misc/qsort/hsort6.c
void hsort5(char *a, int n, int es, int (*cmp)())
{
a -= es;
> and I've certainly never written any.
I don't any more, but I know that I have in the past.
> I don't think changing the standard is a good way to fix broken code.
--
pete
Barry Margolin
pete <pfi...@mindspring.com> wrote:
>Alan Balmer wrote:
>>
>> On 29 May 2003 17:17:44 -0700, Daniel.V...@safelogic.se (Daniel
>> Vallstrom) wrote:
>>
>> >you also have to
>> >weight in all the code that would go from undefined behavior
>> >to defined and intended behavior by allowing pointers before
>> >arrays.
>>
>> I don't recall ever seeing any such code,
>
>It's out there.
>http://s2k-ftp.cs.berkeley.edu:8000/sequoia/misc/qsort/hsort6.c
>
>void hsort5(char *a, int n, int es, int (*cmp)())
>{
>
>a -= es;
If your proposal were adopted, but the maximum required element size that
had to be supported were less than 1024 (the MYBUFSIZE value in the code),
the function still be broken. Since you've stated that you only feel it
necessary to support arrays of small, built-in types, it seems likely that
the required size would indeed be smaller than this.
Hallvard B Furuseth
>>> you also have to weight in all the code that would go from undefined
>>> behavior to defined and intended behavior by allowing pointers
>>> before arrays.
>>
>> I don't recall ever seeing any such code,
>
> It's out there.
> http://s2k-ftp.cs.berkeley.edu:8000/sequoia/misc/qsort/hsort6.c
That one easy to fix, however.
I've seen (and fixed) some such code once in a while too.
--
Hallvard
Douglas A. Gwyn
> You say that there is a risk of people introducing undefined
> behavior when their types aren't small but you also have to
> weight in all the code that would go from undefined behavior
> to defined and intended behavior by allowing pointers before
> arrays. I think that the latter case would be more frequent
> than the former.
I disagree. There should be *no* existing code that uses
down-addressing with post-testing against the limit. I
haven't seen any code like that since the early, PDP-11
days of C, and even there it caused problems (since wrap-
around could go undetected, unlike the case for up-
addressing).
Douglas A. Gwyn
> Believe me, I can come up with ten suggestions every day that would be
> more of an improvement to the C Standard, and none of them would have a
> chance.
Actually, well-reasoned, well-justified changes have a good
chance *if the proposals occur during preparation of a
revised standard* and *if there are "champions" for the
proposals* making sure that they continue to be evaluated
by the committee. Within a few years the next round of
revision work should commence, and that would be the best
time to draft such proposals. In the meantime, the C
standard is essentially in a "maintenance" mode, and work
centers primarily on tasks such as the embedded-system
technical report, Unicode character code support, etc.
Douglas A. Gwyn
> Once you know the rules, it's very easy to write code
> which doesn't use an (array - 1) sentinel.
> Then, it seems like the only purpose to your proposal
> is to legitimize old bad code.
Exactly. The current language specification allows the
programmer who needs such a sentinel to easily use one,
without imposing any penalty on anybody who doesn't
need such a sentinel.
Alan Balmer
wrote:
>Alan Balmer wrote:
>>
>> On 29 May 2003 17:17:44 -0700, Daniel.V...@safelogic.se (Daniel
>> Vallstrom) wrote:
>>
>> >you also have to
>> >weight in all the code that would go from undefined behavior
>> >to defined and intended behavior by allowing pointers before
>> >arrays.
>>
>> I don't recall ever seeing any such code,
>
>It's out there.
>http://s2k-ftp.cs.berkeley.edu:8000/sequoia/misc/qsort/hsort6.c
>
>void hsort5(char *a, int n, int es, int (*cmp)())
>{
>
>a -= es;
>
Without knowing what the range restrictions on es are, it seems that
it would take more than Daniel Vallstrom's proposal to fix that one.
>> and I've certainly never written any.
>
>I don't any more, but I know that I have in the past.
>
>> I don't think changing the standard is a good way to fix broken code.
--
Barry Margolin
Alan Balmer <alba...@spamcop.net> wrote:
>On Fri, 30 May 2003 12:38:13 -0400, pete <pfi...@mindspring.com>
>wrote:
>
>>Alan Balmer wrote:
>>>
>>> On 29 May 2003 17:17:44 -0700, Daniel.V...@safelogic.se (Daniel
>>> Vallstrom) wrote:
>>>
>>> >you also have to
>>> >weight in all the code that would go from undefined behavior
>>> >to defined and intended behavior by allowing pointers before
>>> >arrays.
>>>
>>> I don't recall ever seeing any such code,
>>
>>It's out there.
>>http://s2k-ftp.cs.berkeley.edu:8000/sequoia/misc/qsort/hsort6.c
>>
>>void hsort5(char *a, int n, int es, int (*cmp)())
>>{
>>
>>a -= es;
>>
>Without knowing what the range restrictions on es are, it seems that
>it would take more than Daniel Vallstrom's proposal to fix that one.
If you go to the web page he referenced, you'll see that the range
restriction is es <= 1024 (apparently only because there's a temporary
buffer declared char[1024]); if es is larger than that, it calls qsort().
Since I think his original proposal was oriented towards much smaller
objects (he mentioned ints and pointers), it probably wouldn't help this
code, as I said in another post.
Alan Balmer
<barry.m...@level3.com> wrote:
>In article <fa8fdvsus0p6ka738...@4ax.com>,
>Alan Balmer <alba...@spamcop.net> wrote:
>>On Fri, 30 May 2003 12:38:13 -0400, pete <pfi...@mindspring.com>
>>wrote:
>>
>>>Alan Balmer wrote:
>>>>
>>>> On 29 May 2003 17:17:44 -0700, Daniel.V...@safelogic.se (Daniel
>>>> Vallstrom) wrote:
>>>>
>>>> >you also have to
>>>> >weight in all the code that would go from undefined behavior
>>>> >to defined and intended behavior by allowing pointers before
>>>> >arrays.
>>>>
>>>> I don't recall ever seeing any such code,
>>>
>>>It's out there.
>>>http://s2k-ftp.cs.berkeley.edu:8000/sequoia/misc/qsort/hsort6.c
>>>
>>>void hsort5(char *a, int n, int es, int (*cmp)())
>>>{
>>>
>>>a -= es;
>>>
>>Without knowing what the range restrictions on es are, it seems that
>>it would take more than Daniel Vallstrom's proposal to fix that one.
>
>If you go to the web page he referenced, you'll see that the range
>restriction is es <= 1024 (apparently only because there's a temporary
>buffer declared char[1024]); if es is larger than that, it calls qsort().
Interesting. I didn't go look, since I have no intention of either
emulating or fixing it <g>.
>
>Since I think his original proposal was oriented towards much smaller
>objects (he mentioned ints and pointers), it probably wouldn't help this
>code, as I said in another post.
--
Keith Thompson
[...]
> Perhaps you specifically mean that the pointer-before concept
> would be complicated for user defined types like
> struct SmallUserType1{ char c; } or more realistically
> struct SmallUserType2{ char c1; char c2; }? I think that
> most cases where a pointer before an array would be useful
> involve only basic types. But if you want to cover all types
> you'll give the basic types some rank-size, e.g.
> rank-size(char)=1 say. Then inductively extend rank-size by
> summing so that the rank-size of a type would be the sum of
> the rank-sizes of its basic types and e.g.
> rank-size(struct SmallUserType2) = 2.
So you want to introduce a new concept of "rank-size" that seems to be
what sizeof would be if there were no padding. How is this better
than just defining it in terms of the actual size of the type?
Daniel Vallstrom
> On 29 May 2003 17:17:44 -0700, Daniel.V...@safelogic.se (Daniel
> Vallstrom) wrote:
>
> >you also have to
> >weight in all the code that would go from undefined behavior
> >to defined and intended behavior by allowing pointers before
> >arrays.
>
> I don't recall ever seeing any such code,
For example if you use stack-like structures and you need to loop through
them top-down you will most likely have encountered this pointer-before-array
issue. I happen upon the issue fairly often because what I do tend to need
stacks where the order of the elements is important so that I need to loop
through the arrays top-down but maybe that's untypical?
> and I've certainly never
> written any.
That you are aware of that is;p
> I don't think changing the standard is a good way to fix
> broken code.
You get fixes to broken code as a *bonus*. It's not the primary reason for
allowing pointers before arrays for small types.
Daniel Vallstrom
Daniel Vallstrom
> In article <fa8fdvsus0p6ka738...@4ax.com>,
> Alan Balmer <alba...@spamcop.net> wrote:
> >On Fri, 30 May 2003 12:38:13 -0400, pete <pfi...@mindspring.com>
> >wrote:
> >
> >>Alan Balmer wrote:
> >>>
> >>> On 29 May 2003 17:17:44 -0700, Daniel.V...@safelogic.se (Daniel
> >>> Vallstrom) wrote:
> >>>
> >>> >you also have to
> >>> >weight in all the code that would go from undefined behavior
> >>> >to defined and intended behavior by allowing pointers before
> >>> >arrays.
> >>>
> >>> I don't recall ever seeing any such code,
> >>
> >>It's out there.
> >>http://s2k-ftp.cs.berkeley.edu:8000/sequoia/misc/qsort/hsort6.c
> >>
> >>void hsort5(char *a, int n, int es, int (*cmp)())
> >>{
> >>
> >>a -= es;
> >>
> >Without knowing what the range restrictions on es are, it seems that
> >it would take more than Daniel Vallstrom's proposal to fix that one.
>
> If you go to the web page he referenced, you'll see that the range
> restriction is es <= 1024 (apparently only because there's a temporary
> buffer declared char[1024]); if es is larger than that, it calls qsort().
>
> Since I think his original proposal was oriented towards much smaller
> objects (he mentioned ints and pointers), it probably wouldn't help this
> code, as I said in another post.
Indeed it probably wouldn't. The idea behind allowing pointers before arrays
for small types is to allow pointers just one before arrays acting as
sentinels. As a side-effect you would be allowed to have pointers a little
more than one before an array for small "small" types but probably not
nearly as much as 1024.
Daniel Vallstrom
Daniel Vallstrom
> Daniel.V...@safelogic.se (Daniel Vallstrom) writes:
> [...]
> > Perhaps you specifically mean that the pointer-before concept
> > would be complicated for user defined types like
> > struct SmallUserType1{ char c; } or more realistically
> > struct SmallUserType2{ char c1; char c2; }? I think that
> > most cases where a pointer before an array would be useful
> > involve only basic types. But if you want to cover all types
> > you'll give the basic types some rank-size, e.g.
> > rank-size(char)=1 say. Then inductively extend rank-size by
> > summing so that the rank-size of a type would be the sum of
> > the rank-sizes of its basic types and e.g.
> > rank-size(struct SmallUserType2) = 2.
>
> So you want to introduce a new concept of "rank-size" that seems to be
> what sizeof would be if there were no padding. How is this better
> than just defining it in terms of the actual size of the type?
I'm not (necessarily) proposing the introduction of "rank-size". I'm just
proposing allowing pointers before arrays for small types (since IMO
it would be very useful and cost very little). Exactly what "small types"
should mean I don't know. But it would be good if the standard guaranteed
that all basic types and all pointer types would work.
If you above that want some structure types to be guaranteed to also work
you could define something like "rank-size". "rank-size(char)=1" was
arbitrary. You could also set rank-size(char)=pi. But you might not want
to use sizeof since then if sizeof(SmallUserType2) is 666 and the standard
guarantees that pointers before arrays work for sizeof-type less than 8,
before-pointers for SmallUserType2 would mean undefined behaviour, or
implementation dependent behaviour if exactly what sizes that would be
allowed would be defined through implementation limits.
Daniel Vallstrom
Daniel Vallstrom
> In article <171aec1a.03052...@posting.google.com>,
> Daniel Vallstrom <Daniel.V...@safelogic.se> wrote:
> >It seems that you have not read my original post. You are just
> >restating more or less things I have said in the proposal. The
> >reasons you give are the reasons why I'm only proposing
> >allowing pointers before arrays for *small types*.
>
> I just reread your original message, and it doesn't say this. It proposed
> that the maximum size would be implementation-dependent, and suggested that
> "ideally" the standard would mandate that this include some of the common
> built-in types.
True.
>
> In the cases where the programmer has an array of structs, how is he
> supposed to make use of this feature portably?
See my "rank-size" replies to Keith Thompson. Basically, if you want the
standard to also allow some struct types, you can assign values to the basic
types and pointer types and then sum over the basic types in a struct type
to see whether the struct type is small or not.
> Is he supposed to sprinkle
> his code with 'if (sizeof(*myarray) > MAX_PTR_BEFORE_ARRAY_SIZE)
> report_error()'?
Definitely not!
> If he has to go to this trouble, wouldn't it be simpler
> for him to just fix the algorithm to avoid the need?
No, adding 1+1 would be simpler;)
Daniel Vallstrom
Daniel Vallstrom
> On Thu, 29 May 2003, Daniel Vallstrom wrote:
> >
> > "Douglas A. Gwyn" <DAG...@null.net> wrote in message news:<3ED5881A...@null.net>...
> > > Daniel Vallstrom wrote:
> > > > The alternative, allocating a dummy element before the actual array start,
> > > > feels ugly and unnecessary, ...
> > >
> > > So you'd insist that *every* C implementation, for *every*
> > > program, *always* itself allocate such a dummy element?
> >
> > No, that is not what I proposed, just as I don't insist that *every* C
> > implementation, for *every* program, *always* itself allocate such a
> > dummy element after an array.
> >
> > > This is not a notion that will succeed.
> >
> > Are you then advocating not allowing pointers beyond an array since
> > that imposes roughly the same amount of work for implementations as
> > allowing some pointers before an array AFAICS?
>
> question,
Except that it wasn't an answer to anything I wrote but to something else.
> but I have a different objection. It seems that nobody else
> really considers your proposal to solve any problem with the current
> language. What problem are you trying to solve that can't be done
> as simply in C99? Code would be nice, but a coherent explanation in
> pseudocode would probably be fine.
I gave an example in my first post where solving the problem in C99 will
be quite messy while it there would be no problem if pointers before
arrays for small types would be allowed.
If you are only asking for a basic example of a use of a sentinel pointer
possibly pointing one position before an array, here's one:
char * stack;
...
char * a = stack + f();
...
// aEnd might point to one position before the stack array
// resulting in undefined behaviour.
for ( char * aEnd = g(); a != aEnd; a-- )
{
...
}
Daniel Vallstrom
>
> -Arthur
Daniel Vallstrom
> Daniel Vallstrom wrote:
> > Are you then advocating not allowing pointers beyond an array since
> > that imposes roughly the same amount of work for implementations as
> > allowing some pointers before an array AFAICS?
>
> No, I'm telling you that you don't understand the problem.
> In fact the C standards committee considered this issue
> long ago, and found it imposed too much of a burden on
> otherwise perfectly reasonable implementations.
Then you can't have considered allowing before-pointers for *small
types only*, which is the issue here, since that imposes only very
little burden on implementations and wouldn't affect the efficiency
of C programs.
> The only
> reason the one-past-the-end address computation was
> required to be supported universally was that we knew how
> to make it work relatively cheaply, and it was a common
> idiom that needed full support. Down-addressing was
> much rarer (for good reason!) and had already had to be
> changed in the course of porting older software, since in
> fact it did/does cause problems on many platforms.
I'm not disputing that before-pointers can very well cause problems
on some real platforms for some real implementations. I'm just noting
that it would be easy to support before-pointers for small types which
is all that is needed for almost all cases occurring in practice.
Daniel Vallstrom
Francis Glassborow
Vallstrom <Daniel.V...@safelogic.se> writes
>> Francis Glassborow has given an excellent technical answer to your
>> question,
>
>Except that it wasn't an answer to anything I wrote but to something else.
However it was an explanation of why you are completely wasting your
time. Try to use your creative energies on things that many would find
useful. Competent programmers know how to write code that does not need
a one before the start (they have to because even your proposal requires
that they do) incompetent programmers would ignore the size limitation.
Most of us find the concept of algorithms that only work for a limited
range of types anathema. They have a strong odour of premature
optimisation.
Just learn to do it properly once and use that everywhere rather than
learning to do it badly for small types and also having to learn to do
it properly for all the rest.
Now I do not often decide to ignore a thread to which I have contributed
but I intend to do so here because I have far better things to do with
my time as well as proposals for real future enhancements to the
language.
--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow ACCU
Daniel Vallstrom
> pete wrote:
> > Once you know the rules, it's very easy to write code
> > which doesn't use an (array - 1) sentinel.
> > Then, it seems like the only purpose to your proposal
> > is to legitimize old bad code.
The purpose is to legitimize a useful coding-construct that
comes natural. If as a bonus it turns existing undefined
behaviour into defined and intended behaviour I don't see
that as a bad thing.
> Exactly. The current language specification allows the
> programmer who needs such a sentinel to easily use one,
> without imposing any penalty on anybody who doesn't
> need such a sentinel.
Exactly. And for that reason before-pointers for small types
should be allowed.
Daniel Vallstrom
Goran Larsson
Daniel Vallstrom <Daniel.V...@safelogic.se> wrote:
> The purpose is to legitimize a useful coding-construct that
> comes natural. If as a bonus it turns existing undefined
> behaviour into defined and intended behaviour I don't see
> that as a bad thing.
You could just as well be writing about "i = i++;".
Pointing before an object is just as natural as "i = i++;".
--
Göran Larsson http://www.mitt-eget.com/
Mark McIntyre
Daniel.V...@safelogic.se (Daniel Vallstrom) wrote:
>"Douglas A. Gwyn" <DAG...@null.net> wrote in message news:<3ED7976D...@null.net>...
>> pete wrote:
>> > Once you know the rules, it's very easy to write code
>> > which doesn't use an (array - 1) sentinel.
>> > Then, it seems like the only purpose to your proposal
>> > is to legitimize old bad code.
>
>The purpose is to legitimize a useful coding-construct that
>comes natural.
If, in the opinion of the C experts you've been arguing with, it did
either of those things at a reasonable cost, then believe me, you'd
have got different answers. The point is, it does not. So its a dead
subject.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
James Kuyper
...
> For example if you use stack-like structures and you need to loop through
> them top-down you will most likely have encountered this pointer-before-array
> issue. I happen upon the issue fairly often because what I do tend to need
> stacks where the order of the elements is important so that I need to loop
> through the arrays top-down but maybe that's untypical?
You can loop through the arrays backwards without using a
pointer-before-array, by simply performing the exit test on the pointer
before it is decremented, rather than after. It may be a little trickier
to do it right, than to do it your way, but it's not's terribly
difficult.
> > and I've certainly never
> > written any.
>
> That you are aware of that is;p
It's a rather bizarre and rarely used programming techique. Programmers
familiar with the restrictions on C pointers are unlikely to have used
it, and certainly aren't likely to use it by accident.
E. Robert Tisdale
> However,
> it was an explanation of why you are completely wasting your time.
> Try to use your creative energies
> on things that many would find useful.
Appeal To Widespread Belief
http://www.don-lindsay-archive.org/skeptic/arguments.html#bandwagon
> Competent programmers know how to write code
> that does not need one before the start
> (they have to because even your proposal requires that they do)
> incompetent programmers would ignore the size limitation.
> Most of us find the concept of algorithms
> that only work for a limited range of types anathema.
> They have a strong odor of premature optimization.
>
> Just learn to do it properly once and use that everywhere
> rather than learning to do it badly for small types
> and also having to learn to do it properly for all the rest.
>
> Now I do not often decide to ignore a thread to which I have contributed
> but I intend to do so here because I have far better things to do with
> my time as well as proposals for real future enhancements to the language.
Francis,
Do you actually ever write code in C?
I see that you write reviews
and that you have written at least one text book,
but have you ever actually written C code professionally?
If so, can you give us a pointer to some of your code
so that we can evaluate it for ourselves?
E. Robert Tisdale
> The purpose is to legitimize a useful coding-construct
> that comes natural. If, as a bonus,
> it turns existing undefined behavior
> into defined and intended behavior,
> I don't see that as a bad thing.
Why do you need to "legitimize" a "natural coding-construct"
if, in fact, it is portable everywhere?
There are no ANSI/ISO C89 or C 99 compilers
which will not accept your "pointer before array"
or emit code which does not behave as expected.
If there were, you may rest assured that
you would have been presented with numerous examples by now.
I don't think most C programmers realize how difficult
it is to avoid computing an "out-of-bounds" pointer
in a complicated pointer arithmetic expression.
There are certainly millions of lines of code
that depend upon out-of-bounds pointers
which would break if you attempted to port them to a platform
that would fault on out-of-bounds pointers.
Today, a new computer architecture which would fault
on out-of-bounds pointers would have an extremely short life
because it wouldn't be practical to port existing applications
onto it. It is simply cheaper, easier and wiser
to avoid such platforms than it is to try to pinpoint
and eliminate out-of-bounds pointers.
Richard Heathfield
> Daniel Vallstrom wrote:
>
>> The purpose is to legitimize a useful coding-construct
>> that comes natural. If, as a bonus,
>> it turns existing undefined behavior
>> into defined and intended behavior,
>> I don't see that as a bad thing.
>
> Why do you need to "legitimize" a "natural coding-construct"
> if, in fact, it is portable everywhere?
The Standard says the behaviour of that construct is undefined.
> There are no ANSI/ISO C89 or C 99 compilers
> which will not accept your "pointer before array"
> or emit code which does not behave as expected.
You have yet to verify this claim.
> If there were, you may rest assured that
> you would have been presented with numerous examples by now.
Why? The existence of such an architecture is entirely irrelevant to this
discussion.
>
> I don't think most C programmers realize how difficult
> it is to avoid computing an "out-of-bounds" pointer
> in a complicated pointer arithmetic expression.
Well, I can see how it might be difficult for some C programmers. Most of us
seem to manage OK, though.
> There are certainly millions of lines of code
> that depend upon out-of-bounds pointers
Please provide evidence to support that assertion. Lines of code written by
you personally, or by code generators written by you, are specifically
excluded.
> which would break if you attempted to port them to a platform
> that would fault on out-of-bounds pointers.
> Today, a new computer architecture which would fault
> on out-of-bounds pointers would have an extremely short life
> because it wouldn't be practical to port existing applications
> onto it.
Sure it would, if they were written properly.
> It is simply cheaper, easier and wiser
> to avoid such platforms than it is to try to pinpoint
> and eliminate out-of-bounds pointers.
You don't get to choose what other people use.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
E. Robert Tisdale
> E. Robert Tisdale wrote:
>
>>Why do you need to "legitimize" a "natural coding-construct"
>>if, in fact, it is portable everywhere?
>
> The Standard says the behavior of that construct is undefined.
Thump, thump, thump.
>>There are no ANSI/ISO C89 or C 99 compilers
>>which will not accept your "pointer before array"
>>or emit code which does not behave as expected.
>
> You have yet to verify this claim.
It would be much easier to disprove
if, in fact, there were one.
>>If there were, you may rest assured that
>>you would have been presented with numerous examples by now.
>
> Why? The existence of such an architecture
> is entirely irrelevant to this discussion.
Then, I suppose, you're willing to concede
that no such architecture exists.
>>I don't think most C programmers realize how difficult
>>it is to avoid computing an "out-of-bounds" pointer
>>in a complicated pointer arithmetic expression.
>
> Well, I can see how it might be difficult for some C programmers.
> Most of us seem to manage OK, though.
Have you tried to compile with Comeau's C compiler?
http://www.comeaucomputing.com/
I believe that it may have options
to trap at least some out-of-bounds pointers.
>>There are certainly millions of lines of code
>>that depend upon out-of-bounds pointers
>
> Please provide evidence to support that assertion.
> Lines of code written by you personally,
> or by code generators written by you, are specifically excluded.
I used to cite f2c
in response to this question but the authors
have since succumbed to your superstitious beliefs.
There are still millions of lines of code translated
by earlier version of f2c and maintained manually as C code.
Older versions of Numerical Recipes in C
still use array pointers offset by -1.
Douglas A. Gwyn
> There are no ANSI/ISO C89 or C 99 compilers
> which will not accept your "pointer before array"
> or emit code which does not behave as expected.
Wrong.
Douglas A. Gwyn
> Older versions of Numerical Recipes in C
> still use array pointers offset by -1.
And I criticized that as soon as I got my hands on a copy.
The reason the authors did that (according to their own
explanation) was that they were so accustomed to Fortran's
array indexing starting with 1 and so new to C that they
felt the need to pretend the Fortran convention for their
C code. But since C is not Fortran that was a big mistake,
and in fact the code they provided did not work on many
platforms due to this error.
Keith Thompson
Do you have examples of such platforms? (Unlike Mr. Tisdale, I
believe the answer is yes; I'm just curious about the details.)
Joona I Palaste
on comp.lang.c:
> Why do you need to "legitimize" a "natural coding-construct"
> if, in fact, it is portable everywhere?
> There are no ANSI/ISO C89 or C 99 compilers
> which will not accept your "pointer before array"
> or emit code which does not behave as expected.
> If there were, you may rest assured that
> you would have been presented with numerous examples by now.
E., it might come as a shock to you, but the fact that *YOU* haven't
seen any does not directly imply none exist.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I am looking for myself. Have you seen me somewhere?"
- Anon
Christian Bau
Joona I Palaste <pal...@cc.helsinki.fi> wrote:
> E. Robert Tisdale <E.Robert...@jpl.nasa.gov> scribbled the following
> on comp.lang.c:
> > Why do you need to "legitimize" a "natural coding-construct"
> > if, in fact, it is portable everywhere?
>
> > There are no ANSI/ISO C89 or C 99 compilers
> > which will not accept your "pointer before array"
> > or emit code which does not behave as expected.
> > If there were, you may rest assured that
> > you would have been presented with numerous examples by now.
>
> E., it might come as a shock to you, but the fact that *YOU* haven't
> seen any does not directly imply none exist.
1. I would bet that on any compiler where according to Tisdale "pointer
before an array works", I can create code where
<sometype> array [1];
void* p = &array [-1];
will set p to a null pointer. From then on you can expect things to go
seriously wrong.
2. I would bet that on any compiler where according to Tisdale "pointer
before an array works", I can create code where
<sometype> array [1];
void* p = &array [-1];
void* q = &array [0];
if (p >= q) printf ("That will teach you, Tisdale!\n");
will execute the printf statement. Not that it will teach Tisdale
anything :-(
Francis Glassborow
<E.Robert...@jpl.nasa.gov> writes
>Francis,
>
>Do you actually ever write code in C?
>I see that you write reviews
>and that you have written at least one text book,
Actually I am only in the process of doing so.
>but have you ever actually written C code professionally?
>If so, can you give us a pointer to some of your code
>so that we can evaluate it for ourselves?
As for many others, code I write professionally is not mine to reveal or
distribute.
James Kuyper
,,,
> Francis,
>
> Do you actually ever write code in C?
> I see that you write reviews
> and that you have written at least one text book,
> but have you ever actually written C code professionally?
Nothing he said justifies you calling his professional credentials into
question.
Arthur J. O'Dwyer
On Sun, 1 Jun 2003, Daniel Vallstrom wrote:
>
> "Arthur J. O'Dwyer" wrote...
> > On Thu, 29 May 2003, Daniel Vallstrom wrote:
> > >
> > > Are you then advocating not allowing pointers beyond an array since
> > > that imposes roughly the same amount of work for implementations as
> > > allowing some pointers before an array AFAICS?
> >
> > Francis Glassborow has given an excellent technical answer to your
> > question,
>
> Except that it wasn't an answer to anything I wrote but to something else.
It was a very cogent explanation of why current computer architectures do
not permit the implementation of your idea without much extra work on the
part of the compiler vendor; and an observation that compiler vendors, on
the whole, don't like writing extra code when the fix on the user's end
is trivial.
> > but I have a different objection. It seems that nobody else
> > really considers your proposal to solve any problem with the current
> > language. What problem are you trying to solve that can't be done
> > as simply in C99? Code would be nice, but a coherent explanation in
> > pseudocode would probably be fine.
>
> I gave an example in my first post where solving the problem in C99 will
> be quite messy while it there would be no problem if pointers before
> arrays for small types would be allowed.
No, you didn't. You merely alluded to a "problem" without giving any
indication of (a) what the problem was; (b) how you tried to solve it; (c)
how exactly your proposal would simplify the solution; or (d) why you were
trying to solve the problem that way to begin with. I guess I want you
to post some real code after all. (And the stuff below don't count.)
> If you are only asking for a basic example of a use of a sentinel pointer
> possibly pointing one position before an array, here's one:
I'm asking for an example of such code where the intent is obvious and the
equivalent C99 code is non-trivial.
> char * stack;
ptrdiff_t f(void);
char * g(void);
> ...
> char * a = stack + f();
> ...
>
> // aEnd might point to one position before the stack array
> // resulting in undefined behaviour.
That depends on what function 'g' returns, doesn't it now? As long
as 'g' returns something sensible, this won't be a problem. (Under
current C99 rules, 'g' *can't* return what you say it returns, BTW.)
> for ( char * aEnd = g(); a != aEnd; a-- )
> {
> ...
> }
Is something wrong with
char *last_one = g_plus_one();
char *a = stack + f_plus_one();
do
{
--a;
...
} while (a != last_one);
or (probably the most idiomatic)
int idx = f();
while (idx >= 0) {
.. do something with stack[idx]
--idx;
}
-Arthur
Alan Balmer
Vallstrom) wrote:
>Alan Balmer <alba...@att.net> wrote in message news:<4vsedvohu0hcob5ua...@4ax.com>...
>> On 29 May 2003 17:17:44 -0700, Daniel.V...@safelogic.se (Daniel
>> Vallstrom) wrote:
>>
>> >you also have to
>> >weight in all the code that would go from undefined behavior
>> >to defined and intended behavior by allowing pointers before
>> >arrays.
>>
>> I don't recall ever seeing any such code,
>
>For example if you use stack-like structures and you need to loop through
>them top-down you will most likely have encountered this pointer-before-array
>issue. I happen upon the issue fairly often because what I do tend to need
>stacks where the order of the elements is important so that I need to loop
>through the arrays top-down but maybe that's untypical?
There are as many definitions of "typical" as there are programmers,
I'm sure. However, the situation you describe can be handled without
using "pointer-before-array" techniques.
>
>> and I've certainly never
>> written any.
>
>That you are aware of that is;p
I rarely program when not at least partially aware of what I'm doing
;-) I will admit that there have been times when on inspecting the
code another day, I've thought I must have been asleep, but none of
those occasions involved pointers before arrays or other structures.
>
>> I don't think changing the standard is a good way to fix
>> broken code.
>
>You get fixes to broken code as a *bonus*. It's not the primary reason for
>allowing pointers before arrays for small types.
I was responding to your "you also have to weigh in" remark, above. I
consider this an entirely bogus factor, not one to be weighed in.
>
>
>Daniel Vallstrom
Alan Balmer
<E.Robert...@jpl.nasa.gov> wrote:
>I don't think most C programmers realize how difficult
>it is to avoid computing an "out-of-bounds" pointer
>in a complicated pointer arithmetic expression.
Hmmm... I can accept the idea that some programmers might find this
difficult, but that leads me to a conclusion much different than
yours.
James Kuyper
...
> I don't think most C programmers realize how difficult
> it is to avoid computing an "out-of-bounds" pointer
> in a complicated pointer arithmetic expression.
I'll agree that it's difficult to avoid the one-past-the-end case, which
is precisely why it's been officially blessed by the standard. However,
I think that most C programmers have a fairly good idea of how difficult
it is to avoid the other cases: "not very". Would you care to present an
example of code which would be difficult to write in such a way as to
avoid those other cases? The one-before-the-beginning sentinel example
is trivial to re-write to avoid the fact that it currently has undefined
behavior.
Barry Margolin
Alan Balmer <alba...@spamcop.net> wrote:
>On Sun, 01 Jun 2003 16:25:35 -0700, "E. Robert Tisdale"
><E.Robert...@jpl.nasa.gov> wrote:
>
>>I don't think most C programmers realize how difficult
>>it is to avoid computing an "out-of-bounds" pointer
>>in a complicated pointer arithmetic expression.
>
>Hmmm... I can accept the idea that some programmers might find this
>difficult, but that leads me to a conclusion much different than
>yours.
Ideally, it would be nice to think that if we raise the bar, we'll weed out
the less competent programmers. Unfortunately, history isn't consistent
with that expectation.
--
Barry Margolin, barry.m...@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
E. Robert Tisdale
> As for many others, code that I write professionally
> is not mine to reveal or distribute.
Exactly how much code have you written professionally?
E. Robert Tisdale
> Nothing he said justifies
> you calling his professional credentials into question.
Nothing he said justifies
assuming that he has any professional credentials.
Arthur J. O'Dwyer
_______________
/| /| | |
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
/ \ \|_______________|
/ _ \ \ ||
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | _||
/ / \ |____| ||
/ | | | --|
| | | |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ | ||
/ _ \\ | / `
* / \_ /- | | |
* ___ c_c_c_C/ \C_c_c_c____________
Richard Heathfield
> In message <3EDA80CD...@jpl.nasa.gov>, E. Robert Tisdale
> <E.Robert...@jpl.nasa.gov> writes
>>Francis,
>>
>>Do you actually ever write code in C?
>>I see that you write reviews
>>and that you have written at least one text book,
>
> Actually I am only in the process of doing so.
<grin width="evil">
Do you need it reviewed?
</grin>
Mr Tisdale chooses to indulge in ad hominem attacks instead of technical
issues. This is hardly surprising, given the hopelessness of his position,
but it still leaves a nasty taste in the mouth. And I note that he has yet
to provide any evidence of his own technical competence (although he
appears to have provided plenty of counter-evidence).
E. Robert Tisdale
> It was a very cogent explanation
> of why current computer architectures do not permit
> the implementation of your idea without much extra work
> on the part of the compiler vendor;
> and an observation that compiler vendors, on the whole,
> don't like writing extra code
> when the fix on the user's end is trivial.
This is plainly silly.
There are no viable C compilers aspiring to comply
with the ANSI/ISO C 89 and C 99 standards
that will write not emit code which computes pointers
to an [virtual] machine address.
There are no computer architectures
which support ANSI/ISO C 89 or C 99 compilers
that will fault on an "out-of-bounds" pointer.
Daniel Vallstrom's pointer before array proposal
is already implemented by default.
There is no "extra work"
on the part of the compiler developer.
Dave Hansen
<E.Robert...@jpl.nasa.gov> wrote:
[...]
>
>This is plainly silly.
>
[... Silly stuff snipped ...]
You're right. It was silly. Thanks for the warning.
Regards,
-=Dave
--
Change is inevitable, progress is not.
Christian Bau
"E. Robert Tisdale" <E.Robert...@jpl.nasa.gov> wrote:
Much that you have said justifies assuming that you have no professional
credentials.
Mark McIntyre
<francis.g...@ntlworld.com> wrote:
>In message <3EDA80CD...@jpl.nasa.gov>, E. Robert Tisdale
><E.Robert...@jpl.nasa.gov> writes
>>Francis,
>>
>>Do you actually ever write code in C?
>>I see that you write reviews
>>and that you have written at least one text book,
>
>Actually I am only in the process of doing so.
but you have written innumerable magazine articles, as well as
participating in various ISO committees I believe...
>>but have you ever actually written C code professionally?
>>If so, can you give us a pointer to some of your code
>>so that we can evaluate it for ourselves?
>
>As for many others, code I write professionally is not mine to reveal or
>distribute.
Sad but true.
James Kuyper
Experience and competence are imperfectly correllated. Tisdale might
actual have more experience than one might expect from reading his
comments.
CBFalconer
Does anybody have any information on whether this DT really has
any connection with NASA? Even if it is cleaning filters, it
would remain a DT. If there is no real connection we can all
PLONK and be done. We have few enough shuttles remaining to allow
such a clod to remain within any vicinity of the systems.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer
>
> Christian Bau wrote:
> > "E. Robert Tisdale" <E.Robert...@jpl.nasa.gov> wrote:
> > > James Kuyper wrote:
> > >
> > > > Nothing he said justifies
> > > > you calling his professional credentials into question.
> > >
> > > Nothing he said justifies
> > > assuming that he has any professional credentials.
> >
> > Much that you have said justifies assuming that you have no
> > professional credentials.
>
> Experience and competence are imperfectly correllated. Tisdale
> might actual have more experience than one might expect from
> reading his comments.
Yes, but at what? I don't want to eat from any dishes he has
washed, especially considering his deep disdain for standards. I
am refraining from cruder possibilities.
Jun Woong
> James Kuyper wrote:
> >
> > Christian Bau wrote:
> > > "E. Robert Tisdale" <E.Robert...@jpl.nasa.gov> wrote:
> > > > James Kuyper wrote:
> > > >
> > > > > Nothing he said justifies
> > > > > you calling his professional credentials into question.
> > > >
> > > > Nothing he said justifies
> > > > assuming that he has any professional credentials.
> > >
> > > Much that you have said justifies assuming that you have no
> > > professional credentials.
> >
> > Experience and competence are imperfectly correllated. Tisdale
> > might actual have more experience than one might expect from
> > reading his comments.
>
> Yes, but at what? I don't want to eat from any dishes he has
> washed, especially considering his deep disdain for standards. I
> am refraining from cruder possibilities.
>
It can be good mentally to just ignore him. From reading the whole
thread, I've never seen any technical evidence he brings to support
his position, except for listing groundless facts or poor examples
and appealing to sympathy. I bet his illogical claim (actually which
is another superstitious belief) never gets assent.
--
Jun, Woong (myco...@hanmail.net)
Dept. of Physics, Univ. of Seoul
Christian Bau
James Kuyper <kuy...@saicmodis.com> wrote:
Experience maybe. A C programmer who writes programs that invoke
undefined behavior without any good reason to do so, and who insists
that this is correct, is not professional.
Dan Pop
>"E. Robert Tisdale" wrote:
>...
>> I don't think most C programmers realize how difficult
>> it is to avoid computing an "out-of-bounds" pointer
>> in a complicated pointer arithmetic expression.
>
>I'll agree that it's difficult to avoid the one-past-the-end case, which
>is precisely why it's been officially blessed by the standard.
On the contrary, it is trivial to avoid it. It's been officially blessed
by the standard because it was common practice to code that way and
because the burden imposed on the implementor is insignificant.
See the C89 Rationale for a full discussion.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
pete
>
> On Sun, 01 Jun 2003 16:25:35 -0700, "E. Robert Tisdale"
> <E.Robert...@jpl.nasa.gov> wrote:
>
> >I don't think most C programmers realize how difficult
> >it is to avoid computing an "out-of-bounds" pointer
> >in a complicated pointer arithmetic expression.
>
> Hmmm... I can accept the idea that some programmers might find this
> difficult, but that leads me to a conclusion much different than
> yours.
Hmmm... I can accept the idea that most C programmers don't
realize how difficult it is to avoid computing an
"out-of-bounds" pointer in a complicated pointer arithmetic
expression.
I don't realize how difficult it is.
Nobody on the standard committee is ever going to realize
how difficult it is.
I think there's a conclusion there.
--
pete
Francis Glassborow
writes
>Hmmm... I can accept the idea that most C programmers don't
>realize how difficult it is to avoid computing an
>"out-of-bounds" pointer in a complicated pointer arithmetic
>expression.
'Doctor it hurts when I do this.'
' Then do not do that.'
Sorry, but there is something fundamentally wrong with code that can
result in an out of bounds pointer. Fixing the language to say that it
is OK as long as you do not use the result just condones bad
programming.
Please note that the proposal that started this thread actually proposes
no guarantees for types in general, it just wants to special case the
fundamental types.
Why should we work out a way to allow a special case when it is clearly
not possible to provide a general solution.
Note that under the proposal line A in the following is OK but line B &
C would still exhibit undefined behaviour. IOWs if it were really
desirable then the proposal does not fix it.
#include <stdio.h>
char array[1][100];
struct {
char array[1000];
} x;
int main(){
printf("%p\n", array[0] -1); /* A */
printf("%p\n", array - 1); /* B */
printf("%p\n", &x - 1); /* C */
return 0;
Michael Wojcik
> "E. Robert Tisdale" wrote:
>> Do you actually ever write code in C? I see that you write reviews
>> and that you have written at least one text book, but have you ever
>> actually written C code professionally?
>
> Nothing he said justifies you calling his professional credentials
> into question.
True, but the same can't be said for ERT himself. I'm curious on that
account, I have to admit. And I'm glad I don't personally have to rely
on the correct behavior of any C code produced by JPL, at least AFAIK.
(He's no good with rhetoric, either. Francis' comment "it was an
explanation of why you are wasting your time" isn't argumentum ad
populum, Robert. Try again.)
--
Michael Wojcik
Micro Focus International
Arthur J. O'Dwyer
On Tue, 3 Jun 2003, CBFalconer wrote:
>
> "E. Robert Tisdale" wrote:
> Does anybody have any information on whether this DT really has
> any connection with NASA? Even if it is cleaning filters, it
> would remain a DT. If there is no real connection we can all
> PLONK and be done. We have few enough shuttles remaining to allow
> such a clod to remain within any vicinity of the systems.
Yes, duh. Edwin Robert "Bob" Tisdale does appear to work at JPL, doing
some sort of research with Common Component Architectures (whatever
they are). His web page (last updated sometime in 2002?) is even hosted
by a site run out of Los Angeles. As far as I can tell, he has no
connection to the Bob Tisdale who teaches English (I think) at Carleton
College in Minnesota.
Now please stop harping on his NASA connections. We none of us like
incompetence in C programming, but what can one do? Just refute his
points and don't buy his products. ;)
-Arthur
[Disclosure: Anyone is welcome to do a Google search on me, too.
I don't know why CBFalconer didn't do his own.]
Dan Pop
>James Kuyper wrote:
> > "E. Robert Tisdale" wrote:
> >> Do you actually ever write code in C? I see that you write reviews
> >> and that you have written at least one text book, but have you ever
> >> actually written C code professionally?
> >
> > Nothing he said justifies you calling his professional credentials
> > into question.
>
>True, but the same can't be said for ERT himself. I'm curious on that
>account, I have to admit. And I'm glad I don't personally have to rely
>on the correct behavior of any C code produced by JPL, at least AFAIK.
Wait until one of their rockets falls on your house, due to an engine
failure... ;-)
Dan Pop
>Now please stop harping on his NASA connections. We none of us like
>incompetence in C programming, but what can one do? Just refute his
>points and don't buy his products. ;)
Even if you don't buy them, they may still fall on your head/house/car :-)
Looking back, most of the biggest NASA's failures have been caused
by sloppy engineering issues (Apollo 1, both crashed shuttles). It seems
to be a trend and our guy is definitely following it.
Mark McIntyre
O'Dwyer" <a...@andrew.cmu.edu> wrote:
>[Disclosure: Anyone is welcome to do a Google search on me, too.
>I don't know why CBFalconer didn't do his own.]
OK, are you the guy who wrote lots of TI83 stuff? And the robot league
team member? :-)
Mark Gordon
Barry Margolin <barry.m...@level3.com> wrote:
> In article <3ED63952...@yahoo.com>,
> CBFalconer <cbfal...@worldnet.att.net> wrote:
> >Many systems arrange their data space starting at zero, with a
> >non-assigned page at the beginning. This allows simple trapping
> >of a NULL dereference, or of any pointer value that is below the
> >size of a page. It also allows a simple method of uncovering most
> >invalid pointers even before they have been dereferenced. Please
> >explain how such a system can reserve any space before the first
> >item in the data area. Or do you consider an X86 based machine a
> >"*very uncommon* platform"? How about a 360 or 370 architecture?
>
> Locate the text segment at low memory (e.g. starting at the first page
> after that initial unassigned page), and the data segment in high
> memory. And in the case of data objects in the text segment (i.e.
> variables declared const), they could be located at the high end of
> the text segment; the low end would be reserved for code.
>
> The result of this memory layout is that no data objects would be
> adjacent to that unassigned page.
On an embedded system the text segment will frequently be held in ROM.
ICBW but I thought the reset vector on the x86 was at the top of memory,
so you need to have your ROM at the top of memory. So to do what you
suggest one would need ROM mapped in two places which is possible, but
needlessly messy.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Currently looking for a new job commutable from Slough, Berks, U.K.
Although my email address says spamtrap, it is real and I read it.
Alan Balmer
<mwo...@newsguy.com> wrote:
>
>True, but the same can't be said for ERT himself. I'm curious on that
>account, I have to admit. And I'm glad I don't personally have to rely
>on the correct behavior of any C code produced by JPL, at least AFAIK.
>
A search of NASA turns up "also contributing" references to a couple
of slide-show presentations on evaluation of parallel computing.
Since a large part of NASA's work is available to the public, perhaps
Mr. Tisdale could point us to some of his work as an "experienced,
professional C programmer."
Or perhaps he could not.
Daniel Vallstrom
> On Sun, 1 Jun 2003, Daniel Vallstrom wrote:
> >
> > "Arthur J. O'Dwyer" wrote...
> > > On Thu, 29 May 2003, Daniel Vallstrom wrote:
> > > >
> > > > Are you then advocating not allowing pointers beyond an array since
> > > > that imposes roughly the same amount of work for implementations as
> > > > allowing some pointers before an array AFAICS?
> > >
> > > Francis Glassborow has given an excellent technical answer to your
> > > question,
> >
> > Except that it wasn't an answer to anything I wrote but to something else.
>
> It was a very cogent explanation of why current computer architectures do
> not permit the implementation of your idea without much extra work on the
> part of the compiler vendor; and an observation that compiler vendors, on
> the whole, don't like writing extra code when the fix on the user's end
> is trivial.
You might want to read the posts you are replying to or quoting --- at
least after getting an explicit hint that doing so might be a good idea;p
Francis Glassborow seemed to assume that I was proposing allowing pointers
before arrays in general. You still seem to think that. I only want to
allow it for small types.
Anyway, no fix is needed at all for almost all implementations and platforms.
If a fix is needed it's close to trivial: just start handing out memory e.g.
4 or 8 bytes after the place where you would start at without the fix, in
contrast to the 1 byte that you might have to reserve at the end for
beyond-pointers.
>
> > > but I have a different objection. It seems that nobody else
> > > really considers your proposal to solve any problem with the current
> > > language. What problem are you trying to solve that can't be done
> > > as simply in C99? Code would be nice, but a coherent explanation in
> > > pseudocode would probably be fine.
> >
> > I gave an example in my first post where solving the problem in C99 will
> > be quite messy while it there would be no problem if pointers before
> > arrays for small types would be allowed.
>
> No, you didn't. You merely alluded to a "problem" without giving any
> indication of (a) what the problem was; (b) how you tried to solve it; (c)
> how exactly your proposal would simplify the solution; or (d) why you were
> trying to solve the problem that way to begin with. I guess I want you
> to post some real code after all. (And the stuff below don't count.)
I don't want to post the code for the example I was describing in my first
post because then I would have to kill you;p But examples shouldn't be
needed since before-pointers are conceptually no different from
beyond-pointers which you presumably want to allow. If you really want
to divulge into exactly how useful before/beyond-pointers are, just take
any semi-involved program using beyond-pointers and rewrite it using no
beyond-pointers and see how convenient that is. I'm a fan of having sentinel
pointers consistently pointing to one place past the last element rather than
to the last element. In my opinion and experience that produces cleaner code
and is less bug-prone.
You may believe that before-pointers shouldn't be allowed because the situation
where they are useful is not that common in practice to warrant a change of the
standard even if it costs next to nothing; or you might think that it would be
too subtle what the small types are. But that's it.
[snip]
Daniel Vallstrom
Richard Bos
> Francis Glassborow seemed to assume that I was proposing allowing pointers
> before arrays in general. You still seem to think that. I only want to
> allow it for small types.
Please define "small". Please use a definition that causes less pain all
around than just leaving this rule out.
Richard
Alan Balmer
<a...@andrew.cmu.edu> wrote:
>Now please stop harping on his NASA connections. We none of us like
>incompetence in C programming, but what can one do? Just refute his
>points and don't buy his products. ;)
Unfortunately, if he works for NASA, we in the US don't have a choice
about buying his products.
James Kuyper
...
> Francis Glassborow seemed to assume that I was proposing allowing pointers
> before arrays in general. You still seem to think that. I only want to
> allow it for small types.
Francis Glassborow said:
> Most of us find the concept of algorithms that only work for a limited
> range of types anathema. They have a strong odour of premature
> optimisation.
>
> Just learn to do it properly once and use that everywhere rather than
> learning to do it badly for small types and also having to learn to do
> it properly for all the rest.
I don't think he could possibly object the fact that you were proposing
different rules for different types, unless he was actually aware of the
fact that you were proposing different rules for different types.
...
> post because then I would have to kill you;p But examples shouldn't be
> needed since before-pointers are conceptually no different from
> beyond-pointers which you presumably want to allow. If you really want
> to divulge into exactly how useful before/beyond-pointers are, just take
> any semi-involved program using beyond-pointers and rewrite it using no
> beyond-pointers and see how convenient that is. I'm a fan of having sentinel
> pointers consistently pointing to one place past the last element rather than
> to the last element. In my opinion and experience that produces cleaner code
> and is less bug-prone.
Beyond pointers are only a minor annoyance to avoid, and before-pointers
are even easier to avoid. The assymetry is due to the fact that the way
to avoid beyond-pointers is to instead use end-pointers. The way to
avoid using before-pointers is to instead use beginning-pointers. Since
the name of an array and the value returned by malloc() are both
beginning-pointers, it's slightly easier to construct one than it is to
construct an end-pointer.
There's another assymetry, due to the fact that iterating backwards is
simply a lot less common than iterating forwards.
Arthur J. O'Dwyer
On Tue, 3 Jun 2003, Mark McIntyre wrote:
>
> On Tue, 3 Jun 2003 09:47:28 -0400 (EDT), in comp.lang.c , "Arthur J.
> O'Dwyer" <a...@andrew.cmu.edu> wrote:
>
> >[Disclosure: Anyone is welcome to do a Google search on me, too.
> >I don't know why CBFalconer didn't do his own.]
>
> OK, are you the guy who wrote lots of TI83 stuff? And the robot league
> team member? :-)
Yeah, but don't let it get around. :)
-Arthur
E. Robert Tisdale
> James Kuyper writes:
>
>>"E. Robert Tisdale" wrote:
>>
>>>I don't think most C programmers realize how difficult
>>>it is to avoid computing an "out-of-bounds" pointer
>>>in a complicated pointer arithmetic expression.
>>
>>I'll agree that it's difficult to avoid the one-past-the-end case
>>which is precisely why it's been officially blessed by the standard.
>
> On the contrary, it is trivial to avoid it.
> It's been officially blessed by the standard
> because it was common practice to code that way and
> because the burden imposed on the implementor is insignificant.
>
> See the C89 Rationale for a full discussion.
Please cite and quote the relevant passage.
If we could find just one platform
which supports and ANSI/ISO C 89 or C 99 compliant compiler
*and* faults on "out-of-range" pointers,
we try porting applications and find out
how many (what fraction of) applications
actually compute "out-of-range" pointers.
Of course, experienced, professional programmers know
that porting actual application programs
is a messy, expensive and time consuming task ;-)
Richard Heathfield
<snip>
>
> Note that under the proposal line A in the following is OK but line B &
> C would still exhibit undefined behaviour. IOWs if it were really
> desirable then the proposal does not fix it.
>
> #include <stdio.h>
>
> char array[1][100];
>
> struct {
> char array[1000];
> } x;
>
>
> int main(){
> printf("%p\n", array[0] -1); /* A */
Um, ITYM:
printf("%p\n", (void *)(array[0] -1)); /* A */
<snip>
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Keith Thompson
> Dan Pop wrote:
[...]
> > On the contrary, it is trivial to avoid it.
> > It's been officially blessed by the standard
> > because it was common practice to code that way and
> > because the burden imposed on the implementor is insignificant.
> > See the C89 Rationale for a full discussion.
>
> Please cite and quote the relevant passage.
Section 3.3.6, "Additive operators", page 46:
An important endorsement of widespread practice is the requirement
that a pointer can always be incremented to just past the end of
an array, with no fear of overflow or wraparound:
SOMETYPE array[SPAN];
/* ... */
for (p = &array[0]; p ! &array[SPAN]; p++)
This stipulation merely requires that every object be followed
by one byte whose address is representable. That byte can be the
first byte of the next object declared for all but the last object
located in a contiguous segment of memory. (In the example, the
address &array[SPAN] must address a byte following the highest
element of array.) Since the pointer expression p+1 need not
(and should not) be dereferenced, it is unnecessary to leave
room for a complete object of size sizeof(*p). In the case
of p on the other hand, an entire object would have to be
allocated prior to the array of objects that p traverses, so
decrement loops that run off the bottom of an array may fail.
This restriction allows segmented architectures, for instance,
to place objects at the start of a range of addressable memory.
> If we could find just one platform which supports and ANSI/ISO C 89
> or C 99 compliant compiler *and* faults on "out-of-range" pointers,
> we try porting applications and find out how many (what fraction of)
> applications actually compute "out-of-range" pointers.
The answer is either "none" or "too many".
> Of course, experienced, professional programmers know that porting
> actual application programs is a messy, expensive and time consuming
> task ;-)
They know it, but they're not happy about it. They also know that
standards are intended to make the whole thing easier.
--
Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Douglas A. Gwyn
> Do you have examples of such platforms?
The canonical one is PDP-11 Unix. The [-1] element
of an array with moderately large element has an
address that compares *greater* than that of the [0]
element, due to address wrap-around. The same
happens on platforms like the x86 where addresses
are segment-relative; the segment (rather than the
whole address space) wraps around.
Francis Glassborow
<DAG...@null.net> writes
But there is also a problem on various platforms that do not allow an
address register to be loaded with an address that is not 'owned' by the
process. On those trying to address before the start of a dynamically
assigned block of memory causes a segment violation fault. Certainly
Windows NT 4 traps such addresses in some if not all modes of operation.
Furthermore, IMO, such behaviour is correct in any environment which is
security conscious. We really cannot require that out of range addresses
be acceptable in any sense where software needs to be robust against
cracking attempts.
pete
Regarding loops which increment or decrement pointers along
the entire length of arrays:
It's much more natural to avoid the one before,
than it is to avoid the one after.
I think it's common to get the end of an array from something like:
end = array + nmemb;
The loop that then follows naturally is:
ptr = end;
while (ptr != array) {
--ptr;
foo(ptr); /* do stuff with ptr */
}
If one after were to be forbidden and I were working my way up,
then the simplest way that I can think of is:
ptr = array;
if (nmemb) {
end = array + nmemb - 1;
foo(ptr); /* do stuff with ptr */
while (ptr != end) {
++ptr;
foo(ptr); /* do stuff with ptr */
}
}
--
pete
pete
If one after were to be forbidden,
then the above statement would have to be rewritten
end = nmemb - 1 + array;
> foo(ptr); /* do stuff with ptr */
> while (ptr != end) {
> ++ptr;
> foo(ptr); /* do stuff with ptr */
> }
> }
>
> --
> pete
--
pete
Christian Bau
pete <pfi...@mindspring.com> wrote:
> Regarding loops which increment or decrement pointers along
> the entire length of arrays:
> It's much more natural to avoid the one before,
> than it is to avoid the one after.
Just think what happens if you use an index of type unsigned int. For
example you want i to run through all the values 0 <= i < n. Going
upwards this is easy:
for (i = 0; i < n; ++i) ...
Going down:
for (i = n-1; i >= 0; --i) ...
and you are in deep trouble! Very similar to the situation with
pointers.