Paul Eggert wrote:
Matthew Woehlke writes:
Actually, while trying to compile m4, it looks like this may indeed be
a problem. OSS's sys/stat.h bombs if int64_t is not defined,
Can you please explain exactly why this problem occurs?
gnulib's stdint.h replacement should include the relevant
syste
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Actually, while trying to compile m4, it looks like this may indeed be
> a problem. OSS's sys/stat.h bombs if int64_t is not defined,
Can you please explain exactly why this problem occurs?
gnulib's stdint.h replacement should include the relevant
sys
Paul Eggert wrote:
Bruno Haible <[EMAIL PROTECTED]> writes:
Can you agree to that, Paul? I know you worked several hours on this patch,
but if we carry it forward, it will cost many more hours of brain cycles in
other code, like gnulib, coreutils etc. - for the sole purpose of unoptimized
binar
Bruno Haible <[EMAIL PROTECTED]> writes:
> Can you agree to that, Paul? I know you worked several hours on this patch,
> but if we carry it forward, it will cost many more hours of brain cycles in
> other code, like gnulib, coreutils etc. - for the sole purpose of unoptimized
> binaries on one par
Paul Eggert wrote on 2006-10-11:
> 2006-10-11 Paul Eggert <[EMAIL PROTECTED]>
>
> Don't assume that 64-bit signed int is available if unsigned int
> is, and vice versa.
> * lib/allocsa.h (sa_alignment_unsignedlonglong): New constant.
> (sa_alignment_max): Don't assume tha
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Paul Eggert wrote:
>> We haven't observed any bug with left shift of long long int, even
>> with -O.
>
> We haven't? I thought I'd said both had problems;
Sorry; evidently I misunderstood you.
> I should get to it eventually, but I have a lot of *ahe
Paul Eggert wrote:
Matthew Woehlke <[EMAIL PROTECTED]> writes:
Are you not catching the discussion on the coreutils list?
Quite possibly he's not. To summarize what I have observed so far:
We have observed no bugs when compiling without -O, so that seems to
be a viable platform.
We haven't
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Are you not catching the discussion on the coreutils list?
Quite possibly he's not. To summarize what I have observed so far:
We have observed no bugs when compiling without -O, so that seems to
be a viable platform.
We haven't observed any bug wit
Bruno Haible wrote:
Hello Mathew,
mwoehlke wrote:
Ok, I did this:
{ right_works = FALSE; \
printf("j=%i\n", j);\
printf("shc=%i\n", shc);\
printf("sample1=%Ld\n", sample1);\
printf("sample2=%Ld\n", sample2);\
}
Hello Mathew,
> mwoehlke wrote:
> > Ok, I did this:
> > { right_works = FALSE; \
> > printf("j=%i\n", j);\
> > printf("shc=%i\n", shc);\
> > printf("sample1=%Ld\n", sample1);\
> > printf("sample2=%Ld\n", sample2);\
> > }
mwoehlke wrote:
> Ok, I did this:
> { right_works = FALSE; \
> printf("j=%i\n", j);\
> printf("shc=%i\n", shc);\
> printf("sample1=%Ld\n", sample1);\
> printf("sample2=%Ld\n", sample2);\
> }\
>
> ...and got this:
mwoehlke <[EMAIL PROTECTED]> writes:
> j=1
> shc=1
> sample1=a84e715a515523b4
> sample2=0
This was test_integer_sshift, right? In that case, the C standard
says that the behavior of sample1>>shc is implementation-defined if
sample1 is negative, which is the case here. So Tandem C is within
its
Paul Eggert wrote:
mwoehlke <[EMAIL PROTECTED]> writes:
In the midst of all these changes to printf-friends, is anyone (else)
aware that the 'long long' suffix for the system printf on OSS is "L"
("ll" is not recognized)?
That's news to me. I suppose we could configure it as well, though
I'd
mwoehlke <[EMAIL PROTECTED]> writes:
> In the midst of all these changes to printf-friends, is anyone (else)
> aware that the 'long long' suffix for the system printf on OSS is "L"
> ("ll" is not recognized)?
That's news to me. I suppose we could configure it as well, though
I'd rather avoid it
Paul Eggert wrote:
> If you recompile with -D__CHAR_UNSIGNED__ those messages should go way.
Yes.
> > I'm attaching the non-optimized output. The optimized ('cc -O') output
> > is identical, plus these two errors:
> >
> > #error "Left shift of integers of type long long does not work!!"
>
> This
Paul Eggert wrote:
mwoehlke <[EMAIL PROTECTED]> writes:
#error "Right shift of integers of type char does not work!!"
#error "Casts from char to short works by zero-extend!!"
#error "Casts from char to int works by zero-extend!!"
#error "Casts from char to long works by zero-extend!!"
Paul Eggert wrote:
Here are some proposed changes to the gnulib allocsa and vasnprintf
modules prompted by the needs of porting coreutils to Tandem NSK
(OSS), along with modernizing the code to use the newer macros like
AC_TYPE_LONG_LONG_INT rather than the older macros like
gl_AC_TYPE_LONG_LONG.
Sorry about combining the two ideas into a single patch. Since the
first part has been installed, here's the second proposed part, which
I'm creating so that Bruno doesn't have to go to the work of creating
it.
2006-10-11 Paul Eggert <[EMAIL PROTECTED]>
Don't assume that 64-bit signed
mwoehlke <[EMAIL PROTECTED]> writes:
#error "Right shift of integers of type char does not work!!"
#error "Casts from char to short works by zero-extend!!"
#error "Casts from char to int works by zero-extend!!"
#error "Casts from char to long works by zero-extend!!"
#error "Casts from ch
Bruno Haible wrote:
Matthew,
The citation in
http://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00062.html
looks like it explains why no 'long long' type exists although the machine
would support it. Are you sure the machine supports '[signed] long long'?
Before we engage on a change as
Matthew,
The citation in
http://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00062.html
looks like it explains why no 'long long' type exists although the machine
would support it. Are you sure the machine supports '[signed] long long'?
Before we engage on a change as large as this, can yo
Paul Eggert wrote:
> Here are some proposed changes to the gnulib allocsa and vasnprintf
> modules prompted by the needs of porting coreutils to Tandem NSK
> (OSS), along with modernizing the code to use the newer macros like
> AC_TYPE_LONG_LONG_INT rather than the older macros like
> gl_AC_TYPE_LO
Here are some proposed changes to the gnulib allocsa and vasnprintf
modules prompted by the needs of porting coreutils to Tandem NSK
(OSS), along with modernizing the code to use the newer macros like
AC_TYPE_LONG_LONG_INT rather than the older macros like
gl_AC_TYPE_LONG_LONG. I haven't tested th
23 matches
Mail list logo
