[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros
From: |
Eli Zaretskii |
Subject: |
bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros |
Date: |
Sat, 08 May 2021 16:58:17 +0300 |
> From: Spencer Baugh <sbaugh@catern.com>
> Cc: 48264@debbugs.gnu.org
> Date: Sat, 08 May 2021 09:35:31 -0400
>
> > So how about using _d_ of _def_instead? It's much shorter and
> > expresses the purpose no worse than _defaulted_.
>
> Sure, that would work.
>
> >> Keep in mind though, this name isn't exposed to the programmer
> >> anywhere - it might as well be _ABCDEFGHI_, nothing will change
> >> outside the definition of the BVAR_DEFAULTED_FIELD macro.
> >
> > See above: I'd prefer to get rid of the macro for this purpose.
>
> Sure, we could mostly get rid of it, although it's important that the
> argument to BVAR_OR_DEFAULT be "case_fold_search" rather than, say,
> "case_fold_search_def", even if the field is named the latter.
> Otherwise one might accidentally call BVAR with "case_fold_search_def",
> which would compile but behave wrong at runtime - and preventing that is
> the whole point of the different names.
I agree, but I'm not sure I see the connection. Can you tell how
getting rid of the macro in the likes of b->SOME_MACRO(foo) could run
afoul of the argument to BVAR_OR_DEFAULT?
> >> (eassert (EQ (buffer_defaults->field ## _)); (buf)->field ## _)
> >>
> >> Which would make sure that it's not used on anything with a default.
> >> But of course that's substantially more annoying than a compile time
> >> check...
> >
> > I'm not sure I understand why this is much more annoying, can you
> > elaborate? We have similar assertions, conditioned on
> > ENABLE_CHECKING, elsewhere in our macros, like XWINDOW etc, so why not
> > here?
>
> I mean that it's annoying that merely compiling doesn't detect the usage
> error, one has to actually run tests.
Well, with eassert just running Emacs will sooner or later crash with
SIGABRT, so I think it's acceptable. Again, we do that in other
cases, quite a lot, actually, so there's no reason to treat this
particular case differently.
> If you think such a conditionally-compiled runtime check would be
> acceptable for applying these changes, I can go ahead and write that.
Yes, I think so. But if Lars or Stefan think differently, I might
reconsider.
- bug#48264: [PATCH v3 11/15] Delete SET_PER_BUFFER_VALUE_P and buffer local_flags field, (continued)
- bug#48264: [PATCH v3 11/15] Delete SET_PER_BUFFER_VALUE_P and buffer local_flags field, Spencer Baugh, 2021/05/06
- bug#48264: [PATCH v3 13/15] Assert that PER_BUFFER_IDX for Lisp variables is not 0, Spencer Baugh, 2021/05/06
- bug#48264: [PATCH v3 14/15] Remove PER_BUFFER_IDX and buffer_local_flags, Spencer Baugh, 2021/05/06
- bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros, Spencer Baugh, 2021/05/06
- bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros, Eli Zaretskii, 2021/05/07
- bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros, Spencer Baugh, 2021/05/07
- bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros, Eli Zaretskii, 2021/05/07
- bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros, Spencer Baugh, 2021/05/07
- bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros, Eli Zaretskii, 2021/05/08
- bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros, Spencer Baugh, 2021/05/08
- bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros,
Eli Zaretskii <=
- bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros, Spencer Baugh, 2021/05/08
- bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros, Spencer Baugh, 2021/05/08
- bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros, Eli Zaretskii, 2021/05/09
- bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros, Spencer Baugh, 2021/05/09
- bug#48264: [PATCH 1/2] Take buffer field name in DEFVAR_PER_BUFFER, Spencer Baugh, 2021/05/09
- bug#48264: [PATCH 2/2] Add compile-time check that BVAR is used correctly, Spencer Baugh, 2021/05/09
- bug#48264: [PATCH 2/2] Add compile-time check that BVAR is used correctly, Stefan Monnier, 2021/05/09
- bug#48264: [PATCH 2/2] Add compile-time check that BVAR is used correctly, Eli Zaretskii, 2021/05/09
- bug#48264: [PATCH 2/2] Add compile-time check that BVAR is used correctly, Spencer Baugh, 2021/05/10
- bug#48264: [PATCH v3 15/15] Add and use BVAR_FIELD macros, Lars Ingebrigtsen, 2021/05/09