Mail Archives: cygwin/2010/01/20/08:10:49
2010/1/20 Charles Wilson:
> Reini Urban wrote:
>> Then CursesVar.c is regenerated by gen\make.CursesVar.c
>> It looks like this generation got triggered somehow and gets it wrong.
>> Because the DLL exporting part of ncurses/ncurses_dll.h does:
>>
>> /*
>> =A0* For reentrant code, we map the various global variables into SCREEN=
by
>> =A0* using functions to access them.
>> =A0*/
>> #define NCURSES_PUBLIC_VAR(name) ncwrap_##name
>> #define NCURSES_WRAPPED_VAR(type,name) extern type
>> NCURSES_PUBLIC_VAR(name)(void)
>
> Uhm no, that's not wrong. =A0That's correct. It's a consequence of cygwin
> finally moving from what upstream ncurses calls "ABI 5" to what they
> call "ABI 6" [*].
Thanks. I also found that out afterwards.
Getting those public vars is still supported, but setting is now unsupporte=
d.
Interestingly this change is not documented.
See http://rt.cpan.org/Ticket/Display.html?id=3D53818
> We now build with support for re-entrancy, which requires a few ABI
> changes of this sort. Which means that you really can't change the value
> of LINES in this way -- there may be another way, but I'm not sure what
> it is.
>
> Besides, I don't think changing the value of the LINES "C" variable
> outside of curses was ever really supposed to work. The documentation
> says that LINES will be "populated" by initscr() using the value of the
> *environment variable* LINES, or if that's empty, then it will be
> populated from the terminfo description. =A0But the docs are silent as to
> what happens if you manually modify that "C" variable after initscr().
>
> Anyway, I looked at the bug report thread, and I think your Tue Jan 19
> 11:16:23 2010 response is the correct one. You just shouldn't write to
> those variables, AFAICT. =A0Maybe there is some set_FOO() function that
> could be used, but I don't know what it is; and for /some/ of these
> particular variables it just conceptually doesn't really make sense to
> change them once initscr() is complete. (You should be able to update
> COLORS and COLOR_PAIRS...I think there are accessor functions for that.)
I haven't found any set_FOO().
I wrote into my perl patch:
"I'm sorry. I had to disable writing to LINES, COLS, curscr, stdscr,
COLORS, COLOR_PAIRS, because with the new NCURSES_REENTRANT lib, writing
is forbidden. It's now wrapped behind a function call.
I believe this affects all platforms, but some ncurses expert
should clarify how to write to LINES now."
> You're also right that this will affect more platforms than just cygwin,
> once they start enabling re-entrancy -- which is slated to be the
> default when ncurses-6 is released upstream. 'Course, that may not
> happen for a year. =A0Or two or three.
>
>
> [*] cygwin *used* be be at ABI 5 -- actually, because of issues with
> DLLs and exported "complex" data structures in the historical absence of
> pseudo-reloc support, we were really using a somewhat bastardized form
> of ABI "5.5". =A0Furthermore, because of certain other historical changes
> -- ABI jumps required by new compilers, the cygwin-1.3 to -1.5
> transition, and ABI-breaking bugfixes -- our ABI "5" or "5.5" was
> actually cygncurses-9.
>
> Well, now, we're actually using the true upstream ABI 6. =A0Only, we have
> to call it cygncurses-10.
>
> Isn't this fun?
Thanksfully this is not problematic, than silently breaking setters.
Maybe they didn't know that people were also setting those vars.
--=20
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -