Re: Horses & water
- From: koehler@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (Bob Koehler)
- Date: 12 Oct 2010 08:23:51 -0600
In article <i9055q$a5s$5@xxxxxxxxxxxxxxxxxxxx>, Johnny Billquist <bqt@xxxxxxxxxx> writes:
Heck! The standard more or less makes sure you cannot do that.
Pointer arithmetic is legal, and used, and can point to anywhere inside,
or outside what you might think is meaningful, and still be legal.
You don't want to break this, believe me.
You can accomplish this in Fortran via out of range indexes. And
you can turn on and off the compiler and run time checks to make
sure you don't, if you have a good compiler. But language
rules help you not overflow string buffers by simply requiring
behavior that tracks the allocated (not used) length of strings
(you can allways call LEN() on a CHARACTER variable).
And in general, I do want to break it. I want to find the incipient
bugs in programs. I know of exceptions to that rule and its good
to be able to handle the exceptional circumstances, but not by
making them the rule.
I've seen folks claim that it's not the fault of the language that
compilers don't do this. The langauge standard does require null
terminated strings, but does not require that they be simply
passed by reference. But nothing ever gets added to the standard
that isn't met by passing them by reference, so compiler writers
won't do it.
To me, that's a fault of the language.
Yes, in C, there is a requirement that they be passed by reference. Or
rather, C don't pass strings at all. It only passes pointers. And the
pointers are actually passed by value.
The problem though, is that strings are just random pointers in C.
I've seen lots of behavior in C that is required and met by pass
by reference, but I have not seen an explicit requirement that
additional information cannot be passed.
- Prev by Date: Re: c.o.v opinion requested, was: Re: Problems restoring saveset using VMS 8.3 Alpha CD
- Next by Date: Re: Horses & water
- Previous by thread: Re: Horses & water
- Next by thread: Re: Horses & water