Hi,
On Thu, Apr 19, 2018 at 12:12 PM, Bram Moolenaar <[email protected]> wrote:
>
> Nikolay Pavlov wrote:
>
>> 2018-04-19 0:01 GMT+03:00 Bram Moolenaar <[email protected]>:
>> >
>> > Patch 8.0.1735 (after 8.0.1723 and 8.0.1730)
>> > Problem: Flexible array member feature not supported by HP-UX. (John
>> > Marriott)
>> > Solution: Do not use the flexible array member feature of C99.
>> > Files: src/configure.ac, src/auto/configure, src/structs.h,
>> > src/getchar.c, runtime/doc/develop.txt
>
> [...]
>
>> > --- 511,517 ----
>> > struct buffblock
>> > {
>> > buffblock_T *b_next; /* pointer to next buffblock */
>> > ! char_u b_str[1]; /* contents (actually longer) */
>>
>> Why not just stuff a macros here which will expand to 1 or nothing,
>> depending on configure check for flexible array members support?
>> _FORTIFY_SOURCE point still stands and macros name is a nice
>> replacement for “actually longer” comment.
>
> Well, that means maintaining two versions of the code. And since many
> compilers do support flexible array members, the version still using [1]
> would get little testing, and it might break for some rare compilers in
> mysterious ways. I rather have one solution, even when it's not all
> that nice. In other words: Adding a nicer solution doesn't help getting
> rid of the not-so-nice solution.
What Nikolay says is (maybe you interpreted it the same way, but just
to make sure..):
- Add code to 'make config' that spits out a "#define
HAS_FLEXIBLE_ARRAY 1" (or "#define HAS_FLEXIBLE_ARRAY 0") into
auto/config.h, define a macro (in vim.h, probably) that does:
#if HAS_FLEXIBLE_ARRAY
#define FLEX_ARRAY
#else
#define FLEX_ARRAY 1
#endif
and implement struct buffblock (in structs.h as):
/*
* structure used to store one block of the stuff/redo/recording buffers
*/
struct buffblock
{
buffblock_T *b_next; /* pointer to next buffblock */
char_u b_str[FLEX_ARRAY]; /* contents */
};
This way, you only need to write the code once, and the compiler gets
tested in both cases.
If the compiler(s) all get flexible array compatibility, the need to
use this macro may disappear, but that has happened before...
Is this a "nice enough" solution to get rid of the "not so nice" one?
Christ van Willegen
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
