You might want to take a look at Cyclone: http://www.research.att.com/projects/cyclone/

It attempts to create a safe C, and adds some other features as well.

In article <CFN374644754512384@news.digitalmars.com>, Pavel Minayev says...
>It is definitely not safe. But as long as you stick with references and dynamic arrays, you don't even have to remember about this problem.

>... It is a dangerous feature, indeed, but it is quite possible - and not very hard, in fact - to use it properly. At least easier than inline assembler.

>...This would also assume that any program which has parts written in assembler
>should not be trusted, nor can you trust OS API calls (because they could
>use pointer arithmetic), nor drivers etc etc.

I don't know much about the question about balance between power and safety, and it probably seems awfully presumptuous of me to try to influence language design.  I just think that if mistakes can be made, they will be.  It's the guys who write my word processor, the guys who write all my security loopholes, the guys who write my operating systems, etc., that I'm worried about.  Although they're getting better, a lot of API calls and drivers are actually not very reliable.  It would be very nice if D were to become the next preferred language, and would eliminate memory errors forever.  It seems to close.  Inline assembler will not be used very much.  But if pointer arithmetic is easy, it will be commonly used, and mistakes will be made.  Are you sure that there isn't a safe and effective way to avoid pointer arithmetic?

Thanks, Adam Connor, for the pointer to Cyclone.

"Rex Couture" <Rex_member@pathlink.com> wrote in message news:ai45k0$ffo$1@digitaldaemon.com...
>
> a safe and effective way to avoid pointer arithmetic?
>
> Thanks, Adam Connor, for the pointer to Cyclone.
>
>

Use dynamic arrays.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

On Mon, 29 Jul 2002 19:38:40 +0000 (UTC) Rex Couture <Rex_member@pathlink.com> wrote:

> design.  I just think that if mistakes can be made, they will be.  It's the
guys

Not sure if this is the right approach. I think it is better to state that "if language requires using dangerous techniques, mistakes will be made". C does (printf and all). D doesn't. All the code I've written in vanilla D (no ports etc) so far does not use pointers at all simply because they are not needed for my tasks. Why would anybody use pointers and PA while there are better, simpler replacements provided by the language - dynamic arrays, references, out parameters... I would only use a pointer where I need to - and just in case I need them, I want them to be there.

> who write my word processor, the guys who write all my security loopholes, the guys who write my operating systems, etc., that I'm worried about.  Although

Well I doubt you can write an OS in a completely typesafe language. You'll
simply have to mess with the hardware and other low-level stuff too much
for this to work. You'll get down to asm anyhow, which is far from being safe.

> assembler will not be used very much.  But if pointer arithmetic is easy, it will be commonly used, and mistakes will be made.  Are you sure that there
isn't

I don't understand why somebody would use PA "just because it is there". This is not a criteria. After all, if somebody writes a program in such a manner, well, we have free market, right? So you can always find someone who doesn't abuse dangerous language features just for the sake of it.

> a safe and effective way to avoid pointer arithmetic?

Yes. Just don't use it. =)
Alternatively, something like Cyclone's "fat pointers" could be made. But
they are simply TOO fat, IMHO - making a check every time one subscripts
a pointer!

> Thanks, Adam Connor, for the pointer to Cyclone.

By the way, after taking a look at Cyclone, I've made a decision that it is The Language I Would Never Ever Use. Nah, I'll beter stick to Delphi and C++ for now, and wait for D to grow mature.

..BTW, Walter, any plans on the next alpha (beta?) release?

In article <ai45k0$ffo$1@digitaldaemon.com>, Rex Couture says...
>
>I don't know much about the question about balance between power and safety, and it probably seems awfully presumptuous of me to try to influence language design.  I just think that if mistakes can be made, they will be.  It's the guys who write my word processor, the guys who write all my security loopholes, the guys who write my operating systems, etc., that I'm worried about.  Although they're getting better, a lot of API calls and drivers are actually not very reliable.  It would be very nice if D were to become the next preferred language, and would eliminate memory errors forever.  It seems to close.  Inline assembler will not be used very much.  But if pointer arithmetic is easy, it will be commonly used, and mistakes will be made.  Are you sure that there isn't a safe and effective way to avoid pointer arithmetic?

