Christopher Eltschka wrote:
> Indeed, I think that it would have been cleaner to separate the
> "pointing pointer" from the "iterating pointer", with an implicit
> conversion ip->pp, but not the other way round. The only way (except
> for a cast) to get an iterating pointer would be to have an array.
>
> Of course, this would not have been possible in C++ due to C
> compatibility.

    Now that we have iterators, perhaps "pointer arithmetic"
should be limited to iterators.  Arithmetic on iterators is
well-defined and checkable; there are STL implementations that
do in fact check.  This is because an iterator is logically
bound to both a collection and an element of the collection.
(In STL implementations that check, iterators actually do
contain two pointers.)

    I realize this restriction would be painful.  So
I'd propose two backwards-compatible features:

   1.   This, and other related restrictions, only apply
 in "strict mode" (think "use strict" in Perl.)
   2.   As a special case, pointer arithmetic on const
 pointers to objects that don't contain pointers
 might be allowed.  This allows the widely used
 "const char*" idiom, and keeps "printf" working.
 But you can only reference bad data this way,
 not store into it.  Pointer bugs thus have only
 local effects.  Yes, it breaks "sprintf", but
 it's probably time to do that and end the
 buffer overflows.

     John Nagle
     Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

John Nagle <nagle@animats.com> writes:

> Christopher Eltschka wrote:
> > Indeed, I think that it would have been cleaner to separate the
> > "pointing pointer" from the "iterating pointer", with an implicit
> > conversion ip->pp, but not the other way round. The only way (except
> > for a cast) to get an iterating pointer would be to have an array.
> >
> > Of course, this would not have been possible in C++ due to C
> > compatibility.
>
>     Now that we have iterators, perhaps "pointer arithmetic"
> should be limited to iterators.  Arithmetic on iterators is
> well-defined and checkable; there are STL implementations that
> do in fact check.  This is because an iterator is logically
> bound to both a collection and an element of the collection.
> (In STL implementations that check, iterators actually do
> contain two pointers.)
>
>     I realize this restriction would be painful.  So
> I'd propose two backwards-compatible features:
>
>    1.   This, and other related restrictions, only apply
>  in "strict mode" (think "use strict" in Perl.)

I actually like the idea of a strict mode.
This would allow certain C incompatibilities (restrictions)
without the danger of breaking old code.

One possibility would be to have a standard header <strict> which
enables strict mode. A compiler would then be free to either have some
implementation specific stuff in it (say "#pragma strict", or
"#pragma add-compiler-flags --strict", or maybe s.th. like
"__set_compiler_flag(__strict, true)"), or alternatively handle the
#include <strict> itself specially.

Some things I would like to have in strict mode:

- No implicit conversion bool -> int
- No implicit conversion floating point -> integral
- No delete on incomplete types (instead of undefined behaviour)
- C-style and constructor style casts restricted not to do
  reinterpret_cast
- No implicit conversion of string literals to char* (i.e. without
  const)

>    2.   As a special case, pointer arithmetic on const
>  pointers to objects that don't contain pointers
>  might be allowed.  This allows the widely used
>  "const char*" idiom, and keeps "printf" working.
>  But you can only reference bad data this way,
>  not store into it.  Pointer bugs thus have only
>  local effects.  Yes, it breaks "sprintf", but
>  it's probably time to do that and end the
>  buffer overflows.

If sprintf (i.e. the function body) is compiled in non-strict mode, it
is not affected by this, even if called from strict mode code.

BTW, if already special casing, why not making the special case just
for the char types (char, signed char, unsigned char, wchar_t)?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]