Assertion failed: win, file ../pdcurses/inopts.c, line 207

[David Wall]

Just rebuilt 3.2 with the latest Mingw gcc9 gmp621 vbi211 & pdc431 & got the above - I can't find where this occurs although certainly there is some reference to inopts inside the pdcurses.dll file.
I got the same using pdc430 which 'used' to build / compile & run fine - so where did I go wrong ??.
I've attached the build log and cobc ver

[David Wall]

Went back to the older Mingw gcc6.3 & gmp620 vbi201 & pdc430 & all working again.
Will laboriously update everything individually till I find the culprit.
AND - will be enormously annoyed when I end up discovering - IT WAS ME..
I'd better not.. And all that will be tomorrow.

[David Wall]

Rebuilt 3.2 with the latest Mingw gcc9 & GMP620 & VBI201 & PDC430 & still working - so we can rule out the Mingw as being the problem - will probe deeper - ooh yes please !!.

[David Wall]

OK - Final build.
Mingw gcc9 (latest) + GMP621 + VBI211 + PDC431 & 3.2 & it all works as expected.

I'm sort of assuming the fact that PDC431 had changed the initscr & GnuCOBOL couldn't find it caused the error - but having edited the curses.h has fixed that.

I suppose it 'could be' put down to my fault - but how was I to know the initscr had changed.
Maybe I'll check the curses.h file on future PDC versions in case it changes again.

[Simon Sobisch]

The referenced line is https://github.com/Bill-Gray/PDCursesMod/blame/bd8fa58ea7f0e0d45c682af43e80d9994360cf97/pdcurses/inopts.c#L207 it is a null check for the use of the first parameter passed to keypad(), which is in since PDCursesMod 4.3.0.
We call that with a parameter of stdscr in cob_scr_init which is setup by calling initstcr, which is directly done before.

So... I guess either your build of PDCursesMod was broken (or the current 4.3.1 version has a bug, or something zeroes out stdscr - but even then it would have to happen bet) or you did not use the same PDCurses defines (CHTYPE, UTF8 WIDE) when building PDCursesMod and when building GnuCOBOL.

[David Wall]

Well - since there are 4 flavours of recent PDC's - 32bit console & gui & 64bit console & gui - I build them all at the same time & save the .dll & .a files for the 4 versions.
Then when the compiler is being built & which version is required for it is selected the appropriate saved files are copied into the Mingw\bin folder for copying across to the final compiler\bin folder.
This 'has' worked fine for all versions since the 4 flavours have been introduced.
The inopts file in the pdc pdcurses folders are identical 430 & 431 so it's not that.
I wonder if it's got anything to do with the later MIngw - but again I doubt it.

More investigation - a mere traffic jam :) Thanks Simon.

[Arnold Trembley]

As I understand it, an "ASSERT" in software development is a code check that basically says, If you are here, then (this) should be true. If the assertion is not true, that's reported as an error. The link Simon provided points to an assertion to verify that PDCursesMod is running in Windows.

What would happen if you were running a test COBOL program in the MinGW msys shell? Would PDCursesMod know it was running in Windows, or might it assume it was running in Linux?

[Simon Sobisch]