One of the things I'm very excited about is that D includes enough language features (dynamic arrays, in particular), that pointers are no longer necessary for the vast majority of programs.

I fully expect that, in the future, D compilers will come with compiler switches to turn on/turn off pointer arithmetic.  In fact, I believe that in most cases, POINTER ARITHMETIC OFF will be the DEFAULT OPTION.

For those who still need it (systems programmers, perhaps some very performance-sensitive game programmers), it will be there, but very few people will ever use it.

In article <CFN374670355875694@news.digitalmars.com>, Pavel Minayev says...

>...  All the code I've written in vanilla D
>(no ports etc) so far does not use pointers at all simply because they are
>not needed for my tasks. Why would anybody use pointers and PA while there
>are better, simpler replacements provided by the language - dynamic arrays,
>references, out parameters... I would only use a pointer where I need to -
>and just in case I need them, I want them to be there.


It sounds * very * encouraging that you have never needed pointers or pointer arithmetic except for porting.

Here's my vision:  D becomes a language of choice, maybe the language of choice. Millions of lines of code later, and there are no more memory errors.  With luck, crashes could be a thing of the past.

Please allow me one last impudent suggestion.  If it's dangerous and not needed except for comptibility (or maybe for some rare, unforseen circumstance), why not forbid pointer arithmetic by default?  It could be allowed with a switch for compatibility.

I see Russ Lewis has just posted that suggestion too.  I think it's a great idea.  Otherwise, a lot of people will probably use old ways out of habit.

I'm also a little concerned that subscript range checking is always turned off in the final compilation, whether this is really needed or not.  I certainly am capable of leaving undetected subscript range errors in my programs.



>Well I doubt you can write an OS in a completely typesafe language....You'll get down to asm anyhow, which is far from being safe.

I believe the Oberon OS's and compilers were written entirely in the Oberon language.  Assembly language was used to write part of the compiler, and the compiler was then completely rewritten in its own language.  I don't know much about this, but it certainly sounds like a safe way of operating.  I'm not certain whether there might be some low-level, relatively unsafe language.

P.S.  Thanks to all about being good sports and letting me invade your discussion group like this and continue to press these questions.  Walter, sorry to make all these suggestions and not be able to help with coding.

"Rex Couture" <Rex_member@pathlink.com> wrote in message news:ai4ege$pin$1@digitaldaemon.com...

> Please allow me one last impudent suggestion.  If it's dangerous and not
needed
> except for comptibility (or maybe for some rare, unforseen circumstance),
why
> not forbid pointer arithmetic by default?  It could be allowed with a
switch for
> compatibility.

   After all, what are pointers good for?

1- Referencing polymorphic classes.
2- Referencing elements of an array.
3- Converting raw memory into typed memory. Usually used for OS and such
type stuff.
4- Converting memory from one type of object to another.

   Did I forget any?

1- D automatically uses mutable references for polymorphic objects. Not an
issue in D.
2- Could become a "safe" pointer, like an iterator... Or could just use
indices. Not needed in D.
3- This is just a cast. It doesn't need arithmetic, as long as raw memory is
just represented by an integer.
4- Usually a nasty hack. Not desirable. And #3 allows this if we add
conversion from typed to raw memory.

   The end result is that the only case really needed in D is number 3. And
all of it can be done easily by using integers for addresses, and converting
to/from typed pointers, so pointer arithmetic is definitely not needed. I'll
bet that's how the Oberon compilers and OSs and such do it this way, too. If
you just make the conversion functions nasty enough (like the C++ casts)
that they'll be used only when needed, you'll have the best of all worlds.

   Completely eliminating the possibility of dealing with raw memory makes
