Activity for GnuCOBOL
-
Simon Sobisch modified ticket #506
patch for GCSORT (improve and check COBOL performance)
-
Ralph Linkletter posted a comment on ticket #1219
The command line: c:\IBZANIM\COBOL>C:\IBZANIM\WINGNU\BIN\cobc \IBZANIM\COBOL\CEEENV.COB -tC:\IBZANIM\LISTINGS\CEEENV.L ST -oC:\IBZANIM\LOADLIB\CEEENV -fgoto-entry=ok -fno-ec=all -LC:\WINGNU\INCLUDE -ffold-call=upper -L C:\IBZANIM\WINGNU\INCLUDE -O0 -fassign-clause=ibm -fno-gen-c-decl-static-call -fbinary-size=2-4-8 -- tsymbols -fsign=ebcdic -fodoslide -fimplicit-init -fperform-osvs -fmove-ibm -fhostsign -fnotrunc -fn o-recursive-check -fdefaultbyte=00 -fsticky-linkage -fsource-location -Xref -A "-include...
-
COBC signal SIGSEGV
-
Sauro Menna posted a comment on ticket #506
Hi Simon, I've updated the GCSORT version by incorporating the files you sent me. I've released the updates in GCSORT version 1.04.08 (2025-09-21). Thanks for your suggestions and advice. Sauro
-
Saurabh Kumar posted a comment on discussion Contributions
Hello team! It looks like the CI might be broken for macOS, as the failures reported there are not reproducible locally with the same commands. I noticed there are some open PRs that fix it. Could someone please take a look and consider reviewing and merging them to help unblock progress? Thanks!
-
László Erdős posted a comment on discussion Help getting started
Hello, The Raylib C library is also based on BGI. https://en.wikipedia.org/wiki/Raylib https://github.com/raysan5/raylib There are Raylib bindings and wrappers for many programming languages: https://github.com/raysan5/raylib/blob/master/BINDINGS.md Also for COBOL: https://codeberg.org/glowiak/raylib-cobol Our GNU Cobol Contributions also include an example using Raylib (author: Giancarlo Canini): https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/samples/raylib_painter However, the main...
-
Michael Del Solio posted a comment on discussion Help getting started
Now, we have some more functions available: >>SOURCE FREE IDENTIFICATION DIVISION. PROGRAM-ID. GFXDEMO. DATA DIVISION. WORKING-STORAGE SECTION. 78 C-BLACK VALUE 0. 78 C-BLUE VALUE 1. 78 C-GREEN VALUE 2. 78 C-CYAN VALUE 3. 78 C-RED VALUE 4. 78 C-MAGENTA VALUE 5. 78 C-BROWN VALUE 6. 78 C-LIGHTGRAY VALUE 7. 78 C-DARKGRAY VALUE 8. 78 C-LIGHTBLUE VALUE 9. 78 C-LIGHTGREEN VALUE 10. 78 C-LIGHTCYAN VALUE 11. 78 C-LIGHTRED VALUE 12. 78 C-LIGHTMAGENTA VALUE 13. 78 C-YELLOW VALUE 14. 78 C-WHITE VALUE 15. 01...
-
Ok, I think we are on the good way with winbgm/putpixel() on SuperBOL-AIO-distribution :-) 1) Library (always check it with virustotal.com) and graphics.h from: https://github.com/dbautsch/winbgim/releases/tag/6.0a 2) Rename libbgi64.a to libbgi.a and put it into: C:\Users\YOURUSER\AppData\Local\GnuCOBOL\mingw64\lib\gcc\x86_64-w64-mingw32\13.2.0 3) Put graphics.h (from the Source Code ZIP file) into: C:\Users\YOURUSER\AppData\Local\GnuCOBOL\mingw64\lib\gcc\x86_64-w64-mingw32\13.2.0\include 4) Compile...
-
Ok, I think we are on the good way with winbgm/putpixel() on SuperBOL-AIO-distribution :-) 1) Library (always check it with virustotal.com) and graphics.h from: https://github.com/dbautsch/winbgim/releases/tag/6.0a 2) Rename libbgi64.a to libbgi.a and put it into: C:\Users\YOURUSER\AppData\Local\GnuCOBOL\mingw64\lib\gcc\x86_64-w64-mingw32\13.2.0 3) Put graphics.h (from the Source Code ZIP file) into: C:\Users\YOURUSER\AppData\Local\GnuCOBOL\mingw64\lib\gcc\x86_64-w64-mingw32\13.2.0\include 4) Compile...
-
Vincent (Bryan) Coen committed [r5670] on Code
1218
-
Fixes to chapter 6 and 8
-
done
-
Chuck Haatvedt posted a comment on discussion Help getting started
PDCursesMOD does provide a Windows graphic version called WINGUI. With this you should be able to access individual pixels using the setpixel function. There are some serious considerations How to Access Pixels in WinGUI To draw or manipulate individual pixels, you must bypass the curses abstraction and use the underlying Windows API: Get the Device Context (HDC): You need a handle to the window's device context to perform graphical operations. In the WinGUI port, you can often obtain the relevant...
-
Thank you very much. I searched now for a 64-bit version and found this one for MinGW: https://github.com/dbautsch/winbgim/releases/tag/6.0a The binary libbgi64.a looks ok while checked with virustotal (please recheck if you want to use it). We need to extract the graphics.h from the file "Source code (zip)" and put it into include folder of the SuperBOL-installation ... and we need to put ibbgi64.a into the libs folder... Tomorrow (or within the next days) I will try to compile the example from...
-
Eugenio Di Lorenzo created ticket #1218
Fixes to chapter 6 and 8
-
1215 & 1216
-
Sincere thanks for this answer, which I think is exhaustive, even if it doesn't meet my goals. Thank you. At this point, I'd say I have to abandon this approach. I remember that the older BASIC had some simple statements to draw, for example, a circle, a square or a line etc. in a graphical way. 10 SCREEN 1 ' set graphic mode 20 XC = 160 : YC = 100 : R = 50 'Center and Radius 30 FOR A = 0 TO 6.28 STEP 0.1 40 X = XC + R * COS(A) 50 Y = YC + R * SIN(A) 60 PSET (X,Y) ' draw a pixel 70 NEXT A If anyone...
-
Fixes for missing features as RW standards
-
RW - Report Writer - Feature requests
-
RW - Report Writer - Feature requests
-
Some fix and update to TRIGONOMETRIC FUNCTIONS
-
Some fix and update to USAGE and Chapter 10.
-
Some fix and update to USAGE and Chapter 10.
-
Some fix and update to USAGE and Chapter 10.
-
Some hints I found to this topic: putpixel() is part of the Borland BGI Graphics emulation (based on https://en.wikipedia.org/wiki/Borland_Graphics_Interface ): https://winbgim.codecutter.org/ But unfortunately this is just für MinGW-32 and so it does not work with the SuperBOL-distribution which is shipped with MinGW-64. It should work with the distribution of Arnold because this is based on MinGW-32 but this comes without g++ (C++ compiler). But g++ ist needed because in the graphics.h the file...
-
Xavier Del Campo Romero posted a comment on ticket #518
I have prepared the following minimal reproducible example in a tarball that fails to build on GnuCOBOL r5627: $ make cobc -c -o foo.o foo.cbl foo.cpy:2: warning: handling of FUNCTION PROTOTYPE is unfinished; implementation is likely to be changed [-Wunfinished] 1 | identification division. 2 > function-id. foo is prototype. 3 | data division. 4 | linkage section. cobc -c -o main.o main.cbl foo.cpy:2: warning: handling of FUNCTION PROTOTYPE is unfinished; implementation is likely to be changed [-Wunfinished]...
-
According to cobc-dev.7 (sourceforge.net): GnuCOBOL, insofar as is practical, requires compilers that support C99 and environments that support the current Posix standard. The rest of the documentation encourages the use of some C99 features, while discouraging others such as VLAs or _Generic (although _Generic was in fact introduced by C11, not C99). What do you think of trying to adjust configure.ac to do that, similar to the check for gc_cv_keyword_inline? Given the fact that the project is explicitly...
-
OK, for making a patch, but then the correct option, which is: -fno-trunc, will be present: Only on page 10 (Chapter 2.1.7 Debug switches) Only on page 38 (Chapter A.3 Compiler options) In both chapters ? The new description will be Do not truncate binary fields according to PICTURE. Allow numeric field overflow; non-ANSI behaviour.
-
The first one is correct for the description but is an old version (maybe still available for backward compatibility but should be removed in GC4) of the second option. Patch Welcome.
-
Yes, of course, looking at https://www.geeksforgeeks.org/c/putpixel-function-c/ I can see that there are some calls that need to be made before using the function. But the problem is something else. These calls, however, seem to look for a library that I don't know what it is and where to find. Replacing pdcurses-wingui.dll and copying it to pdcurses.dll is also impossible because I'm using the AIO compiler available in SuperBOL and VSCode. This compiler doesn't use pdcurses, but libncursesw.dll.a...
-
The GnuCOBOL manual gnucobol.pdf has two similar options: -fnotrunc = Do not truncate binary fields according to PICTURE. ( at page 10) -fno-trunc = allow numeric field overflow; non-ANSI behaviour ( at page 38) I suspect that both are equivalent in terms of results, and therefore one of them is incorrect. Am I wrong ?
-
Anonymous posted a comment on discussion Help getting started
There are prerequisites to calling putpixel Initialization: You must initialize the graphics system using initgraph(&gd, &gm, ""); before calling putpixel. Where: gd = Graphics Driver -> A pointer to an integer specifying the driver. Using the macro DETECT (set to 0) allows the system to automatically pick the best driver for your hardware. gm = Graphics Mode -> resolution "" (Path to Driver): Windows: EasyX SDL_BGI
-
I believe that you will be required to use the pdcurses-wingui.dll and copy it to pdcurses.dll Chuck Haatvedt
-
Some further adjustments to the Literals chapter
-
BINARY-DOUBLE is a 64bit native integer (think of long long), so you dont' have any decimals. You'd want to check FLOAT-LONG (a native double) as well as FLOAT-DECIMAL-34 (in theory also FLOAT-BINARY-128, but without checking I guess we don't implement that so far).
-
As far as I see: you want an int, so BINARY-LONG that function seems to be a header-implementation, so you'd add --include graphics.h
-
I'd like to use the putpixel() C function from a GnuCOBOL program. To draw geometric shapes on the screen: a circle, a rosette, etc. See: https://www.geeksforgeeks.org/c/putpixel-function-c/ Possibly without using a C wrapper but using something like this in the GnuCOBOL program: >>SOURCE FREE IDENTIFICATION DIVISION. PROGRAM-ID. PIXELC. DATA DIVISION. WORKING-STORAGE SECTION. 01 wX BINARY-SHORT. 01 wY BINARY-SHORT. 01 wC BINARY-SHORT. PROCEDURE DIVISION. move 04 to wX wY wC *> void putpixel(int...
-
I tried using COMP-2 for the intermediate results, but nothing changed; cases "a." and "b." remain approximate (0.999999999999). I tried using BINARY-DOUBLE, and the result is completely wrong. See cases "a." and "b." below. SIN 90 gives zero instead of +1 (or even 0.9999999999). BINARY-DOUBLE is as if it doesn't handle decimals. >>SOURCE FREE IDENTIFICATION DIVISION. PROGRAM-ID. TESTTRIGONOMETRIC2. DATA DIVISION. WORKING-STORAGE SECTION. 01 wRESULT BINARY-DOUBLE. *> comp-2. *>PIC s999v999999999999999999999999....
-
We do support the IBM and MF directives already, so you may be able to enforce special options that way. For missing ones (where we can point to IBM/MF docs) those can be added, if missing. But for a common set of arguments (or a very long input list in DOS or other small environments where you cannot pass that much arguments on the command line) the @file syntax (that then includes for example listing options or fine-tuned compiler options for every source) helps a lot and brings us nearer to "common...
-
Thanks to GMP we don't have much approximation in calculations and commonly no truncation in intermediate values... the only side issues are: when storing intermediate results and get them back we enforce partial issues, when using them further we always get approximation issues wRadians PIC s999v999999999999999999999999 - you may try long-double or long floating point usages and see how those change the final result we can be much slower when using lots of intermediate values [especially when they...
-
I made this observation some time ago, and I'll repeat it. In some cases, a certain source program MUST be compiled with certain options, otherwise it won't work correctly. Example: -fno-trunc; -fsingle-quote; -fcomplex-odo In a mainframe environment, using the IBM compiler, you can insert compiler options directly into the source code at the top of every line. You add a line starting with CBL, followed by all the options the program needs. This way, anyone who uses that source code will know how...
-
I've made a couple of interesting discoveries. Trigonometric functions as SIN and COS allow "argument," which can be either a numeric literal or a numeric identifier, or even an arithmetic expression. This last option isn't yet documented in the PG, but I'll release an update soon. If I use an arithmetic expression, the values of SIN and COS functions are corrected and are no longer "approximated." For example, SIN 90 = 1, not 0.9999999999999 In the following examples it is the "c." case which always...
-
Some fix and update to TRIGONOMETRIC FUNCTIONS
-
I've made a couple of interesting discoveries. Trigonometric functions as SIN and COS allow "arguments," which can be either a numeric literal or a numeric identifier, or even an arithmetic expression. This last option isn't yet documented in the PG, but I'll release an update soon. If I use an arithmetic expression, the values of SIN and COS functions are corrected and are no longer "approximated." For example, SIN 90 = 1, not 0.9999999999999 In the following examples it is the "c." case which always...
-
Add a compiler configuration/command line options file
-
Add a compiler configuration file
-
Let's revamp this issue with a more "standard" approach --> we should implement cobc @/path/to/some/file with the file having command line options - same as gcc.
-
We do have two different things here: io-status: depending on the COBOL standard and vendor/product version you have a different set; GnuCOBOL returns ISO 2026 codes runtime library callable functions like CBL_xyz: depending on the vendor/product version you have, the behaviour is slightly differently (especially how file and folder names are interpreted) and the return codes differ much more For 1: we need a patch that allows dialect specific return codes; trunk has an implementation but that needs...
-
@smenna Can you please review/comment?
-
... we don't support MF prototypes - patches welcomed for those, the non-standard extension for the standard feature itself is tracked under [feature-requests:#509]
-
Support for MF cbltypes.cpy and cblproto.cpy
-
GnuCOBOL fully supports prototypes as far as I know and also internally creates them when compiling. What we don't have yet ("just needs a patch") is someone that writes the prototype information to a specified file and reads it from there as well. Those are heavily used for example in COBJAPI since years. Moving our existing internal checks for runtime library calls (system.def) in cobc to function prototypes would already be possible and very useful, as we currently only do a partial check on those...
-
GnuCOBOL does not need newer options but may use them where reasonable. configure checks with whatever flags you pass to it and may enable/disable some features that way. Therefore I'd always specify the newest supported option. Adding it to default CFLAGS will need a test in configure in any case - so we should first check if the void function declaration and pointer use works or not - and only try to work around that by specifying a std as-needed (and then try gnu17 / c17 / gnu11 /c11 / gnu99 /...
-
Build breaks with gcc-16 unless -std < c23 is specified
-
Thank you for the quick reply. According to my tests, -std=gnu99 also worked as expected, so maybe at this point GnuCOBOL should add this flag to its default CFLAGS in order to maintain compatibility with modern compilers. OTOH to my understanding GnuCOBOL does not rely on any C11 or C17 features, so IMHO it would be wiser to rely on -std=gnu99 rather than -std=gnu17 in order to maintain compatibility with older compilers. WDYT @sf-mensch ?
-
Support for MF cbltypes.cpy and cblproto.cpy
-
Correct - while that was GCC15 that changed the default, see https://gcc.gnu.org/gcc-15/porting_to.html#c23 Thanks for the report which is more on topic than the existing one, so I've closed the older in favor of this. Note: The same issue exists with previous (released) versions. I have at least a partial improvement, but the general issue with "any number" - as you've described, is hard to get completely right, To compile for now, please add CFLAGS="-std=gnu17" for the configure line and, if needed...
-
GnuCOBOL make faills on Fedora 42 (C23)
-
now duplicated by [bugs:#1214] which is a bit more about the real topic, so closing this in favor of the newer one
-
Support for Micro Focus' COBRTxxx status codes
-
Build breaks with gcc-16 unless -std=gnu99 is specified
-
Denis HUGONNARD-ROCHE created ticket #73
Sine And cosine optimization proposal
-
Some fixes on Trigonometric FUNCTIONS and others
-
1213
-
Some fixes on Trigonometric FUNCTIONS and others
-
Some fixes on Trigonometric FUNCTIONS and others
-
Some fixes on Trigonometric FUNCTIONS and others
-
Hi Simon After digging , i see only one "solution" : check if angle is "close" to pi/2 . it means adding a test like this " if abs (angle -P/2) is < Epsilon then angle is PI/2" (epsilon = 0,...001) Tell me if you want me to try this solution or we leave as, as, you said it's normal for floatting point to be not 100% accurate . Other : We have to increase the code coverage of the trigonometric functions by adding additional tests In digging i have reshape cos and sin function that appear about 12%...
-
... and the same considerations apply to the ACOS ASINand ATAN functions.
-
OK, then all compiler agree with the standard here (apart from MF reasoning that as a statement) and we can close this; note that cobc -std=ibm will likely display identical as IBM (as that dialect disables "pretty printing).
-
plus/minus need a space before numbers to be recognized as arithmetic operator
-
Mickey White posted a comment on ticket #829
On IBM the first program errors out the same. The second program compiles with warnings , but does not display the decimal point in the answer. If change 9v9 to 9.9 decimal is displayed.
-
TAN "should" not raise an error as COS should not result in zero - those functions return an approximation, so something like .0000000000000000000000000000000000000000000000000000000000000001 as intermediate values is totally fine; we possibly should round (not necessarily truncate) in case of moving from the internal mpf to the mpz.
-
Where do we stand with that? MF errors on that with "recognizing" it as an unknown verb GnuCOBOL says "error: syntax error, unexpected Literal" gcobol says <source>:18:33: error: syntax error, unexpected numeric literal 18 | compute num-4 = (3/2)+3 | ^~ cobol1: error: failed compiling <source> ... and my guess is that IBM will error similar. So - just close this as "not a bug"?
-
Hi Going on the test (with no degrees conversion ) regarding the following program and the results , The problems are : - SIN when muliptle of PI ---> should give 0 - COS when multiple of PI/2 ---> should give 0 - TAN when multiple of PI/2 ---> should raise a exception divide by zero when multple of PI ---> should give 0 i tried a simple trick with COB_MPF_PREC = 4096 instead of 2048 --> same results. i'll dig into the way of how cob_mpf_sin compute the angle to be given to the series (as it is used...
-
I have added the proposal link into the main post above. I would appreciate it if I could get a review from the community. Comments can be added directly on the document. I am sorry for the delay, I was not well.
-
I have added the proposal link into the main post above. I would appreciate it if I could get a review from the community. Comments can be added directly to the document. I am sorry for the delay, I was not well.
-
I have added the proposal link into the main post above. I would appreciate it if I could get a review from the community. I am sorry for the delay, I was not well.
-
Hello everybody! My name is Saurabh Kumar. I am a self-taught computer programmer from India with interest in Compilers and low-level development. I am one of the core contributors of the LFortran project, a modern, interactive and open-source LLVM based Fortran compiler. GnuCOBOL currently has no support for handling OO code and exits with an array of unhelpful error messages due to the lack of parsing support for OO code constructs. I propose to implement initial parsing, AST and codegen support...
-
Tangent function possibly nees a zero-checl
-
I'm not sure - that only happens in cases of calculations with exactly pi, which we don't have. The standard says because of this that the return value is only an approximation. GMP docs say that we'd get a signal (crash) if that happens - can you produce a crash here? If yes, we need a check if (mpz_sgn (vf2) == 0) (not sure what we should do then, according to the standard we may should set vf2 to 0.000000000000000001 in that case), but otherwise pointing this out in a comment could be useful.
-
Tangent function
-
For a few GnuCOBOL users on this site here are my most recent additions to providing IBM zOS LE services with GnuCOBOL. Attached is CEE3GTST and a test harness CALLGTST Included are CEEGTST and CEEFRST This is a GnuCOBOL implementation of the above LE services. The real zOS implementation uses big endian. The GnuCOBOL implementation uses little endian. If a failure in either is detected I emit the actual zOS error message text This is a cobcrun example C:\IBZANIM\LOADLIB>COBCRUN CALLGTST C:\IBZANIM\LOADLIB>COBCRUN...
-
For a few GnuCOBOL users on this site here are my most recent additions to providing IBM zOS LE services with GnuCOBOL. Attached is CEE3GTST and a test harness CALLGTST Included are CEEGTST and CEEFRST This is a GnuCOBOL implementation of the above LE services. The real zOS implementation uses big endian. The GnuCOBOL implementation uses little endian. If a failure in either is detected I emit the actual zOS error message text This is a cobcrun example C:\IBZANIM\LOADLIB>COBCRUN CALLGTST C:\IBZANIM\LOADLIB>COBCRUN...
-
For a few GnuCOBOL users on this site here are my most recent additions to providing IBM zOS LE services with GnuCOBOL. Attached is CEE3GTST and a test harness CALLGTST This is a GnuCOBOL implementation of the above LE services. The real zOS implementation uses big endian. The GnuCOBOL implementation uses little endian. If a failure in either is detected I emit the actual zOS error message text This is a cobcrun example C:\IBZANIM\LOADLIB>COBCRUN CALLGTST C:\IBZANIM\LOADLIB>COBCRUN CALLGTST CALLGTST...
-
yes strange behavior i did a little more test on sinus function . IDENTIFICATION DIVISION. PROGRAM-ID. TESTTRIGONOMETRIC. DATA DIVISION. WORKING-STORAGE SECTION. 01 wRESULT PIC s99v9999999999999999999999999. 01 wRadians PIC s999v999999999999999999999999. PROCEDURE DIVISION. compute wRadians rounded = (90 * FUNCTION PI) / 180 move FUNCTION SIN(wRadians) to wRESULT DISPLAY 'SIN 90: ' wRESULT display 'SIN 90: ' FUNCTION SIN(wRadians) display '---------------------------------' compute wRadians rounded...
-
Yes you are right. But there is another question. The OPTIONSparagraph of ID DIVISIONit seems like it's not working well. >>SOURCE FREE IDENTIFICATION DIVISION. PROGRAM-ID. TESTROUNDED. *> ************************************************************** OPTIONS. DEFAULT ROUNDED MODE IS NEAREST-EVEN. *> ************************************************************** DATA DIVISION. WORKING-STORAGE SECTION. 01 wRESULT PIC s99v9999999999999999999999999. PROCEDURE DIVISION. *> following DISPLAY should give...
-
I tried with the value 3.1416 but the results are worse See following program. >>SOURCE FREE IDENTIFICATION DIVISION. PROGRAM-ID. TESTTRIGONOMETRIC. DATA DIVISION. WORKING-STORAGE SECTION. 01 wRESULT PIC s99v9999999999999999999999999. 01 wRadians PIC s999v999999999999999999999999. 78 wPi value 3.1416 PROCEDURE DIVISION. compute wRadians rounded = (90 * FUNCTION PI) / 180 move FUNCTION SIN(wRadians) to wRESULT DISPLAY 'SIN 90: ' wRESULT display 'SIN 90: ' FUNCTION SIN(wRadians) compute wRadians =...
-
you can easily try on your own online: https://cobol.godbolt.org/z/sj5rYx67x (if you do that then you get a non-integer in every case - otherwise you'd have the expected values with gcobol)
-
What happen if you use 3.14 (or 3.1416) instead of FUNCTION PI ? Or define PIE as PIC 9.9999 VALUE 3.141 Numeric display to participate with a finite definition of PI
-
What happen if you use 3.14 (or 3.1416) instead of FUNCTION PI ?
-
The simple "rounded" should be enough, no? Side note: that floating result shows that we can improve the optimizing part - it currently stops when seeing division, but as long as all are constants this should still be handled in the optimizer (for a test that cannot be optimized easily: MOVE 3 TO wRESULT. compute wRESULT = (1 / wRESULT ) *3.)
-
same error if use compute wRESULT = ( 1 / 3 ) * 3 display '1 / 3 * 3 = ' wRESULT displays: 1 / 3 * 3 = +00.9999999999999999999999999 wich type of "ROUNDED" option is needed ?
-
same error if use compute wRESULT = ( 1 / 3 ) * 3 display '1 / 3 * 3 = ' wRESULT displays: 1 / 3 * 3 = +00.9999999999999999999999999 wigh kind of "ROUNDED" option is needed ?
-
That's all floating point calculation as Pi is involved and there is no exact representation of that. If you use MOVE then the intermediate result field is the "most exact representation of the floating point and MOVE truncates, not rounds, so you don't get 1 but "nearly one". We could round directly after using the trigonometric functions, if we do that for example to the 20th position then we're still much more detailed than other floating-point environments but would get your expected 1/0 result....
-
I'm getting some strange results when using some trigonometric functions. Is everything correct? Following program: >>SOURCE FREE IDENTIFICATION DIVISION. PROGRAM-ID. TESTTRIGONOMETRIC. DATA DIVISION. WORKING-STORAGE SECTION. 01 wRESULT PIC s99v9999999999999999999999999. 01 wRadians PIC s999v999999999999999999999999. PROCEDURE DIVISION. compute wRadians rounded = (90 * FUNCTION PI) / 180 move FUNCTION SIN(wRadians) to wRESULT DISPLAY 'SIN 90: ' wRESULT display 'SIN 90: ' FUNCTION SIN(wRadians) compute...
-
CDF others Directives and others small fix
-
1211
-
The next part of the implementations are: adding bit-offset and size (there's an automatic padding to a full byte for the next data-item in a record that isn't USAGE BIT, but we can have 8 items and therefore need to store the bit-offset and bit-size), most likely to cb_field, we can store that in a single char (lower and upper nibble) to not add two chars to the struct, but we may also use defined bits 1-7 for offset and the rest for size or, if it is small as well also reserve stuff for something...
-
Into the first post of this thread I updated the documentation with last version n.12. Added: CobGDB version number on program screen new J Jump command Scroll symbols and scroll options on source listing As always you can find the new product and updated documentation at https://github.com/marcsosduma/cobgdb
