[m-dev.] MSVC and --no-smart-indexing

[Zoltan Somogyi]

On Mon, 9 Feb 2015 10:32:12 +1100, Paul Bone <paul at bone.id.au> wrote:
> > I don't have any convenient way to test cross-compilation between
> > 32 and 64 bit systems, but if someone does, I could generate diffs
> > for them to test.
> 
> I can test this.

OK. I will look at the smart indexing code for both backends with an eye
for cross compilation.
 
> > This should be fixable by having the hash functions mask out bits
> > above e.g. 2^30 on all platforms.
> 
> That's easy enough to do and except for the most extreme cases it won't
> cause any significant issues.

Implemented by the attached diff, for review by anyone.

> However it will only work well if there are some string primates that will
> return the Nth character without testing the length of the string on every
> call, that return the "rest" of the string without copying it (we might have
> this already),

No, that operation does not exist, and it CANNOT exist. If S1 points to
a string, and you applied this operation to assign to S2 (say) all the
chars in S1 after the 10th, and S1 became dead, then Boehm would
collect the block containing the string, and then S2 would become
a dangling pointer.

We could have a restricted version that would work only for values on N
that we have registered as allowed offsets with Boehm, which would mean
1-7 for 64 bit platforms. That may be useful enough for tries, but would
complicate the implementation, since trie nodes on different sides of depth 7
would need different handling.

> and that will return the null byte at the end of the string
> and allow our switch code to test to see if the byte is null.  Also this
> won't support unicode without some extra effort.

It should be possible to mostly ignore Unicode by working on code units,
not code points.

> It may have already been fixed in more recent versions of MSVC.  I don't
> have access to these so I don't know.  If not then I would guess that they
> would laugh at us for being so small but claiming that our compiler is more
> robust.

I am not claiming that in general, just in this specific instance.

> That said, our compiler is probably exercised less than there's.
> Apart from G12 (or whatever it is these days) and PrinceXML I don't think
> Mercury has to deal with machine generated code very often.

But at least we TRY to deal with it.

> Anyway, I expect nothing to happen if I report this so I don't think it's
> worth my time.

Agreed. Fixing this won't lead to new sales for Microsoft, so they would
ignore it.

Zoltan.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.string_hash
Type: application/octet-stream
Size: 1021 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/developers/attachments/20150209/f0116ee8/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.string_hash
Type: application/octet-stream
Size: 27043 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/developers/attachments/20150209/f0116ee8/attachment-0001.obj>