system programming impossible. But providing a simple and visible way of
doing it is definitely good enough.

Salutaciones,
                         JCAB

> not forbid pointer arithmetic by default?  It could be allowed with a
switch for
> compatibility.

<Babble>
That reminds me of C#. It has has unsafe blocks where you can do all your
dirty code work. Even without pointers and the like, there will still be
memory bugs. If a variable overflows, and the programmer simply tells the
system to reboot/shutdown, then you have rockets falling out of the sky (ie
ADA). In many cases, it's impossible to catch every error but it's possible
to reduce them by forcing the programmer to work a particular way like you
suggest with pointers. However, sometimes the best solution is to a product
that is reasonably bug free and use testing processes and end users to plug
the gaps.

In the defence of pointers. Sometimes pointers can reduce bugs because things coded may be shorter and more readable. Also a I consider speed a debugging issue. so for code that is meant to run efficiently but doesn't, that's a bug. If pointer can solved this issue (most often they don't bring much of a performance benefit), then that's what I'll use.

--One of the disadvantages of adding more language features to code is that it gets harder to read. Of course you need to always weight this up against efficiency, writability and flexibility.

"Russ Lewis" <Russ_member@pathlink.com> wrote in message news:ai4als$kro$1@digitaldaemon.com...
> In article <ai45k0$ffo$1@digitaldaemon.com>, Rex Couture says...
> >
> >I don't know much about the question about balance between power and
safety, and
> >it probably seems awfully presumptuous of me to try to influence language design.  I just think that if mistakes can be made, they will be.  It's
the guys
> >who write my word processor, the guys who write all my security
loopholes, the
> >guys who write my operating systems, etc., that I'm worried about.
Although
> >they're getting better, a lot of API calls and drivers are actually not
very
> >reliable.  It would be very nice if D were to become the next preferred language, and would eliminate memory errors forever.  It seems to close.
Inline
> >assembler will not be used very much.  But if pointer arithmetic is easy,
it
> >will be commonly used, and mistakes will be made.  Are you sure that
there isn't
> >a safe and effective way to avoid pointer arithmetic?
>
> One of the things I'm very excited about is that D includes enough
language
> features (dynamic arrays, in particular), that pointers are no longer
necessary
> for the vast majority of programs.
>
> I fully expect that, in the future, D compilers will come with compiler
switches
> to turn on/turn off pointer arithmetic.  In fact, I believe that in most
cases,
> POINTER ARITHMETIC OFF will be the DEFAULT OPTION.
>
> For those who still need it (systems programmers, perhaps some very performance-sensitive game programmers), it will be there, but very few
people
> will ever use it.
>

I think most compiler switches should be included in the code itself. That way each peace of code should run without having to know what complier switches are needed. This would expecially the case if you wanted to combine projects/modules. I think there should be a standard on how things are disabled/enabled in a program. It should be module based so that options don't effect other modules.

My suggestion is that it could be block based and look something like this.

dEnable(D_POINTER_ARITHMETIC | ...);


dDiable(D_POINTER_ARITHMETIC | ...);

and...

//Parhaps a set command would be better in this particular case
dDisable(D_ALL); //Disables all
dEnable(D_STANDARD); //The d standards


and parhaps complier stacking....

dPushEnable();
dDisable(D_POINTER_ARITHMETIC)

dPopEnable(); //We're finished with it

This code of course would be worked out at compiler time so "if" statement and the like wouldn't effect it. It would also be able to used in the global area (anywhere in the code) because for example...

dEnable(D_POINTER_ARITHMETIC);

int *p; ect...

dDisable(D_POINTER_ARITHMETIC);


//This method needs pointers
int func()
{
    dEnable(D_POINTER_ARITHMETIC);

    p = NULL;
    ...

    dDisable(D_POINTER_ARITHMETIC);
}

That's just my thoughts on that matter.