FWIW I had been working on removing glib two years ago or a bit less
(dang, was it really that long ago?), as this is basically why I
stopped when I was almost done: it really wasn't maintainable.
Realistically, I do think there's literally no major alternative. I
mean, for atomics there's libatom
Hi,
There is a small memory leak in tcp command shell server in v 1.1.6 and may be
still present in v1.1.7 ?.
The memory leak is a lack of deletion of the command handler
(fluid_cmd_handler_t).
The command handler is created at client connection time, just before client
creation task (i
> would moving to another libc that supports the necessary C11 extensions
be a possibility?
Dont think so. glibc has such a monopoly on unix systems. And musl only
supports Linux as it seems.
The core problem I see is that threads and even atomic are an optional C11
feature. While I could live wi
Sorry, sent off too early. Let me try again...
Hi all,
Just a quick thought: would moving to another libc that supports the
necessary C11 extensions be a possibility? I've read that musl has C11
support, including the threading extensions. [1]
Not sure how big the repercussions would be for the
Hi all,
Just a quick thought: would moving to another libc that supports the
necessary C11 extensions be a possibility? I've read that musl has C11
support, including the threading extensions.
Not sure how big the repercussions would be for the Linux and Mac OS ports,
Am 10.10.2017 19:32 schrie
Without having seen your changes, you have probably done something like
what existed before glib:
https://github.com/FluidSynth/fluidsynth/blob/b49458e817ed09aedd948a6ea1831965373adc80/fluidsynth/src/fluid_sys.h#L142
This is not an option because it's unmaintainable. See the related
discussion her
Hello,
as I wrote in the subject, I worked a bit on Fluidsynth and I made a version
that works fine without external dependencies. I compiled it on the ancient
VisualStudio 6.0 and my version currentl runs on Windows.
However, it should not be difficult to include a new driver for adding again
s
GCC support stdatomic.h since 4.9
On Fri, Oct 6, 2017 at 10:21 PM, Tom M. wrote:
> Not really. It's not done by simply switching to a C++ compiler. The data
> types should be converted to object-oriented ones and the
> checking-every-functions-return-value-mentality should be rethought.
> Usage
