https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48140
Albert Chan changed:
What|Removed |Added
CC||albertmcchan at yahoo dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33167
Albert Chan changed:
What|Removed |Added
CC||albertmcchan at yahoo dot com
--- Comment
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 e
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
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 ?
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
