[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: segmentation fault inside waddch_literal()
From: |
Thomas Dickey |
Subject: |
Re: segmentation fault inside waddch_literal() |
Date: |
Sat, 17 Jul 2021 12:25:27 -0400 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
On Sat, Jul 17, 2021 at 08:21:03PM +0900, Tetsuo Handa wrote:
> On 2021/07/16 14:41, Tetsuo Handa wrote:
> > My program (which runs on Linux) is built with symbol _GNU_SOURCE defined
> > in order to make Unix/Linux specific extensions visible. As a result,
> > curses.h is #include'd with symbol _GNU_SOURCE defined.
> >
> > When this sample is built with -D_GNU_SOURCE, segmentation fault happens.
> > When this sample is built without -D_GNU_SOURCE, it seems to work fine.
> > I have no idea why this makes run-time difference.
The curses.h header file is almost the same for the normal and wide-character
configurations. However, there's a problem reported here:
20161210
+ add configure script option --disable-wattr-macros for use in cases
where one wants to use the same headers for ncurses5/ncurses6
development, by suppressing the wattr* macros which differ due to
the introduction of extended colors (prompted by comments in
Debian #230990, Redhat #1270534).
I was reminded of this in January, made a to-do note that
changing the default would be helpful -- for ncurses 6.3, of course.
> I compared string data within sample1 built with _GNU_SOURCE and without
> _GNU_SOURCE,
> and noticed that there are several differences.
>
> $ diff strings-built-with-_GNU_SOURCE strings-built-without-_GNU_SOURCE
> 13d12
> < _bkgrnd
> 19d17
> < cchar_t
> 21d18
> < chars
> 77d73
> < ext_color
> 129,130c125
> < long double
> < long long int
> ---
> > long int
> 180d174
> < stddef.h
> 192d185
> < /usr/lib/gcc/x86_64-mageia-linux-gnu/10/include
> 199d191
> < wchar_t
>
> It seems that the cause of this problem is "#include <curses.h>" with
> symbol _GNU_SOURCE defined causes NCURSES_WIDECHAR to be defined as 1
> because
>
> defined(_XOPEN_SOURCE_EXTENDED) || (defined(_XOPEN_SOURCE) &&
> (_XOPEN_SOURCE - 0 >= 500))
>
> is evaluated as true, and the disagreement of memory layout of data structure
> definitions between this program and the library cannot be detected until
> this problem occurs.
>
> It seems that how NCURSES_WIDECHAR is defined has changed in v5_9_20111029.
That was here (after ncurses 6.0 in August 2015):
20151212
+ improve CF_XOPEN_CURSES macro used in test/configure, to define as
needed NCURSES_WIDECHAR for platforms where _XOPEN_SOURCE_EXTENDED
does not work. Also modified the test program to ensure that if
building with ncurses, that the cchar_t type is checked, since that
normally is since 20111030 ifdef'd depending on this test.
However, I no longer use "_GNU_SOURCE" if "_DEFAULT_SOURCE" works:
20160806
+ improve CF_GNU_SOURCE configure macro to optionally define
_DEFAULT_SOURCE work around a nuisance in recent glibc releases.
> ----------
> @@ -151,15 +151,21 @@ typedef unsigned @cf_cv_typeof_mmask_t@ mmask_t;
>
> /*
> * With XPG4, you must define _XOPEN_SOURCE_EXTENDED, it is redundant (or
> - * conflicting) when _XOPEN_SOURCE is 500 or greater.
> + * conflicting) when _XOPEN_SOURCE is 500 or greater. If NCURSES_WIDECHAR is
> + * not already defined, e.g., if the platform relies upon nonstandard feature
> + * test macros, define it at this point if the standard feature test macros
> + * indicate that it should be defined.
> */
> -#undef NCURSES_WIDECHAR
> -#if defined(_XOPEN_SOURCE_EXTENDED) || defined(_XPG5)
> -#define NCURSES_WIDECHAR
> +#ifndef NCURSES_WIDECHAR
> +#if defined(_XOPEN_SOURCE_EXTENDED) || (defined(_XOPEN_SOURCE) &&
> (_XOPEN_SOURCE - 0 >= 500))
> +#define NCURSES_WIDECHAR 1
> +#else
> +#define NCURSES_WIDECHAR 0
> #endif
sure: ncurses attempts to use the POSIX definitions, and for platforms
where the developers don't care much about that, it's possible to set
NCURSES_WIDECHAR.
In a quick check, defining _DEFAULT_SOURCE doesn't turn on the unwanted
definitions that _GNU_SOURCE does. Of course, over time the feature's
likely to degrade. _GNU_SOURCE used to be usable.
> +#endif /* NCURSES_WIDECHAR */
>
> #include <stdarg.h> /* we need va_list */
> -#ifdef NCURSES_WIDECHAR
> +#if NCURSES_WIDECHAR
> #include <stddef.h> /* we want wchar_t */
> #endif
>
> ----------
>
> Building like
>
> gcc -Wall -O0 -g -DCOLOR_ON -D_GNU_SOURCE -DNCURSES_WIDECHAR=0 -o sample1
> sample1.c -lncurses -ltinfo
>
> avoids this problem (i.e. behaves as if _GNU_SOURCE is not defined) for
> Mageia 8 environment.
> But I don't know whether I can add -DNCURSES_WIDECHAR=0 for other Linux
> environments.
It should work :-)
> How can I know what value my program should specify for NCURSES_WIDECHAR ?
That clump of ifdef's won't change until a new problem arises,
e.g., someone making _DEFAULT_SOURCE as badly broken as _GNU_SOURCE.
Alternatively, you could use -DNCURSES_WATTR_MACROS=0
(offhand, both fixes work with ncurses 6.1 and up).
--
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature