From: Jessica Clarke <jrtc27@jrtc27.com>

---
 include/libseat.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/include/libseat.h b/include/libseat.h
index 385acd9..e01786a 100644
--- a/include/libseat.h
+++ b/include/libseat.h
@@ -3,6 +3,10 @@
 
 #include <stdarg.h>
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 /*
  * An opaque struct containing an opened seat, created by libseat_open_seat and
  * destroyed by libseat_close_seat.
@@ -172,4 +176,8 @@ void libseat_set_log_handler(libseat_log_func handler);
  */
 void libseat_set_log_level(enum libseat_log_level level);
 
+#ifdef __cplusplus
+} /* extern "C" */
+#endif
+
 #endif
-- 
2.34.5

On Tue, Nov 22 2022 at 05:44:44 AM +00:00:00, ~jrtc27 
<jrtc27@git.sr.ht> wrote:
> +#ifdef __cplusplus
> +extern "C" {
> +#endif

So far I have done the same as we do in wlroots: libseat is a C 
library, and therefore doesn't have C++ compiler directives in it.

The reasoning is that it seems illogical to make C libraries carry C++ 
code/directives around, just like we don't carry Rust, Zig, D or any 
other language-specific code/directives. If the problem is that the 
needed C++ compiler directives are too ugly, then it makes even less 
sense that C libraries should be forced to carry around another 
language's ugly directives.

I know that the stance is slightly defiant to an otherwise relatively 
established (but somewhat odd) norm, but I'll stick to it for now. 
Sorry!

On 30 Nov 2022, at 19:51, Kenny Levinsen <kl@kl.wtf> wrote:
> 
> On Tue, Nov 22 2022 at 05:44:44 AM +00:00:00, ~jrtc27 <jrtc27@git.sr.ht> wrote:
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
> 
> So far I have done the same as we do in wlroots: libseat is a C library, and therefore doesn't have C++ compiler directives in it.
> 
> The reasoning is that it seems illogical to make C libraries carry C++ code/directives around, just like we don't carry Rust, Zig, D or any other language-specific code/directives. If the problem is that the needed C++ compiler directives are too ugly, then it makes even less sense that C libraries should be forced to carry around another language's ugly directives.
> 
> I know that the stance is slightly defiant to an otherwise relatively established (but somewhat odd) norm, but I'll stick to it for now. Sorry!

The trouble is if libseat.h includes anything then the extern “C” applies to that too, which may break things if they end up pulling in a header that makes use of C++ things when compiling for C++, whereas if you put it in libseat.h then you can ensure it only goes around the declarations there. Though ISO C++ seems to take the view that it’s ok to do, even if one should “strongly consider” editing the header instead[1][2], so maybe in practice it’s ok to do... just makes me feel less warm and fuzzy inside and feels more like a hack that could break in future.

Jess

[1] https://isocpp.org/wiki/faq/mixing-c-and-cpp#include-c-hdrs-nonsystem
[2] https://isocpp.org/wiki/faq/mixing-c-and-cpp#include-c-hdrs-personal

On Wed, Nov 30 2022 at 08:01:10 PM +00:00:00, Jessica Clarke 
<jrtc27@jrtc27.com> wrote:
> The trouble is if libseat.h includes anything then the extern “C” 
> applies to that too, which may break things if they end up pulling in 
> a header that makes use of C++ things when compiling for C++

extern "C" only changes linkage, which for anything imported by C 
should also be C - otherwise things break/won't link at all.

If libraries worked differently when included in C compared to in C++ 
with C linkage, then I imagine we would have big issues whenever anyone 
tried to interop between C++ and C...

If you find or hit such an issue, please do share it.