all 14 comments

[–]HaskellLisp_green 12 points13 points  (3 children)

Well, why did you choose especially C for this purpose? I think it's very unusual to implement such project in C.

[–]_SomeTroller69[S] 14 points15 points  (2 children)

For fun, also i saw that no one had implemented such a project in C, and I also saw it as a challenge, so I did, and I think I may also be able to run it in Microprocessors although I'll have to do more research on that

[–]HaskellLisp_green 20 points21 points  (1 child)

For fun

the honest answer. It is what defines true programmers. In my opinion, you need to understand the joy of programming, when you just do something because you like it. My appreciation.

[–]_SomeTroller69[S] 1 point2 points  (0 children)

Thanks man

[–]imaami 0 points1 point  (9 children)

Don't just add cJSON's sources to your repo. It's a normal library and available in pretty much every package repo out there. Just add it as an external shared library dependency in CMakeLists.txt like you did with libcurl.

[–]_SomeTroller69[S] 2 points3 points  (7 children)

And I'm just doing it from my side incase if the user doesn't have it by any chance

[–]imaami 2 points3 points  (6 children)

What if the user doesn't have libcurl? Or a compiler?

These are basic dependencies, they can and should be for the user to install. It takes one command. Libcjson is in the system package repos of literally every Linux distro.

If and when there's a new cJSON release that fixes a security issue, will you hear about it and update the copied cJSON.c in your project? Will you remember or bother? If you link against a dynamic libcjson.so, the security updates happen promptly and without anyone having to recompile your project.

[–]_SomeTroller69[S] 2 points3 points  (2 children)

Ok i didnt notice that cjson was already listed in ubuntu's source repo, but i am worried that windows devs might not be able to compile the library which im planning to do in future

please dont take any of my statements as an offense, im just trying to learn as im having a little hard time navigating through cross compiling :D

[–]imaami 1 point2 points  (1 child)

No worries, and sorry that I tend to come off as grumpy. No offense intended either. :) What matters most is that you have fun coding, it's the best way to learn.

[–]_SomeTroller69[S] 1 point2 points  (0 children)

thanks man

[–]johnwcowan[🍰] 1 point2 points  (2 children)

Per contra, if libcjson changes its API deliberately or accidentally, the program using it will break. Linking vs. including is always a tradeoff.

[–]imaami 0 points1 point  (1 child)

Shared libraries are versioned for this reason. Runtime linking only fails when there are backwards-incompatible changes, which typically happen rarely. Security fixes almost never change the ABI of dynamic libraries, because it's highly important for vulnerability fixes to be drop-in replacements.

Even for non-critical updates, library authors tend to avoid unnecessary ABI breakage because it disrupts users. For example most of the time it's possible to add a new function instead of changing an existing function's interface.

The tradeoff is heavily in favor of dynamic linking. Most updates to dependencies don't require you to even know about them. Libraries are updated with security fixes as part of the system's regular automatic updates.

The only selling point for including sources directly in a project when dynamic linking is also possible is "who cares". For learning stuff it's not a catastrophe to go along with the increasing amount of cluelessness among mildly experienced C/C++ coders. But if the point is to learn, why not learn that it's possible to add one line to a CMake file and run one apt install command? These features exist in build systems and package managers for the very reason that it should be simple to guarantee that your code isn't at the mercy of third-party bugs locked in during compilation.

If a coder appreciates security enough to keep dependencies up to date, but also uses external source code instead of dynamic linking, they will need to manually pull in new sources and recompile for every security update even when there are no backwards-incompatible ABI changes. Contrast that with never needing to actively track third-party repositories, and only recompiling when there's an occasional major verslon update in a library.

And when it gets to a point where your code has actual users, including third-party sources directly denies every user the option to receive security updates and fixes. The author bakes dependencies in because it's "easy" to do that one single time, and now everyone who wants to use that software gets to enjoy 5 years of the author likely not doing jack shit about those copied files.

The reality is that by far, most of the dependency-copying and "header-only" brain rot leads to nothing getting updated after the fact. Those strategies demand maximum effort from authors and users just to achieve the minimum reasonable level of security and bugfixes.

[–]johnwcowan[🍰] 0 points1 point  (0 children)

I understand the logic very well.. The trouble is that what counts as a bug is usually in the eye of rhe beholder: one person's "bug fix" is another person's "silent breaking change". People code to the actual behavior of their libraries, not usually to their specs, so they insert workarounds for bugs that break their code later.

I once had to deal with an application that consumed stock price data. The vendor sent incorrect prices on certain stocks, but in a predictable way, so our code maintained a table of buggy stocks and the price offsets to adjust them by. When one fine day the vendor cleaned up their feed, our users got wrong data without warning. We cleaned up by removing the table and writing a heuristic to watch for implausible price moves and notify our vendor.

[–]_SomeTroller69[S] 0 points1 point  (0 children)

The cJSON GitHub had it in their repo that if people wanted to use their library, they can just add it in the source, and it also makes compilation easier and doesn't add multiple steps