help signed and unsigned in 64bits

[amit]

Hi,

What will happen in following scenario..
long a = -2;
longlong b = a

long c;
c = *(ulonglong *)&b;
b = c;
also when
long d;
d = *&b;
b = d;
What will be the value of b ? When will it lose the upper 32bits ?

regards
amit

[Leor Zolman]

On 6 Apr 2004 17:44:38 -0700, an******@yahoo.com (amit) wrote:

Hi,

What will happen in following scenario..
long a = -2;
longlong b = a

long c;
c = *(ulonglong *)&b;
b = c;
also when
long d;
d = *&b;
b = d;
What will be the value of b ? When will it lose the upper 32bits ?

regards
amit

Let me know if I've misinterpreted anything you wrote up there:

#include <stdio.h>

int main()
{
long a = -2;

printf("a = %ld\n", a);
printf("a (unsigned) = %uld\n\n", a);

long long b = a;
printf("b = %lld\n", b);
printf("b (unsigned) = %llu\n\n", b);

long c;
c = *(unsigned long long *)&b;
printf("c (via pointers) = %ld\n", c);
printf("c (via pointers, unsigned) = %uld\n\n", c);

/* I've added this (why bother with the pointers? */
c = (unsigned long long) b;
printf("c (no pointers) = %ld\n", c);
printf("c (no pointers, unsigned) = %uld\n\n", c);

b = c;
long d;
d = *&b;
printf("d = %ld\n", d);
printf("d (unsigned) = %uld\n\n", d);

b = d;
printf("b (from d) = %lld\n", b);
printf("b (from d) (unsigned) = %llu\n\n", b);

b = (unsigned) d;
printf("b (from unsigned d) = %lld\n", b);
printf("b (from unsigned d) (unsigned) = %llu\n\n", b);
return 0;
}

Output:
a = -2
a (unsigned) = 4294967294ld

b = -2
b (unsigned) = 18446744073709551614

c (via pointers) = -2
c (via pointers, unsigned) = 4294967294ld

c (no pointers) = -2
c (no pointers, unsigned) = 4294967294ld

d = -2
d (unsigned) = 4294967294ld

b (from d) = -2
b (from d) (unsigned) = 18446744073709551614

b (from unsigned d) = 4294967294
b (from unsigned d) (unsigned) = 4294967294

So note that you do lose finally lose the upper 32 bits when assigning from
d to c, /if/ you first cast d's value to unsigned. So long as you're doing
the assignment as a signed value, you'll get sign extension.

(Compiled with Comeau 4.3.3, Dinkum Unabridged Library)
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On 6 Apr 2004 17:44:38 -0700, an******@yahoo.com (amit) wrote:

Hi,

What will happen in following scenario..
long a = -2;
longlong b = a

long c;
c = *(ulonglong *)&b;
b = c;
also when
long d;
d = *&b;
b = d;
What will be the value of b ? When will it lose the upper 32bits ?

regards
amit

Let me know if I've misinterpreted anything you wrote up there:

#include <stdio.h>

int main()
{
long a = -2;

printf("a = %ld\n", a);
printf("a (unsigned) = %uld\n\n", a);

long long b = a;
printf("b = %lld\n", b);
printf("b (unsigned) = %llu\n\n", b);

long c;
c = *(unsigned long long *)&b;
printf("c (via pointers) = %ld\n", c);
printf("c (via pointers, unsigned) = %uld\n\n", c);

/* I've added this (why bother with the pointers? */
c = (unsigned long long) b;
printf("c (no pointers) = %ld\n", c);
printf("c (no pointers, unsigned) = %uld\n\n", c);

b = c;
long d;
d = *&b;
printf("d = %ld\n", d);
printf("d (unsigned) = %uld\n\n", d);

b = d;
printf("b (from d) = %lld\n", b);
printf("b (from d) (unsigned) = %llu\n\n", b);

b = (unsigned) d;
printf("b (from unsigned d) = %lld\n", b);
printf("b (from unsigned d) (unsigned) = %llu\n\n", b);
return 0;
}

Output:
a = -2
a (unsigned) = 4294967294ld

b = -2
b (unsigned) = 18446744073709551614

c (via pointers) = -2
c (via pointers, unsigned) = 4294967294ld

c (no pointers) = -2
c (no pointers, unsigned) = 4294967294ld

d = -2
d (unsigned) = 4294967294ld

