[Bug c/48140] fmod() not accurate to double precision?

[albertmcchan at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48140

Albert Chan  changed:

   What|Removed |Added

 CC||albertmcchan at yahoo dot com

--- Comment #4 from Albert Chan  ---
I think fmod is accurate
Gcc cannot do exact fmod(1e9, 2*pi)

it can only do fmod(1e9, 0x1.921f54442d18p+2) = 0.57739546248310347

which is exactly what gcc returns

in fact, it is VERY accurate
If we do remainder calculation in steps:

quotient = floor(1e9 / (2 pi)) = 159154943
remainder = 1e9 - quotient * 0x1.921f54442d18p+2
= 0.57739543914794922

doing in steps under-counted 210,184,384 ULP

[Bug c/33167] Hex constant characters with \x escape not parsing correctly

[albertmcchan at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33167

Albert Chan  changed:

   What|Removed |Added

 CC||albertmcchan at yahoo dot com

--- Comment #4 from Albert Chan  ---
if gcc hex escapes is right, then gcc octal escape is wrong
(it just look at first 3 octals)

"\123" = "S"
"\0123" = "\n3"  ??
"\00123" = "\1" "23" ??

personally, i like this octal escape "bug"

[Bug c/33167] Hex constant characters with \x escape not parsing correctly

[albertmcchan at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33167

--- Comment #6 from Albert Chan  ---
if gcc hex escape AND octal is right, does it contradict comment #1 ?

"octal or hexadecimal ... longest sequence that constitute escape sequence"

I noticed OLD python (2.0) also use the C rule regarding hex escapes,
but later switch to a more sensible 2 hex = 1 byte rule (\xX or \xXX)

[Bug debug/83861] New: sscanf %lg conversion bug

[albertmcchan at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83861

Bug ID: 83861
   Summary: sscanf %lg conversion bug
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: albertmcchan at yahoo dot com
  Target Milestone: ---

double x;
sscanf("6.2e-323", "%lg", &x);

x were set to 6e-323, which was 1 ULP short

correct value should be 6.4e-323

this bug failed even with the latest gcc 7.1 that comes with
Strawberry Perl 5.26.1.1 32-bits for Windows

[Bug c/83861] sscanf %lg conversion bug

[albertmcchan at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83861

--- Comment #2 from Albert Chan  ---
hello Andrew,
can you explain what is libc ?
is it part of gcc ?
where should this sscanf bug be sent ?

[Bug c/84815] New: gcc fwrite failed write to stdout in binary mode (Win7)

[albertmcchan at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84815

Bug ID: 84815
   Summary: gcc fwrite failed write to stdout in binary mode
(Win7)
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: albertmcchan at yahoo dot com
  Target Milestone: ---

#include 
#include 
#include 
#include 

int main()
{
size_t n = 64*1024; // code ok if below 64k
char* buf = malloc(n);
if (buf == NULL) return 1;
memset(buf, 'O', n);
buf[n-1] = 'X'; // signal for last byte

setmode(STDOUT_FILENO, _O_BINARY);  // <-- this caused the bug

n = fwrite(buf, 1, n, stdout);  // fwrite failed, but why ?
printf("\nfwrite %d bytes\n", n);   // output: fwrite 0 bytes
free(buf);
return 0;
}