Checking if a string is null

Frits van Bommel fvbommel at
Thu Jul 26 00:28:16 PDT 2007

Derek Parnell wrote:
> On Thu, 26 Jul 2007 07:50:07 +0200, Frits van Bommel wrote:
>> Derek Parnell wrote:
>>> On Wed, 25 Jul 2007 14:29:47 +0100, Regan Heath wrote:
>>>> Aside: If the location and length are identical you can short-circuit 
>>>> the compare, returning true and ignoring the content, this could save a 
>>>> bit of time on comparisons of large arrays.
>>> I don't think this is such a good idea. How does one address the array of
>>> four bytes at RAM location 4?
>> I'm pretty sure the only way to obtain such an array would be to have 
>> already invoked Undefined Behavior (assuming 4 is an invalid memory 
>> location on the platform the program's running on) and as such it 
>> doesn't really matter whether or not two array references to it compare 
>> equal or not...
> There is no basis for assuming that any RAM location is not addressable. I
> know that some operating systems prevent unprivileged programs from
> accessing certain locations, and that some RAM is hardware-mapped to I/O
> ports, but in theory, D as a system language should be able to address any
> RAM location.
> For example, if D had been implemented for the Amiga system, access to RAM
> address 4 is vital. As that location contained the 32-bit address of the
> list that contains all addresses of the loaded shared libraries. And every
> program needed to access that location.

I'm sorry, but what would then be the problem with accessing 
(cast(byte)4)[0..4] if it's a valid memory location?
I thought your question implied it was an invalid memory location, 
though I'm very aware that's not always the case (which was why I had 
the parenthesized sentence in there).

By the way, null is a valid address on x86 too, but most operating 
systems don't map the first page to any memory to generate pagefaults 
for null pointer dereferences (and IIRC Linux treats the last page 
similarly, for null pointers with negative indices). IIRC DOS didn't 
(and probably couldn't on machines of the time), do this; the interrupt 
table was located there (which would seem to be a pretty bad idea for a 
system without memory protection -- a null pointer write could 
potentially crash the entire system...).

Also, there's no particular reason null has to be cast(whatever)0, that 
just happens to be a convenient easily-checked-for value...

More information about the Digitalmars-d-learn mailing list