b (from d) = -2
b (from d) (unsigned) = 18446744073709551614

b (from unsigned d) = 4294967294
b (from unsigned d) (unsigned) = 4294967294

So note that you do lose finally lose the upper 32 bits when assigning from
d to c, /if/ you first cast d's value to unsigned. So long as you're doing
the assignment as a signed value, you'll get sign extension.

(Compiled with Comeau 4.3.3, Dinkum Unabridged Library)
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On Wed, 07 Apr 2004 01:13:59 GMT, Leor Zolman <le**@bdsoft.com> wrote:

Well, that was my very first time attempting to display values of long
longs, and in my confusion I ended up with a spurious "d" in four format
conversions (I put %uld when %ul was sufficient for a plain unsigned long).

Fortunately, that didn't really break the output, except that there's a
trailing, meaningless 'd' at the end of 4 of the lines. Sorry about that.
-leor

P.S. It took me a while to find a platform that displayed long long values
at all! Good thing I had that Dinkum lib lying around... ;-)

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On Wed, 07 Apr 2004 01:13:59 GMT, Leor Zolman <le**@bdsoft.com> wrote:

Well, that was my very first time attempting to display values of long
longs, and in my confusion I ended up with a spurious "d" in four format
conversions (I put %uld when %ul was sufficient for a plain unsigned long).

Fortunately, that didn't really break the output, except that there's a
trailing, meaningless 'd' at the end of 4 of the lines. Sorry about that.
-leor

P.S. It took me a while to find a platform that displayed long long values
at all! Good thing I had that Dinkum lib lying around... ;-)

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Jack Klein]

On 6 Apr 2004 17:44:38 -0700, an******@yahoo.com (amit) wrote in
comp.lang.c:

Hi,

What will happen in following scenario..
long a = -2;
longlong b = a

long c;
c = *(ulonglong *)&b;
The result of the assignment is implementation-defined, or, under C99,
for some strange reason, there is the alternative possibility that an
implementation-defined signal will be raised.
b = c;
also when
long d;
d = *&b;
Again, the result is implementation-defined.
b = d;
What will be the value of b ? When will it lose the upper 32bits ?
You will need to try it on your compiler to find out, or consult the
compiler's documentation. You are assigning a value to a signed
integer type from a wider type when the value of the wider type is
outside the range of the destination signed type. The C standard does
not specify the result, only that it is implementation-defined. That
means the compiler must document what it does.

And there is no guarantee that long long has 32 more bits than long,
of course.
regards
amit

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On 6 Apr 2004 17:44:38 -0700, an******@yahoo.com (amit) wrote in
comp.lang.c:

Hi,

What will happen in following scenario..
long a = -2;
longlong b = a

long c;
c = *(ulonglong *)&b;
The result of the assignment is implementation-defined, or, under C99,
for some strange reason, there is the alternative possibility that an
implementation-defined signal will be raised.
b = c;
also when
long d;
d = *&b;
Again, the result is implementation-defined.
b = d;
What will be the value of b ? When will it lose the upper 32bits ?
You will need to try it on your compiler to find out, or consult the
compiler's documentation. You are assigning a value to a signed
integer type from a wider type when the value of the wider type is
outside the range of the destination signed type. The C standard does
not specify the result, only that it is implementation-defined. That
means the compiler must document what it does.

And there is no guarantee that long long has 32 more bits than long,
of course.
regards
amit

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Leor Zolman]

On Tue, 06 Apr 2004 20:45:25 -0500, Jack Klein <ja*******@spamcop.net>
wrote:

You will need to try it on your compiler to find out, or consult the
compiler's documentation. You are assigning a value to a signed
integer type from a wider type when the value of the wider type is
outside the range of the destination signed type. The C standard does
not specify the result, only that it is implementation-defined. That
means the compiler must document what it does.

And there is no guarantee that long long has 32 more bits than long,
of course.
Of course (not that it even occurred to me, because even with my new locker
and badge I still don't always think in terms of "the general case" when
faced with questions like this) this is all accurate in terms of the
Standard.

I began with the assumption the OP's long long was really longer than his
long (watch it, Richard!) and that he was interested in issues such as the
ones I tried to highlight in my test program. I'm kind of hoping he finds
/both/ analyses to be useful...
-leor

regards
amit

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On Tue, 06 Apr 2004 20:45:25 -0500, Jack Klein <ja*******@spamcop.net>
wrote:

