Sean Kelly wrote:

> In article <cf0e4q$mqi$1@digitaldaemon.com>, parabolis says...
> 
>>
>>Sorry I meant from the docs
>>
>>http://www.digitalmars.com/d/type.html:
>>
>>    void  no type
>>     bit  single bit
>>    byte  signed 8 bits
>>   ubyte  unsigned 8 bits
>>   ....
> 
> 
> Probably an esoteric question, but I assume that the byte size gurantee is only
> for machines with the proper architecture?  Not that I expect to see a D
> compiler for the very few machines that support strange byte sizes, just
> wondering...

Actually that is not a terribly esoteric question. I do not believe the D byte is the same as the C/C++ char. (Which is what I assume you are referring to in this case.) I would be curious to know the answer as well. I would also be curious how a compiler would deal with Harvard architecture.

On Fri, 06 Aug 2004 14:29:19 -0400, parabolis <parabolis@softhome.net> wrote:

<snip>

>> I still don't agree with the last bit, void[] gives no _assurance_ at all, neither does ubyte[] or any other [].
>
> My argument is that there exists a program in which a bug will be caught.

Ok.

> You argument is that there does not exist a program such that a bug will be caught (or that for all programs there is no program such that a bug is caught).

I make no such argument. In fact I am having a hard time following the above sentence.

> Assuming we have the function:
>       read_bad(void*,uint len)
>      read_good(ubyte[],uint len)
>
> A exerpt from program P in which a bug is caught is as follows:
> ============================== P ==============================
>      ubyte ex[256];
>       read_bad(ex,0xFFFF_FFFF); // memory overwritten
>      read_good(ex,0xFFFF_FFFF); // exception thrown
> ================================================================
>
> P contains a bug that is caught using an array parameter. The existance of P simultaneously proves my argument and disproves yours.

I don't think you understand my argument.

> Yet we have had this discussion before and you seem to insist that since you can find examples where a bug is not caught my argument must be wrong somehow. I am not familiar with any logic in which such claims are expected. Either you will have to explain the logic system you are using to me so I can explain my claim properly or you will have to use the one I am using. Here are some links to mine:
>
> http://en.wikipedia.org/wiki/Logic
> http://en.wikipedia.org/wiki/Predicate_logic
> http://en.wikipedia.org/wiki/Universal_quantifier
> http://en.wikipedia.org/wiki/Existential_quantifier

You are missing my point.

There is one pivotal fact in this debate and that is that an array is _not_ guaranteed to be correct about it's own length. Consider:

void read(void[] a, int length) {
  if (length > a.length)
    throw new Exception(..);
}
void main()
{
  char* p = "0123456789";
  read(&p[0..1000],1000);
}

no exception is throw and memory is overwritten.

My point, which you seem to have missed, is simply: "An array is _not_ guaranteed to be correct about it's own length"

The reason this point is all important in this debate is that when trying to write basic types and structs you _will_ need to create the array from the basic type, when doing so you _will_ need to define the arrays length manually. So there is _always_ going to be the same risk of error regardless of whether you use void[] or void*.

Since the risk is the same in either case I vote for the clearest/cleanest/simplest code, as this reduces the risk of error slightly, the code I propsed:

bool read(out int x) {
  return read(&x,x.sizeof) == x.sizeof;
}

is cleaner/clearer and simpler than

bool read(out int x) {
  return read(&x[0..x.sizeof],x.sizeof) == x.sizeof);
}

>>> However I think the conceptual problems void[] introduces outweigh the benefits. void[] does a rather unspected thing when it gives you a byte count in .length.
>>
>>
>> That is what I assumed it would do. A void* is a pointer to 'something', the smallest addressable unit is a byte. As you do not know what 'something' is, you have to provide the ability to address the smallest addressable unit, i.e. a byte.
>
> Wonderful guess. It is entirely more complicated than a ubyte[] being a partition of memory on 8-bit boundries and knowing how the length and sizeof will work.

The semantics of void* are quite well known, anyone who has used it knows what I have described above, anyone who doesn't will read the docs on void* before they start. Anyone who _guesses_ what will happen is asking for trouble.

>>> The default assumption would be (or at least my default assumption was) that the .length would be the same for an int[] being treated as a void[].
>>
>>
>> But then you cannot address each of the 4 bytes of each int.
>
> Yes that was exactly my point.

So we agree, void[] works in a logical fashion.

>>> This suggests that at least some people using/writing functions with void[] parameters will do strange things.
>>
>>
>> Have you used 'void' as a type before, I suspect only people who have
>
> No I have never used void as a type before. I have always been under the impression that "void varX;" is not a legal declaration/definition in C or C++. I have used void* frequently in C/C++ but the size of any void* variables is of course the size of any pointer.

In that case why didn't you read the documentation on the void[] type?

>> not used the concept before will get this wrong, and a simple line of documentation describing void[] will put them right.
>
> Or using ubyte[] will write the documentation for me and provide some assurance that in cases in which people did not read the docs will have a chance of getting it right from the start.

Rubbish, you're basically asserting that ubyte[] is known of by everyone, and that is simply not true.

>>> I believe the ensuing confusion warrants using a ubyte[] which which has behaviour that people will already understand.
>>
>>
>> I agree ubyte[] is the 'right' type, the data itself is a bunch of unsigned bytes, but, void[] or void* give you ease of use that ubyte[] lacks.
>
> No actually I have been saying void is 'right' because streaming data is only partitioned according to the semantics of the interpretation of the data. Partitioning data into a byte forces an arbitrary partition of general data that would not happen conceptually with void.
>
> I just feel that using void[] lacks the ease of use you get with ubyte[].

Ease of use?! How is this:

bool read(out int x) {
  return read(&x[0..x.sizeof],x.sizeof) == x.sizeof);
}

easier than:

bool read(out int x) {
  return read(&x,x.sizeof) == x.sizeof;
}

?


There seems to be 2 points in this argument, "what is easier" and "what is safer", my opinion which I have tried to demonstrate is that neither is safer and void* is easier.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/