This checks that it did got a curses window passed (it actually only checks "this pointer is not NULL), in our case it gets the main one: "stdscreen".

PDCurses code doesn't care about "WindowsTM".

[Simon Sobisch]

Actually in PDCursesMod there are 6 ports that are reasonable to use/test: wincon, wingui, vt (the later is the one that Microsoft is pushing, especially reasonable to use in conjuction with "modern terminals" like the one that is integrated with powershell or vscode.
But the good thing: you only need 1 link library for all of those and don't need to relink any programs (because the link is in libcob, not in the programs) and also don't need to relink libcob - because as long as UTF8/WIDE/CHTYPE is defined identical you can just swap the pdcurses dll's (which is the reason that I highly suggest to build each three for the ABI set you are interested in, possibly for 32+64bit) and keep them with their port name in bin (for example pdcurses_vt.dll) - then you can just copy the one you like to use over the existing pdcurses.dll and are fine to go.

[David Wall]

I just rebuilt the old Mingw gcc6 with pdc431 & got the following error in a previously working program:

COBOLPR1.cob:199: attempt to reference unallocated memory (signal SIGSEGV)
Last statement of "PROGRAM" was at line 199 of COBOLPR1.cob
Started by COBOLPR1.exe COBOLPR1.COB
Press any key to continue . . .

Funny enough line 199 is the first Diaplay statement of the program.

cobc -ver shows:
native EBCDIC : no
extended screen I/O : not found <<<<<<<<<<<<????????????????
variable file format : 0

I've been doing my builds using the same script each time -

Had a look thru the pdcurses.dll's created & found that instead of having what was a previous standard initscr_x32 is now initscr_x32_4301 - having been changed in the curses.h in the pdcurses431.zip I downloaded a few days ago.

Wonderful - NOT MENTIONED ANYWHERE - we have to now specify :
-Dinitscr=initscr_x32_4301 in the compiler build.

I did this & all good again - at least in the OLD Mingw.

Now to try the NEW Mingw.

@arn79 - watch this .....

[Arnold Trembley]

Would this be in the "make" step for PDCursesMod or in the GnuCOBOL make step?

And would it be "-Dinitscr=initscr_x64_4301" for a 64-bit variant of PDCursesMod? Or is the default now assumed to be 64-bit?

Kind regards,

[David Wall]

They are now:
PDCWIDE & UTF8
32 - initscr_u32_4301
64 - initscr_u64_4301
WIDE ONLY
32 - initscr_w32_4301
64 - initscr_w64_4301
8BIT
32 - initscr_x32_4301
64 - initscr_x64_4301

I gave up trying to mod my script - I just edited the curses.h to remove the _4301 re-zipped it & reran the compile build - worked fine - since you're distributing you'll have to do it the hard way.

[David Wall]

Found another way - when I build the PDC431 I use a different script to building 430 & they both save a .LOG file in the Mingw/msys folder.
I can get the MKCOBOL script to check if there is a MkPDC431.LOG file in the msys folder & change the compile parameters accordingly.
Bit of a workup for something that has changed in PDC versions without any indication in a Readme or anywhere.
Maybe Bill Gray will notice..

[Arnold Trembley]

Thanks again for all your help!!

I will add this to my build guide.

Kind regards,

[David Wall]

I just realised - the peculiar extension to the initscr is _4301 - yet the PDC is version 431
How inane can you get ??????????
I won't bother changing my script - I'll just edit the curses.h file.

[Simon Sobisch]

The header https://github.com/Bill-Gray/PDCursesMod/blob/bd8fa58ea7f0e0d45c682af43e80d9994360cf97/curses.h#L11..L21 says:

::text
Define before inclusion (only those needed):
    XCURSES         if building / built for X11
    PDC_RGB         if you want to use RGB color definitions (Red = 1, Green = 2, Blue = 4) instead of BGR
    PDC_WIDE        if building / built with wide-character support
    PDC_FORCE_UTF8  if forcing use of UTF8
    PDC_DLL_BUILD   if building / built as a Windows DLL
    PDC_NCMOUSE     to use the ncurses mouse API instead of PDCurses' traditional mouse API

And the definition take this into account, see https://github.com/Bill-Gray/PDCursesMod/blob/bd8fa58ea7f0e0d45c682af43e80d9994360cf97/curses.h#L1321..L1341:

::c
#ifdef PDC_WIDE
   #ifdef PDC_FORCE_UTF8
      #ifdef CHTYPE_32
         #define initscr initscr_u32_4301
      #else
         #define initscr initscr_u64_4301
      #endif
   #else
      #ifdef CHTYPE_32
         #define initscr initscr_w32_4301
      #else
         #define initscr initscr_w64_4301
      #endif
   #endif
#else       /* 8-bit chtypes */
   #ifdef CHTYPE_32
      #define initscr initscr_x32_4301
   #else
      #define initscr initscr_x64_4301
   #endif
#endif

And those were the defines you already had to do before....

Those defines are set by the makefile when building pdcurses https://github.com/Bill-Gray/PDCursesMod/blob/bd8fa58ea7f0e0d45c682af43e80d9994360cf97/vt/Makefile#L39..L49.

My personal approach would be:

• build pdcurses ports you are interested in - all with the same parameters during make
• see the defines -Dsomething used during the build (they are visible on the screen)
• copy/install the resulting files (the header and link library needs to be copied only once, they are identical)
• adjust the installed pdcurses.h by inserting the defines you noted down after its header as

#define CHTYPE_32
#define PDC_WIDE

(or whatever applies to your build)

This way you never need to pass any defines during build (which you normally would need to do) like configure CPPFLAGS="-DCHTYPE_32 -DPDC_WIDE - something I never would like to do.

[David Wall]

I'm not talking about 'having to do' the -Dinitscr= - we've had to do that for a number of times now.
However - 'previously' the -Dinitscr= options have been ( in my case ) initscr_x32 - wherease NOW it's initscr_x32 FOLLOWED BY _4301.
Where'd the _4301 come from ?? - It's NEVER been present before & what does it mean ??.

I mean - I 'could' understand IF it was meant to represent the version number of the release - but it doesn't match that either ??.

Here's the same code as you've put above from version 430 (the version before)
I've had to remove some of the code because of the highlighting.
BUT - DO YOU SEE THE DIFFERENCE - WHERE'S THE 4301 or other number ??
What was the point of it.

  #ifdef CHTYPE_32
     #define initscr initscr_u32            << NO 4301  
  #else
     #define initscr initscr_u64            << NO 4301
  #endif

  #ifdef CHTYPE_32
     #define initscr initscr_w32            << NO 4301
  #else
     #define initscr initscr_w64            << NO 4301
  #endif

  #define initscr initscr_x32             << NO 4301

  #define initscr initscr_x64             << NO 4301

  It's not as if it's some 'magic code' used elsewhere - it just ends up in the pdcurses.dll & IS REQUIRED to be exactly specified when the Compiler is built.

Maybe I'm just whinging ( I am a Pom ) but could someone explain the exact purpose of what appears to be this 'random number' ??.

AND I understand it was only added to curses.h a few days ago - perhaps only hours before I actually downloaded it from the github. somewhat pointless in my humble opinion.
Maybe next revision it'll have a different number & we can go round altering our scripts again.

END OF RANT. OK Brian T - Time to calm me down eh ?

[Simon Sobisch]

I'm not talking about 'having to do' the -Dinitscr= - we've had to do that for a number of times now.
However - 'previously' the -Dinitscr= options have been ( in my case ) initscr_x32 - wherease NOW it's initscr_x32 FOLLOWED BY _4301.
Where'd the _4301 come from ?? - It's NEVER been present before & what does it mean ??.

The PDCurses doc always said that you need to pass the correct -D (WIDE, UTF8, CHTYPE, DLL_BUILD ) when linking an application to ensure that the application does the right thing. Some versions before PDCursesMod ensured this by internally renaming an external symbol - so instead of application crashes you get a link error; and if you link to the library correctly and then use a library that does not match the link-time ABI you get a "entry point xyz not found in pdcurses.dll" error when starting the application.

YOU WERE NEVER EXPECTED TO DEFINE THE INTERNAL SYMBOL - AS THIS WOULD NOT ENSURE THE OTHER DEFINES TO BE CORRECTLY.

Therefore it doesn't matter what the internal symbol is named... (I think it is the internal ABI version).

Summary: don't do anything to initscr ever, always use the correct defines, if you want to do it most convenient: adjust the (to be) installed pdcurses.h to match what you've seen when compiling PDCurses/PDCursesMod.

Just to add it as reference here: The main part of the complete discussion (and the question if pdcurses.h should not automatically add the necessary defines) in PDCursesMod can be found at https://github.com/Bill-Gray/PDCursesMod/issues/133 .

[David Wall]

YOU WERE NEVER EXPECTED TO DEFINE THE INTERNAL SYMBOL - AS THIS WOULD NOT ENSURE THE OTHER DEFINES TO BE CORRECTLY.

Simon - IT WAS YOU - who told me to use it and if you check this message and the following ones you suggested to be using it -permanently. I just follow what you said then.
This was back in May 2020.
https://sourceforge.net/p/gnucobol/discussion/help/thread/bc0f3d2ea5/?page=1&limit=25#ab9e/642d/9483/1c9c/8d86/a9b5/7b1f/cca2/ba94/414f/cecd/834c/2004/db0f/54d2/88d9/986d/d618

Maybe you could suggest a replacement line for the following (which is what I currently use) that doesn't reference initscr.

./configure "CPPFLAGS=-DCHTYPE_32 -DPDC_DLL_BUILD -Dinitscr=initscr_x32" --prefix=/mingw --with-vbisam --disable-rpath

[Simon Sobisch]

I see, that was silly from me for anything but a quick hack, sorry.

My suggestion is:

1. change your (installed!) pdcurses.h to have

#define CHTYPE_32
#define PDC_DLL_BUILD

somewhere at the beginning (I'd insert that after the docs-part, but of course before it is referenced)

1. change configure to not search for initscr but for endwin, this also sounds better :-)

Report back, that likely everything "just works" (configure, compile, link, test) and I'll commit the second part.

[Arnold Trembley]

How would that work exactly? I understand how (and where) to put in the #define statements (and the variety of choices), but I don't understand what should go into the GnuCOBOL ./configure command to replace:
"CPPFLAGS=-DCHTYPE_32 -DPDC_DLL_BUILD -Dinitscr=initscr_x32".

What should the statement look like to add "endwin"?

For the old PDCurses 3.4 thru 3.9 there was no need to put anything into the GnuCOBOL ./configure command, which was certainly easier on the build.

I would like to get back to that if adding the #define's to pdcurses.h would help.

Kind regards,

[Simon Sobisch]

If you add the defines into pdcurses.h (CHTYPE_32 and PDC_DLL_BUILD), then you don't need to add them to the GnuCOBOL configure line.
If you search and replace "initscr" to "endwin" in the GnuCOBOL configure script, then you don't need to have any CPFFLAGS at all.

For the old PDCurses 3.4 thru 3.9 there was no need to put anything into the GnuCOBOL ./configure command, which was certainly easier on the build.

That's actually not correct - if you used any parameter when building PDCurses, then you should have either adjusted pdcurses.h manually or pass those defines as -D in the GnuCOBOL configure line - if you don't do it then you get a "broken result", which may anything between "color and other attributes are not correctly applied", "non-US-ASCII characters don't display/accept correct", "libcob chrashes".

Yes, this is also true for PDCurses 3.4! Note: the "default" MinGW version did not used any options but DLL=Y, so you didn't need to define anything but the PDC_DLL_BUILD, which was not necessary as I (falsely) hard-wired that into screenio.c some years ago (which will get out again, not later than 4.0preview).

[Arnold Trembley]

Simon, if I understand you correctly, this parameter in the GnuCOBOL ./configure:

"CPPFLAGS=-DCHTYPE_32 -DPDC_DLL_BUILD -Dinitscr=initscr_x32"

Should be replaced with this parameter (and no double-quotes):

-Dendwin=endwin_x32

Is that correct?

And also (please excuse my lack of understanding), what does CPPFLAGS do, and what does -D mean?

Kind regards,

[Simon Sobisch]

CPPFLAGS are the C preprocessor flags. The C preprocessor, along other things, includes the header files and handles some constant text insertions replacements (similar to the COBOL preprocessor with COPY and REPLACE, but especially for the replace much more powerful [or confusing, depends on your point of view :-]).
-Dsomethine tells it to "imply" #define something=1 on the start of each file processed, -Dsomething=valuable to "imply" #define something=valuable. The define's are similar to what REPLACE is.

So if you -Dinitscr=initscr_x32 and there is a mention of the c-word initscr somewhere it will replace it by initscr_x32 which will be then seen by the actual C compiler.

My suggestion was (until this may be solved differently by PDCursesMod) to not use anything "special" for the GnuCOBOL configure - have the defines not "global" but only where the header is included - by adjusting the pdcurses.h - and replace initscr in the GnuCOBOL configure script by endwin(search and replace, preferably with sed, but also possible for example with Notepad++). That is just used to check if the library is found and the entry point in it, too. So far initscr was dynamically renamed - and this breaks the "fixed named" lookup [but I'm positive that this will be solved in PDCursesMod, possibly "soon" (like "until the next release of that")]).

[Arnold Trembley]

Simon,
Thanks for the explanation. I'm aware of the C Preprocessor, but didn't understand that input could be sent to it that way. The -D option seems a bit confusing because without an "=" sign it's an implied "define", but with an "=" sign it's a text replacement.

I'm wondering if I added #defines correctly to pdcurses.h:

#ifndef __PDCURSES__
#define __PDCURSES__ 1
#define __PDCURSESMOD__ 1
/* defines matching the creation of the library */
#define CHTYPE_64
#define PDC_DLL_BUILD

Do I need a #endif before the two defines I added? It's not clear to me where the #ifndef for PDCURSES is ever closed.

In any event, I tried building GC 3.2-dev0 with VBISAM and NO added parameters for PDCurses in the GnuCOBOL ./configure command. But that version ended up with NO extended screen IO support (no PDCurses).

./configure --prefix=/mingw -–with-vbisam --disable-rpath --enable-debug -–enable-cobc-internal-checks

Next I tried adding "endwin", but it would not configure unless I included it in with a CPPFLAGS, like this:

./configure "CPPFLAGS=-Dendwin=endwin_x64_4301" --prefix=/mingw -–with-vbisam --disable-rpath

That version also had no extended screen IO.

Finally I built it with the following ./configure:

./configure "CPPFLAGS=-DCHTYPE_64 -DPDC_DLL_BUILD -Dinitscr=initscr_x64_4301" --prefix=/mingw -–with-
vbisam --disable-rpath --enable-debug --enable-cobc-internal-checks

That one worked, and I was able to display text in colors and use the box drawing characters (using some older test programs).

cobc (GnuCOBOL) 3.2-dev.0
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built     Dec 06 2021 23:36:15
Packaged  Dec 03 2021 21:04:17 UTC
C version (MinGW) "9.2.0"


GnuCOBOL information
COB_MODULE_EXT           : dll
dynamic loading          : system
64bit-mode               : no
BINARY-C-LONG            : 4 bytes
endianness               : little-endian
native EBCDIC            : no
variable file format     : 0
sequential file handler  : built-in
indexed file handler     : VBISAM
mathematical library     : GMP, version 6.2.1
XML library              : disabled
JSON library             : cJSON, version 1.7.14
extended screen I/O      : pdcurses, version 4.3.1 (CHTYPE=64, WIDE=0, UTF8=0)
mouse support            : unknown

It seems a little kludgey to me, but at least I can build GC 3.2 with PDCursesMod 4.3.1 and get it to work.

This version also has WinCon, WinGUI, and VT versions of PDCurses.dll:

 Directory of C:\GC32-VBI\bin

12/04/2021  01:50 AM           174,255 pdcurses.dll
12/04/2021  02:40 AM           163,687 pdcurses_vt.dll
12/04/2021  01:50 AM           174,255 pdcurses_wincon.dll
12/04/2021  02:23 AM           215,523 pdcurses_wingui.dll
               4 File(s)        727,720 bytes
               0 Dir(s)  358,687,088,640 bytes free

Kind regards,