You will need to try it on your compiler to find out, or consult the
compiler's documentation. You are assigning a value to a signed
integer type from a wider type when the value of the wider type is
outside the range of the destination signed type. The C standard does
not specify the result, only that it is implementation-defined. That
means the compiler must document what it does.

And there is no guarantee that long long has 32 more bits than long,
of course.
Of course (not that it even occurred to me, because even with my new locker
and badge I still don't always think in terms of "the general case" when
faced with questions like this) this is all accurate in terms of the
Standard.

I began with the assumption the OP's long long was really longer than his
long (watch it, Richard!) and that he was interested in issues such as the
ones I tried to highlight in my test program. I'm kind of hoping he finds
/both/ analyses to be useful...
-leor

regards
amit

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Jack Klein]

On Wed, 07 Apr 2004 01:54:43 GMT, Leor Zolman <le**@bdsoft.com> wrote
in comp.lang.c:

On Tue, 06 Apr 2004 20:45:25 -0500, Jack Klein <ja*******@spamcop.net>
wrote:

You will need to try it on your compiler to find out, or consult the
compiler's documentation. You are assigning a value to a signed
integer type from a wider type when the value of the wider type is
outside the range of the destination signed type. The C standard does
not specify the result, only that it is implementation-defined. That
means the compiler must document what it does.

And there is no guarantee that long long has 32 more bits than long,
of course.

Of course (not that it even occurred to me, because even with my new locker
and badge I still don't always think in terms of "the general case" when
faced with questions like this) this is all accurate in terms of the
Standard.

I began with the assumption the OP's long long was really longer than his
long (watch it, Richard!) and that he was interested in issues such as the
ones I tried to highlight in my test program. I'm kind of hoping he finds
/both/ analyses to be useful...
-leor

Your test program was actually an excellent idea. One way to
determine implementation-defined results with a particular compiler is
to test it. And since the OP's question involved only
implementation-defined, and not undefined, behavior, a test is quite
practical.

The only thing the OP needs to remember is that he should compile and
run your test program on his implementation, where the results he gets
might or might not be the same as those you got.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On Wed, 07 Apr 2004 01:54:43 GMT, Leor Zolman <le**@bdsoft.com> wrote
in comp.lang.c:

On Tue, 06 Apr 2004 20:45:25 -0500, Jack Klein <ja*******@spamcop.net>
wrote:

You will need to try it on your compiler to find out, or consult the
compiler's documentation. You are assigning a value to a signed
integer type from a wider type when the value of the wider type is
outside the range of the destination signed type. The C standard does
not specify the result, only that it is implementation-defined. That
means the compiler must document what it does.

And there is no guarantee that long long has 32 more bits than long,
of course.

Of course (not that it even occurred to me, because even with my new locker
and badge I still don't always think in terms of "the general case" when
faced with questions like this) this is all accurate in terms of the
Standard.

I began with the assumption the OP's long long was really longer than his
long (watch it, Richard!) and that he was interested in issues such as the
ones I tried to highlight in my test program. I'm kind of hoping he finds
/both/ analyses to be useful...
-leor

Your test program was actually an excellent idea. One way to
determine implementation-defined results with a particular compiler is
to test it. And since the OP's question involved only
implementation-defined, and not undefined, behavior, a test is quite
practical.

The only thing the OP needs to remember is that he should compile and
run your test program on his implementation, where the results he gets
might or might not be the same as those you got.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[CBFalconer]

amit wrote:

What will happen in following scenario..
long a = -2;
longlong b = a
The compiler complains about a syntax error.

long c;
c = *(ulonglong *)&b;
Another syntax error.
b = c;
also when
long d;
d = *&b;
b = d;
What will be the value of b ? When will it lose the upper 32bits ?

Since things don't compile, the remainder of the question is
meaningless. You should consider the use and meaning of the blank
character.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[CBFalconer]

amit wrote:

What will happen in following scenario..
long a = -2;
longlong b = a
The compiler complains about a syntax error.

long c;
c = *(ulonglong *)&b;
Another syntax error.
b = c;
also when
long d;
d = *&b;
b = d;
What will be the value of b ? When will it lose the upper 32bits ?

Since things don't compile, the remainder of the question is
meaningless. You should consider the use and meaning of the blank
character.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[jacob navia]

You get the same results if you use lcc-win32.
lcc-win32 supports long long since quite a while
now.

[jacob navia]

