-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for C99 %a and %A printf format support. #1198
Add support for C99 %a and %A printf format support. #1198
Conversation
…ting point constants in hexadecimal format. The code is written to mimic how GNU glibc does it
This is to help resolve issue #1066 |
Please see this to confirm what I am doing with the 64-bit double floating point type: https://en.wikipedia.org/wiki/Double-precision_floating-point_format |
It requires extend to scanf and for 80-bit long double. There is attribute SF_LONG_DOUBLE which handle 80-bit long double format. NOTE: it must be part of math library to not load FP until floating data are used. I looked into math library and it looks like there is already implemented read of hexadecimal FP format in strtod.c to support C99. Anyway it will need review at all. |
The issue does not mention %la, it mentions only %a, that is what this pull is meant to resolve. Also my version does not need the math library :) I figured other variations could be added later, this is just the first step. Handle this code however you think is best. |
@jmalak Should I revise my pull request here with additional code changes or are you going to handle it? I think the best way to full the request is to add %a support in whatever manner you think best and then worry about %la later. Since %a prints out the various fields of the float without needing to try to convert to decimal it really is possible to implement without needing the full floating point or math library and %la can do the same given the Intel 80-bit long double format as well. Or perhaps it might be appropriate to put into the math library anyway? |
The request is general without implementation knowledge, that it is not important what was exactly requested. There are still a few important C99 features missing which are more important then %a/%A format specifier. I am working on C99 compound literals and designated initializers which are most important, but it is going slowly, it is mainly about study of compiler code. C compiler is hand-crafted parser that there are many specific construct etc. |
@jmalak I can't even get printf() to accept any long double parameters. They always seem to come in as type double! See DOSLIB test program: https://github.com/joncampbell123/doslib/blob/master/hw/dos/testprna.c GCC 9.3 output, x86_64, GNU GLIBC printf():
Open Watcom compiled DOS program with this %a implementation (result is the same regardless of 16-bit, 32-bit):
If the call really were passing a long double to printf() in OW, the second result given the current %a implementation would produce some erronous bogus output as a result of interpreting an 80-bit long double as 64-bit double. So as it stands, it seems there's no point at this time in worrying about %La vs %a because at least as the test program shows, they're the same datatype. Note the GCC GLIBC output makes sense in that the 80-bit format has the explicit leading bit that the 32/64-bit floats omit as the "implied bit". So it's showing the not-implied bit as 0x8 with an exponent. |
It is default setup that it uses 64-bit double as long double. |
First, why doesn't that appear when I run the compiler and it prints out all the options? Second... "Error! E1119: Internal compiler error 136"? 🤨 %write tmp.cmd -fr=nul -fo=dos86c/.obj -i.. -i"../.." -e=2 -zu -zq -mc -d0 -s -bt=dos -oilrb -os -wx -0 -dTARGET_MSDOS=16 -dMSDOS=1 -dTARGET86=86 -DMMODE=c -q -x -i"/usr/src/open-watcom-v2-upstream/rel/h" -fld testprna.c |
That "Zoiks" (heh, someone likes Scooby Doo) is in ./cg/intel/i86/c/i86splt2.c line 357. It's the default case for N_CONSTANT because there isn't one for long double. It needs a case statement for "FL" (long double) below "FD" (double). |
The segfault according to "WD" is in insutil.c line 134 in function FindNameConf(). Parameter "name" is NULL. |
The 32-bit compiler wcc386 doesn't throw any obvious errors but then any function call that passes a long double as a parameter causes the program to crash after that point, whether or not that function does anything with it. At least when compiled as a 32-bit DOS program. |
So to answer my own question, -fld isn't documented because 80-bit "long double" support within the compiler is totally broken. Right? :) |
Even if I just pass the long double constant to printf() directly it still triggers that error (16-bit wcc) or causes the program to crash (32-bit wcc386). In the compiler's current state it is impossible to pass a long double to printf() and therefore it is pointless to try to implement %La or %LA any differently from %a and %A at this time. |
No, it must be ready to use 80-bit LD in CRTL. The CRTL support 80-bit LD even if compiler not yet. |
reimplemented pull request "Add support for C99 %a and %A printf format support." #1198 this is final change to add new specifier processing into math library it supports also 'L' prefix for long double type and is ready when C compiler will fully support 80-bit long double type
I reimplemented it to math library including long double |
This adds support for printing point constants in hexadecimal format using %a and %A. The code is written to mimic how GNU glibc does it.
Feel free to clean it up as needed.