AMD "long mode" deficiencies ( Of what use 64-bit "General Purpose" registers?)

(Brian Hurt) writes:
The solution (to this problem) is automatic bounds checking on array
accesses.

OK. Here's some C code that is a simplified version of real code I've
seen in an application that runs on Linux. The actual code was considerably
more complicated, having more arguments and doing various calculations in
each function, but I've shown the part that's problematic. It can be
argued that the code is simply poorly written, however that was less
obvious in the original version than in this simplified version. Anyhow,
the point of proposing protection mechanisms is that they should catch
cases where the code is poorly written.


In one source file:

void foo (char *s)
{
char s2 [40];
bar (s2, s);
}


In another source file:

void bar (char *a, char *b)
{
sprintf (a, "bar: %s\n", b);
}


How is the compiler (or linker, or run time system) going to perform
automatic bounds checking to solve this problem?

I still maintain that C and C++ are terrible languages for constructing
large scale software systems.

On Mon, 23 Jun 2003 16:56:20 -0400, Eric Smith wrote:

I still maintain that C and C++ are terrible languages for constructing
large scale software systems.


My Momma told me to never take any toys from eunuchs.

She said to me I can basically do whatever I visualize,
so I program in Microsoft Visual Basic for $10 an hour.

Spanked me so hard she did when I spilled java-flavored coffee
on her keyboard as I danced while watching the Sun go down.

In article ,
Eric Smith wrote:

How is the compiler (or linker, or run time system) going to perform
automatic bounds checking to solve this problem?

You turn pointers into triples: (ptr, base, bound). Purify did this
ages ago, and gcc has a patch available to do it. It would be nice if
every C/C++ project had this kind of debugging used. At least we can
dream...

greg

Just out of curiosity, what do you think would be a good language for large
scale programs?

Carlo

"Eric Smith" wrote in message
...
(Brian Hurt) writes:
The solution (to this problem) is automatic bounds checking on array
accesses.

OK. Here's some C code that is a simplified version of real code I've
seen in an application that runs on Linux. The actual code was
considerably
more complicated, having more arguments and doing various calculations in
each function, but I've shown the part that's problematic. It can be
argued that the code is simply poorly written, however that was less
obvious in the original version than in this simplified version. Anyhow,
the point of proposing protection mechanisms is that they should catch
cases where the code is poorly written.


In one source file:

void foo (char *s)
{
char s2 [40];
bar (s2, s);
}


In another source file:

void bar (char *a, char *b)
{
sprintf (a, "bar: %s\n", b);
}


How is the compiler (or linker, or run time system) going to perform
automatic bounds checking to solve this problem?

I still maintain that C and C++ are terrible languages for constructing
large scale software systems.

In article k.net,
Kojak wrote:

That gcc patch hasnt been updated in 3 years :-(

See:

http://web.inter.nl.net/hcc/Haj.Ten.Brugge/

For a patch relative to gcc-3.3, the latest version.

-- greg

"Forrest Gump" wrote in message thlink.net...
On Mon, 23 Jun 2003 16:56:20 -0400, Eric Smith wrote:

I still maintain that C and C++ are terrible languages for constructing
large scale software systems.


My Momma told me to never take any toys from eunuchs.

She said to me I can basically do whatever I visualize,
so I program in Microsoft Visual Basic for $10 an hour.

Spanked me so hard she did when I spilled java-flavored coffee
on her keyboard as I danced while watching the Sun go down.

Java is to C what Ebonics is to English.

In article ,
Carlo Razzeto wrote:

| --
| Eric
|
| The more I ponder the principles of language design, and the techniques
| which put them into practice, the more is my amazement and admiration of
| ALGOL 60. Here is a language so far ahead of its time, that it was not
| only an improvement on its predecessors, but also on nearly all its
| successors.
| -- C.A.R. Hoare, "Hints on Programming Language Design", 1974
|
|

Having done large (20k lines of code or more) projects in Ada and PL/I,
I'll take PL/I thanks. I agree with Hoare on Algol-60, my first language
after FORTRAN-II.

--
Bill Davidsen CTO, TMR Associates
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously.
-Benjamin Franklin (who would have liked open source)

(bill davidsen) writes:
Having done large (20k lines of code or more) projects in Ada and PL/I,
I'll take PL/I thanks. I agree with Hoare on Algol-60, my first language
after FORTRAN-II.

Having done large (200k lines of code or more) projects in Ada, and small
projects in PL/I, I'll take Ada any day. What problem did you have with
Ada?

Bernd Paysan writes:
It would be a lot easier to have a fool-proof buffer overflow exploit
preventer if you have two stacks: One for known fixed size data (and if you
can't know anything: a stack for return addresses only), and one for
possibly overflowing buffers.

Standard practice on the AMD 29000. Because an entire stack frame for
the main stack had to fit within the 128 local registers.

Biggest project I've done in C was 4000+ lines, which doesn't quite compare
to your 200K+ Ada project... But I still don't see what the problem with
C/C++ and dirivitive languages are... I honestly like them.

Carlo

"Eric Smith" wrote in message
...
(bill davidsen) writes:
Having done large (20k lines of code or more) projects in Ada and PL/I,
I'll take PL/I thanks. I agree with Hoare on Algol-60, my first language
after FORTRAN-II.

Having done large (200k lines of code or more) projects in Ada, and small
projects in PL/I, I'll take Ada any day. What problem did you have with
Ada?