You get the same results if you use lcc-win32.
lcc-win32 supports long long since quite a while
now.

[Leor Zolman]

On Wed, 7 Apr 2004 08:55:10 +0200, "jacob navia" <ja***@jacob.remcomp.fr>
wrote:

You get the same results if you use lcc-win32.
lcc-win32 supports long long since quite a while
now.

Thanks, Jacob, I didn't even know about your compiler. I've been
"collecting" C++ compilers (for STLFilt development work), but for C I've
just been relying on the ones (such as Comeau) that come "free" with C++
and have done the best job of diagnosing things. I'll get lcc-win32 and
play with it.
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On Wed, 7 Apr 2004 08:55:10 +0200, "jacob navia" <ja***@jacob.remcomp.fr>
wrote:

You get the same results if you use lcc-win32.
lcc-win32 supports long long since quite a while
now.

Thanks, Jacob, I didn't even know about your compiler. I've been
"collecting" C++ compilers (for STLFilt development work), but for C I've
just been relying on the ones (such as Comeau) that come "free" with C++
and have done the best job of diagnosing things. I'll get lcc-win32 and
play with it.
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On Wed, 07 Apr 2004 01:29:19 GMT, Leor Zolman <le**@bdsoft.com> wrote:

On Wed, 07 Apr 2004 01:13:59 GMT, Leor Zolman <le**@bdsoft.com> wrote:

Well, that was my very first time attempting to display values of long
longs, and in my confusion I ended up with a spurious "d" in four format
conversions (I put %uld when %ul was sufficient for a plain unsigned long).

Fortunately, that didn't really break the output, except that there's a
trailing, meaningless 'd' at the end of 4 of the lines. Sorry about that.
-leor

P.S. It took me a while to find a platform that displayed long long values
at all! Good thing I had that Dinkum lib lying around... ;-)

You're all way too polite (heh), I can't believe no one has posted yet to
give me hell. To set the record straight, I do in fact realize that those
conversions I originally wrote as "%uld", then corrected to "%ul", should
actually be "%lu". The consistency between long and long long conversion
syntax is way too sensible for me to have thought of trying it first, and
then bad eyesight must have made me think the ells before the d's were
ones...
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On Wed, 07 Apr 2004 01:29:19 GMT, Leor Zolman <le**@bdsoft.com> wrote:

On Wed, 07 Apr 2004 01:13:59 GMT, Leor Zolman <le**@bdsoft.com> wrote:

Well, that was my very first time attempting to display values of long
longs, and in my confusion I ended up with a spurious "d" in four format
conversions (I put %uld when %ul was sufficient for a plain unsigned long).

Fortunately, that didn't really break the output, except that there's a
trailing, meaningless 'd' at the end of 4 of the lines. Sorry about that.
-leor

P.S. It took me a while to find a platform that displayed long long values
at all! Good thing I had that Dinkum lib lying around... ;-)

You're all way too polite (heh), I can't believe no one has posted yet to
give me hell. To set the record straight, I do in fact realize that those
conversions I originally wrote as "%uld", then corrected to "%ul", should
actually be "%lu". The consistency between long and long long conversion
syntax is way too sensible for me to have thought of trying it first, and
then bad eyesight must have made me think the ells before the d's were
ones...
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Dan Pop]

In <r2********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On Wed, 07 Apr 2004 01:13:59 GMT, Leor Zolman <le**@bdsoft.com> wrote:

Well, that was my very first time attempting to display values of long
longs, and in my confusion I ended up with a spurious "d" in four format
conversions (I put %uld when %ul was sufficient for a plain unsigned long).
Bzzzt, still wrong. The *correct* conversion descriptor for unsigned long
is, and has always been, %lu. %ul expects an unsigned int and appends an
'l' to its value. If it receives an unsigned long, undefined behaviour.
Fortunately, that didn't really break the output, except that there's a
trailing, meaningless 'd' at the end of 4 of the lines. Sorry about that.
It broke everything, due to invoking undefined behaviour, so any output
you got was by accident, rather than by design.
P.S. It took me a while to find a platform that displayed long long values
at all! Good thing I had that Dinkum lib lying around... ;-)

It's been a common Unix extension for ages...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <r2********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On Wed, 07 Apr 2004 01:13:59 GMT, Leor Zolman <le**@bdsoft.com> wrote:

