Hi,

it seems dmc just uses the lower 32 bits of my 64-bit integer literals.

long long t = 123456789012345;
gives t the value 123456789012345 mod 2^32 = 2249056121

The compiler doesn't even give a warning.

Digital Mars C/C++ Compiler Version 8.33.13n

Regards,
Mikael

On Sat, 5 Apr 2003 13:34:32 +0000 (UTC), Mikael Klasson wrote:
> long long t = 123456789012345;

use
long long t = 123456789012345LL;
instead

> The compiler doesn't even give a warning.

a warning would be nice though.


bye, Christof

-- 
http://cmeerw.org                                 JID: cmeerw@jabber.at mailto cmeerw at web.de

...and what have you contributed to the Net?

>use
>long long t = 123456789012345LL;
>instead

Thanks! You just saved me a lot of hassle.

Cheers,
Mikael

P.S. God I love this compiler... It's soooo fast. :) The most annoying thing I can think of is the 40MB(?) optlink limit on static data. No fix for that?

"Mikael Klasson" <Mikael_member@pathlink.com> wrote in message news:b6mnsa$10ko$1@digitaldaemon.com...
> P.S. God I love this compiler... It's soooo fast. :) The most annoying
thing I
> can think of is the 40MB(?) optlink limit on static data. No fix for that?


Kinda stuck with that. Optlink is written entirely in heavilly optimized assembler, and is a bit immune to any rewrites :-(

>Kinda stuck with that. Optlink is written entirely in heavilly optimized assembler, and is a bit immune to any rewrites :-(

How about that warning for cropped 64-bit literals then? I'm certainly not used to appending LL, and it seems like a useful warning.

Thanks anyhow,
Mikael

"Mikael Klasson" <Mikael_member@pathlink.com> wrote in message news:b6nlpu$1mjg$1@digitaldaemon.com...
> >Kinda stuck with that. Optlink is written entirely in heavilly optimized assembler, and is a bit immune to any rewrites :-(
>
> How about that warning for cropped 64-bit literals then? I'm certainly not
used
> to appending LL, and it seems like a useful warning.

Years ago, it used to and I removed it. I don't remember why. There was a reason :-)

Can we have it back? That'd be good. :)

"Walter" <walter@digitalmars.com> wrote in message news:b6nnj4$1nsg$1@digitaldaemon.com...
>
> "Mikael Klasson" <Mikael_member@pathlink.com> wrote in message news:b6nlpu$1mjg$1@digitaldaemon.com...
> > >Kinda stuck with that. Optlink is written entirely in heavilly
optimized
> > >assembler, and is a bit immune to any rewrites :-(
> >
> > How about that warning for cropped 64-bit literals then? I'm certainly
not
> used
> > to appending LL, and it seems like a useful warning.
>
> Years ago, it used to and I removed it. I don't remember why. There was a reason :-)
>
>

On Sat, 5 Apr 2003 14:06:02 +0000 (UTC), Mikael Klasson wrote:
> P.S. God I love this compiler... It's soooo fast. :) The most annoying thing I can think of is the 40MB(?) optlink limit on static data. No fix for that?

I am currently working on getting OpenWatcom's wlink to work with DMC. So far, I have it mostly working (just had to fix a few incompatibilities in wlink's OMF-file processing).

It is able to link programs with more than 40 MB static data (but the resulting EXE-files are in this case also about 40 MB in size - I hope I can find an easy way to fix that).

But probably the most exciting feature is that wlink can read COFF libraries and even Microsoft's new-style COFF import libraries (so you can directly use Microsoft's Platform SDK import libraries without having to convert them).

I am going to release my modifications to wlink in the next few days...


bye, Christof

-- 
http://cmeerw.org                                 JID: cmeerw@jabber.at mailto cmeerw at web.de

...and what have you contributed to the Net?

On Sun, 6 Apr 2003 13:30:11 +0000 (UTC), Christof Meerwald wrote:
> On Sat, 5 Apr 2003 14:06:02 +0000 (UTC), Mikael Klasson wrote:
>> P.S. God I love this compiler... It's soooo fast. :) The most annoying thing I can think of is the 40MB(?) optlink limit on static data. No fix for that?

[OpenWatcom's wlink]
> It is able to link programs with more than 40 MB static data (but the resulting EXE-files are in this case also about 40 MB in size - I hope I can find an easy way to fix that).

Changing the following lines in \dm\src\core32\cinit.asm fixes the problem:

XOF            segment dword use32 public 'BSS'
;               dd      65 dup(0)          ;64 for _atexit_tbl + 1 for null ptr
               org      4 * 65
XOF            ends


> I am going to release my modifications to wlink in the next few days...

It's now available on my Web site at http://cmeerw.org/prog/owtools/


bye, Christof

-- 
http://cmeerw.org                                 JID: cmeerw@jabber.at mailto cmeerw at web.de

...and what have you contributed to the Net?