Well, that was my very first time attempting to display values of long
longs, and in my confusion I ended up with a spurious "d" in four format
conversions (I put %uld when %ul was sufficient for a plain unsigned long).
Bzzzt, still wrong. The *correct* conversion descriptor for unsigned long
is, and has always been, %lu. %ul expects an unsigned int and appends an
'l' to its value. If it receives an unsigned long, undefined behaviour.
Fortunately, that didn't really break the output, except that there's a
trailing, meaningless 'd' at the end of 4 of the lines. Sorry about that.
It broke everything, due to invoking undefined behaviour, so any output
you got was by accident, rather than by design.
P.S. It took me a while to find a platform that displayed long long values
at all! Good thing I had that Dinkum lib lying around... ;-)

It's been a common Unix extension for ages...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Leor Zolman]

On 7 Apr 2004 14:09:27 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <r2********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On Wed, 07 Apr 2004 01:13:59 GMT, Leor Zolman <le**@bdsoft.com> wrote:

Well, that was my very first time attempting to display values of long
longs, and in my confusion I ended up with a spurious "d" in four format
conversions (I put %uld when %ul was sufficient for a plain unsigned long).
Bzzzt, still wrong. The *correct* conversion descriptor for unsigned long
is, and has always been, %lu. %ul expects an unsigned int and appends an
'l' to its value. If it receives an unsigned long, undefined behaviour.

I guess at least technically, I don't need to say "I spoke too soon" :-)

Fortunately, that didn't really break the output, except that there's a
trailing, meaningless 'd' at the end of 4 of the lines. Sorry about that.

It broke everything, due to invoking undefined behaviour, so any output
you got was by accident, rather than by design.

P.S. It took me a while to find a platform that displayed long long values
at all! Good thing I had that Dinkum lib lying around... ;-)

It's been a common Unix extension for ages...

I only use Unix for teaching Unix and making tar files (and for the
latter, Cgwin actually...)
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On 7 Apr 2004 14:09:27 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <r2********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On Wed, 07 Apr 2004 01:13:59 GMT, Leor Zolman <le**@bdsoft.com> wrote:

Well, that was my very first time attempting to display values of long
longs, and in my confusion I ended up with a spurious "d" in four format
conversions (I put %uld when %ul was sufficient for a plain unsigned long).
Bzzzt, still wrong. The *correct* conversion descriptor for unsigned long
is, and has always been, %lu. %ul expects an unsigned int and appends an
'l' to its value. If it receives an unsigned long, undefined behaviour.

I guess at least technically, I don't need to say "I spoke too soon" :-)

Fortunately, that didn't really break the output, except that there's a
trailing, meaningless 'd' at the end of 4 of the lines. Sorry about that.

It broke everything, due to invoking undefined behaviour, so any output
you got was by accident, rather than by design.

P.S. It took me a while to find a platform that displayed long long values
at all! Good thing I had that Dinkum lib lying around... ;-)

It's been a common Unix extension for ages...

I only use Unix for teaching Unix and making tar files (and for the
latter, Cgwin actually...)
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[CBFalconer]

Leor Zolman wrote:

.... snip ...
I only use Unix for teaching Unix and making tar files (and for
the latter, Cgwin actually...)

Try DJGPP. Much faster. Does all those things.

--
Some useful references:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>

[Leor Zolman]

On Wed, 07 Apr 2004 22:12:53 GMT, CBFalconer <cb********@yahoo.com> wrote:

Leor Zolman wrote:

... snip ...

I only use Unix for teaching Unix and making tar files (and for
the latter, Cgwin actually...)

Try DJGPP. Much faster. Does all those things.

Oh, I have that here. Not sure I ever realized it does C. I got the gcc
version of STLFilt (for C++ of course) supporting djgpp back in 2002...and
I just realized that nowhere in my docs is that fact actually documented.
That's because I just think of djgpp as "yet another gcc clone", and
figured everyone else would probably know that its messages would be the
same as those of "vanilla" gcc. Foo. Thanks for the heads up!
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Dan Pop]

In <kc********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On 7 Apr 2004 14:09:27 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <r2********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

P.S. It took me a while to find a platform that displayed long long values
at all! Good thing I had that Dinkum lib lying around... ;-)

It's been a common Unix extension for ages...

I only use Unix for teaching Unix and making tar files (and for the
latter, Cgwin actually...)

^^^^^^^^^^^^^^
Cygwin's gcc and libraries have supported long long forever, so you had
such a platform right under your nose ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de