4 ms·
Why is this site built with C
- kianN 2y agoOne of the most commonly cited drawbacks about C (limited standard library and package management) is something I’ve grown to enjoy when working in a well-loved C codebase. Instead of learning and working with bloated tool chains, every tool in the repo has been built or added carefully for the task at hand. Simplicity provides a lot benefits over time.
- klysm 2y agoC toolchains are the most painful to set up in my experience and have incredible bloat. Familiarity is not simplicity
- kianN 2y agoI’ve never been on a system that doesn’t have either gcc or clang built in. But disclaimer that my experience in C is limited to a specific subset of scientific computing, so my experience is definitely limited
- klysm 2y agogcc/clang isn’t really sufficient though right? Usually there is another build system on top
- kianN 2y agoI only use clang with a Makefile and I’ve done some relatively complex projects albeit with only a few collaborators.
- dmitrygr 2y agoI haven’t seen a system that has GCC but lacks make
- inferiorhuman 2y agoYeah, but is it a version of make that's compatible with your makefiles?
- theamk 2y agolikely yes? I've never had problems with make versions specifically. Usually the project requires distro at most X years old because of gcc/clang version or shared library version. By the time you solve those, your make is new enough as well.
- inferiorhuman 2y agoI mean yeah if all you're using is Linux then the issues with buggy versions of GNU make is something you've probably not seen in a while. Apple is still on 3.81 due to GPLv3 which means bugs. None of the BSDs ship with GNU make in the base system, and I believe they all install it at gmake (which means you've gotta be careful about hardcoding calls to make.
- ryao 2y agoIt is possible to write portable make files that work with both.
- inferiorhuman 2y agoThe pain in doing so and the very real chance you're trying to do something that can't be done in a portable manner is why things like cmake (and every other build system under the sun) exist.
- maccard 2y agoIn my experience as a regular MacOS user, the "portable" solution is to install the version of make that everyone else uses (i.e. it's not portable)
- maccard 2y agoWindows, for one.
- sgarland 2y agoThat’s on you for using Windows.
- maccard 2y agoMy experience with "portable" software is that it's portable as long as you're using the same OS and toolchain as the author. Other systems exist, and plenty of us are less belligerent about our choice of OS.
- skydhash 2y agoAs for windows, I always assume you need to install an IDE like visual studio, clion, codeblocks.
- maccard 2y agoCmd and powershell exist and have done for a long time. There was a period of time where the visual C++ compiler was bundled with the IDE but it’s been available separately for the best part of a decade. Various incarnations of gnu-on-windows have existed for longer than that - Msys/cygwin/wsl are all feasible options and have been for ages. But, none of them come preinstalled.
- jimbob45 2y agoCouldn’t agree more. Vcpkg + CMake doesn’t come close to the convenience of NuGet + MSBuild. The latter Just Works every time. You can’t say the same about C.
- dig1 2y agoMaybe I'm missing something, but what is painful to set up with C toolchains? On almost every *nix, (g)cc, vi(m) and make are enough to be dangerously productive. Sure, you can overcomplicate stuff with modern IDEs and IDE-like tools, but that is out of the realm of the usual C toolchain.
- klysm 2y agoI’ve never seen a real project that doesn’t use make, cmake, or some other glue on top of gcc/clang. Dependency management is absolute hell as well
- immibis 2y agoDependency management in C is the hell that you and your dependency make it, alone. You can try to copy a .a file and a directory of headers into your project, or you can try to make a massive graph of 1000 dependencies that needs a SAT solver to untangle. Dependencies are hell in JavaScript, Haskell, and Python too, but you don't notice because the computer works through the most common hells automatically... so developers don't hesitate to create hells. In C, they hesitate.
- deleted 2y ago[deleted]
- Ygg2 2y ago> In C, they hesitate. Looks at most Linux distros. Are you sure about that?!
- BoingBoomTschak 2y agoAre you really putting make and CMake in the same bag? POSIX make and Plan 9 mk are incredibly simple, compared to autotools/CMake; even BSD/GNU make, with all their extensions, are quite simple. Personally, after having gone through a lot (GNU make, sh script + POSIX make, CMake + conan at work), I think a simple POSIX 2024 make + pkgconf(ig) really is enough for simple programs; and Windows devs can use WSL or whatever.
- checker659 2y agoOnce you set things up, chances are it'll still build just fine in 5 years tho.
- 1vuio0pswjnm7 2y agoWhat are the "least painful" toolchains to set up. How do they compare to GCC in (a) size and (b) portability.
- inferiorhuman 2y agoLLVM is a bit easier to set up in my experience. One of the most irritating things about setting up a GNU toolchain is the hard dependency on texinfo (which has been dropped in later versions I think). In general I've found rust pretty easy to build.
- wfn 2y agoAgree regarding easiness of building rust (`cargo build`), extremely satisfying (git clone and cargo build...) Does anyone have any comments on Bazel[1] because I'm kind of settling on using it whenever it's appropriate (c/c++)?.. [1] https://bazel.build/ https://bazel.build/
- 1vuio0pswjnm7 2y agoIs python actually a requirement for compiling the rust toolchain so compiling rust toolchain requires compiling python first https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html https://rustc-dev-guide.rust-lang.org/building/how-to-build-...
- klysm 2y agoThen the c toolchain needs to also be considered from a bootstrapping standpoint
- 1vuio0pswjnm7 2y agoIs cmake actually a requirement for compiling LLVM such that one must compile cmake before one can compile LLVM. Compiling a statically-linked cmake is time-consuming and difficult if not infeasible.
- 1vuio0pswjnm7 2y ago
- johnklos 2y agoYou're not wrong, but you're closer to wrong than right. C toolchains are the best of a collection of rather sucky things. I can compile all sorts of things on my Mac LC III+ with 36 megabytes of memory. Sure, Perl takes nine days, but it works. What other language can actually be used on a machine with such little memory?
- lelanthran 2y ago> C toolchains are the most painful to set up in my experience and have incredible bloat. Familiarity is not simplicity What are you comparing it to? C++? Java?
- dezgeg 2y agoautotools would like a word with you
- kianN 2y agoHaha I definitely greatly benefit from autotools infrastructure to such a degree that I took it for granted in my above comment.
- 01HNNWZ0MV43FF 2y agoI don't usually have tools in my repo, I only have my own code
- FiniteIntegral 2y agoEven though I love 3rd party tools (SDL my beloved) I still find novel uses in the C library. Especially for string-related problems people say "just do it from first principles". Sometimes snprintf is enough for my debugging!
- algo_lover 2y agoStill not sure why you chose C though? You could have chosen anything which meets all your requirements. Many languages have markdown parsers in them, produce binaries, and are portable.
- apitman 2y agoThis is covered in the article.
- Brian_K_White 2y agoHaving read the article, I somehow know why they chose C. C satisfies all their priorities, and there are not many, or even any other languages that do as well, and none actually better.
- jopsen 2y agoI'd rather trust 5 libraries written in a memory safe language than one written in C. Sure, if the memory safe language comes with a package manager that happens to have postinstall hooks, the picture might be different. But scanning some go packages to see that they don't do I/O is rather feasible.
- apitman 2y agoWhat type of problem for the author's workflow (rendering markdown files) are you expecting as a result of them using C?
- tuveson 2y agoWhy? It's a static site generator. He controls the inputs - there's basically no attack surface. I can't think of a situation where lack of memory safety would be less of a problem.
- exe34 2y agowhat's the trust model that you think the author should be using here?
- rgovostes 2y agoMany tools in the web publishing world are fixated on build speed. I would think transformations of text into templated HTML ought to be basically instantaneous on modern CPUs and SSDs, even for slow interpreters, for websites of even substantial size. It doesn’t exactly require algorithms with quadratic runtimes.
- gorgoiler 2y agoThis author is great. Their blog engine really ought to link to the top level. There’s lots of content. https://marcelofern.com/ https://marcelofern.com/ I am immediately intrigued about doing code review in Vim (from their posts) as well as using vale.py to lint my prose (from their GitHub.)
- TrayKnots 2y agoWell, I have in essence nothing against this post. I agree with the notion that too many dependencies are not necessary. That we can keep lots of things simpler. I have nothing against directly implementing this in C or just writing markdown files and have the auto-translated into HTML. I just don't like his arguments about it must be fast to recompile everything. I am writing this comment, and this is going to take me a few minutes. After all, I am thinking about what I am writing, typing it out, thinking some more. And then, the deploy is the thing that go the author? Really? Time to server is an important metric? Let's be real, nothing would be lost if it took 5 minutes. He would send it off and 5 minutes later, his phone buzzes, notifying him that it is done. Alright, he found a way to do it in under 10 seconds. Cool. Good for him. Now that it is built, there is nothing bad about it. I just don't see how this was ever an important KPI.
- skissane 2y ago> I just don't like his arguments about it must be fast to recompile everything. C isn't necessarily fast to recompile everything. Too much preprocessor magic and the compilation can slow down a lot. And a lot of the reason for that, is that C's preprocessor is inherently weak – e.g. it doesn't explicitly have support for basic stuff like conditionals inside macros – but you can emulate it with deeply nested recursion – which blows up compilation times enormously. If C's preprocessor was a bit stronger and natively had support for conditionals/etc, one wouldn't need these expensive hacks and it would be a lot faster. Example of real world project where C preprocessor slowed things down a lot is the Linux kernel: https://lwn.net/Articles/983965/ https://lwn.net/Articles/983965/
- catgirlinspace 2y agoI think the part you quoted is about it needing to be fast to compile from markdown to html, not compiling the C program.
- TrayKnots 2y agoyep
- kuon 2y agoI agree with the author that many projects are waaaay to big. I have been using zola and I quite like it. I like the C approach which gives an extra geek point!
- bbkane 2y agoI appreciate his argument about tooling lasting a while, but for me the most important thing is the durability of the content format (markdown), and, secondly, owning the domain name. If, for example, their posts were stored as Word documents or Google Docs, they would have a far fewer options for building and deploying their blog. But, because theyre're using the (comparatively) simple markdown format, they have a lot more options. I do something similar and I've migrated my blog from Jekyll + Github Pages to Zola + Netlify without too many issues. If Zola or Netlify go away, I'm confident I can migrate again easily.
- fragmede 2y agoI don’t know about more, just different. Google App Script can interact with Google docs, and wiring it up so that you can make a Google doc on your phone and have it auto publish. You could also setup such a thing with markdown, just with different apps, (hopefully not via ssh) but that really seems like 6 of one, half dozen of another. If that's a use case you want to support because of convenience, I really don't see a reason to use one over the other, other than personal preference.
- bbkane 2y agoPractically I think you're correct, but I personally prefer owning the files instead of keeping them stored on Google (though of course you could set up automation to export on a schedule or something).
- massysett 2y agoI understand all this, no objections at all, I just wonder if the easier thing to do here is to write the blog posts in HTML and drop them in a folder for a web server, the same way I learned to do websites 25 years ago. What's making this complicated is the Markdown and if you want something lightweight, Markdown doesn't pull its weight.
- encomiast 2y agoIt seems like we've spent the past 25 years trying to solve the big headache this creates: you have 100 blog posts, which means 100 html files. Any structural change you need to make to the site involves touching all 100 files. CSS came along and helped separate the presentation from the information a bit, but it still sucked to maintain 100 html files on the server.
- xnorswap 2y agoIsn't this what Jekyll solves? Posts are all written as markdown, styling and layout are centralised with layout HTML pages and CSS. I believe indexes can be auto-updated via post metadata. And it's all static pages once generated, so there's no dynamic load on a database.
- mid-kid 2y agoI generally just have a makefile that for each page does `cat header.html page.html footer.html > out/page.html`. I realize this can be considered a "static site generator" but I think simple concatenation covers most of the painpoints of writing static sites manually, without introducing intermediate formats and complex processing. Another option is PHP, which was practically made for the purpose of generating HTML. You can run it on your pages to generate static versions, and just use "include" directives with that.
- thombles 2y agoYou're right but in my experience the annoyance factor jumps up as soon as you start wanting an RSS feed.
- rorads 2y agoI appreciate the dedication to minimal performant code. For me a standard Jekyll setup with a theme and github pages is absolutely fine. It's slow and a bit annoying sometimes but it's very straightforward markdown to html and compiles categories into URL structure. It's also easy to throw in some JS if you need, customise CSS etc.
- m000 2y agoI think TFA is unfair wrt pandoc's dependencies. I'm not sure if the listed "ecosystem" is what you need to build pandoc from source, or just the result of shitty packaging of pandoc from the OS package maintainers. For the record, the .deb download from [1] gives you a 146MB statically linked pandoc executable that depends only on libc6 (>= 2.13), libgmp10, zlib1g (>= 1:1.1.4). [1] https://github.com/jgm/pandoc/releases https://github.com/jgm/pandoc/releases
- zahlman 2y agoThe "Markdown" package on PyPI gives you a <1MB (including precompiled .pyc; excluding Pip, which is trivial with the know-how) virtual environment that depends only on the Python runtime. Pandoc is massive overkill if you're only interested in converting one format to one other format.
- rglullis 2y ago> Why Is This Site Built with C Because you are developer who enjoys coding, and you will find any and every excuse to spend more time writing code than you care to admit.
- sgarland 2y agoIf you are a developer who does not enjoy coding, I question your career choice.
- indigoabstract 2y agoSome developers enjoy coding and some enjoy paychecks. Some enjoy both.
- knighthack 2y agoLack of passion and enjoyment for an art form generally correlates with a mentality of doing 'just-enough', rather than a keen desire for craftsmanship. I think those who enjoy paychecks but don't enjoy coding are likely to be incompetent developers. Which is not a desirable end.
- perching_aix 2y agoThey are probably questioning it too. But also, enjoying coding recreationally and enjoying coding for work are very different things.
- rglullis 2y ago[dead]
- Klonoar 2y ago...am I taking crazy pills or reading this wrong somehow? > I've been writing about things on a personal website since 2017. > GitHub pages didn't exist at the time GitHub pages existed before 2017. Like, almost a decade before.
- goykasi 2y agoI thought the same. He also mentioned hosting on DO and droplets not existing. Im 99.9% sure they existed too. Droplets were literally what they were selling if Im not mistaken. gmail has always been free too (from his archive.org link). So much of this post feels like alternate history and gloating. Its cool that he wrote a wrapper around an existing library, but his main argument is that C will still be around in "the upcoming decades." Im willing to bet money on Hugo/go existing and still working too -- or any number of other static-site generators. edit: This can all be done with just pushing markdown files to github anyway. Github will automatically generate the html if you do some basic configuration in your repo.
- zoogeny 2y ago> An alternative for saving time with recompilation was to update my script so that only new markdown files or changed ones are marked for recompilation. That would involve too much wizardry if I wanted to make the script nice and robust. Am I crazy that this doesn't seem like too much wizardry to me? I mean, I have a source directory and a destination directory which gives me a set of unambiguous file to file mappings. At which point I'm looking at comparing some kind of file timestamps. Add in checking if the destination file exists at all and it looks like 2 or 3 system calls and a couple of comparisons. However, I agree with almost everything else in the article, even just blowing things away and rebuilding every time if it is fast enough. I was musing today that with LLMs we might see a resurgence of personal libraries. Why would I take in a dependency (227 transitive dependencies for that one project dependency!) when I could implement the 20% of functionality from that bloated library that I need? In some circumstances it might be easier to describe the functionality I need to an LLM, review the code and then I have my own vendored implementation. But if this was me, I would probably choose Go over C. The speed would be good enough, GC for memory safety and convenience, unlikely to be going away in the next 50 years, simple path from static to dynamic generation with standard lib webserver, etc.
- bowlofhummus 2y agoThey're probably already using Git for the website so using a pre-commit hook is by far the easiest way.
- TheRealPomax 2y agoYour server is irrelevant. If it's being visited by humans, it just needs to get your information to them in a speedy-enough fashion. It's the content you're serving that matters, not what's serving it. (5MB React bundles? You're bad at the web and you should feel bad. Pure HTML and CSS using brotli compression? You're a superhero)
- immibis 2y agoThe server technology is relevant because it controls how the information gets to humans. A site without 5MB of Javascript runs faster than one with 5MB of Javascript, all else equal. And Hacker News is a site for technically-minded people who are here to read about things like servers, so even if it was not relevant, it would still be appropriate for Hacker News.
- TheRealPomax 2y agoTo a degree, but unless you need to serve a literal thousand-plus humans per second (AI bots don't count, modern problems require modern solutions and "your own" is not a solution, use an AI maze SaaS), it's still irrelevant: every modern CPU and even inefficient scripting language can serve hundreds of concurrent connections as long as the content itself is proper content instead of "modern" nonsense bundles. Sending pre-compressed html and css (with a sprinkling of JS at best to enhance the experience after it's already in the browser) is kilobytes of work at most (irrespective of how much it unpacks to on the client). The biggest lie the modern web sold us is that information needs to be packed up in complex datatypes and be interpreted on the client before it's information again.
- immibis 2y agoI run C on the server. Static content blocks from a directory are converted to #defines by a Python script, so I literally #include "staticpages.inc" and reference them by name. Another Python script generates the code for building the navigation menu (dynamically based on the current page). Another one generates the code to parse the URL and select a request handler. Most pages are header+navbar+content+footer, so I wrote a utility function: The blog section is a memory-mapped set of C structures, but in the next rewrite I'll directly embed blog posts in the program, too. I did it this way instead of using a static site generator because I realized that there's no such thing as a static site. My server has to run code to serve any website, including a "static site", so why arbitrarily limit it to the code for loading static files? https://www.immibis.com/blog/12 https://www.immibis.com/blog/12 Not a single library is used, besides libc - at least in the backend code. I use nginx as a reverse proxy and SCGI as the interface from nginx to the C backend.
- assimpleaspossi 2y agoWe did the same. We created bespoke web sites entirely in C. One of which you may have visited (years ago). And we used C for the same reasons the author mentions and agree with his last paragraph. Why? At the beginning we were frustrated trying to find one true solution--granted, the perfect solution--to what we wanted to do and how we wanted to work for 20 years. We found that C interfaced with everything, worked everywhere, every programmer knew it, and it could do anything we wanted it to do. If there wasn't a library for something, we could easily make our own. I could go on and on but I won't. I closed shop just a few years ago cause my reasons for doing that work went away.
- deleted 2y ago[deleted]
- grandempire 2y agoWhen it comes to personal projects some people love to tinker with new tools, but for me any time not spent writing code is discouraging. Velocity is important for fun and experimentation.
- miguel_martin 2y agoI'm also using MD4C for my website with KaTeX for latex rendering and utterances for comments. Instead of C, I'm generating my site with Nim using Karax + Mummy and publishing to Github Pages with Cloudflare for HTTPS. Here is the source code (it should be easy to fork for your own site): https://github.com/miguelmartin75/miguelmartin75.github.io https://github.com/miguelmartin75/miguelmartin75.github.io - To generate a page: https://github.com/miguelmartin75/miguelmartin75.github.io/blob/master/src/gen.nim#L164 https://github.com/miguelmartin75/miguelmartin75.github.io/b... - See usage: https://github.com/miguelmartin75/miguelmartin75.github.io/blob/master/README.md#usage https://github.com/miguelmartin75/miguelmartin75.github.io/b... - Install nim & run `nimble setup` in repo to install necessary packages - Run `nim init` to enable deployment/publishing the site (using git work trees) - Serving it locally before deploying is as easy as `nim dev`, see: https://github.com/miguelmartin75/miguelmartin75.github.io/blob/master/config.nims#L15-L16 - Serving it locally with my private notes (710 files): `nim devpriv`, see: https://github.com/miguelmartin75/miguelmartin75.github.io/blob/master/config.nims#L12-L13 - Generating the site: `nim gen` - To publish the site: `nim publish` I use Obsidian to write notes and can put top-level YAML metadata on each page and retrieve it in my generator, see: https://github.com/miguelmartin75/miguelmartin75.github.io/blob/master/src/gen.nim#L172-L173 https://github.com/miguelmartin75/miguelmartin75.github.io/b... For the local development HTTP server (using Mummy), you can refresh the page to regenerate the markdown. Re-generating the page on file changes and refreshing the page with websockets is on my backlog. Previously I was using GatsbyJS, but have had a lot of trouble with dependencies constantly updating, copying the setup to another computer and generally it was pretty slow to generate the site. Now I can generate my site in <0.1s - even if I include all my private notes (710 markdown files).
- grandempire 2y agoThis problem would also be solved by using make with th his original pandoc script (or just use perl markdown). Make determines which files changed and their dependencies and reexecutes your script to regenerate the necessary output.
- foul 2y agomhm. I don't understand why a makefile or a redo file is out of the picture. Yea if you change something in header or footer build speed matters but when the HTML file is done, it's done.
- gwbas1c 2y agoWhen I was in high school in the 1990s I wrote a site generator in C. It took each post, which was just the body part of HTML, and then added a header and footer. Almost 30 years later, there's plenty of more modern tools that will do a much better job than custom C code.
- enneff 2y agoI agree that Hugo is pretty bloated, but you could much more easily write your own bespoke website generator in Go than in C.
- gbraad 2y agoThe pandoc generation was slow? Easy solution is to only generate the file that is new and/or refresh all when the template changed.
- aninteger 2y agoThe article also mentioned the size of the dependency (over 400 mb)
- gbraad 2y agoOn Fedora this installs 187 MiB. Surely not small, but everything has dependencies and can have issues with them. It is a trade-off. It was an interesting article, though my solution was simple and worked for me.
- zahlman 2y ago> Why Is This Site Built With C The short version: the author eventually decided that statically generating the site would require literally only a Markdown parser and a wrapper to iterate over .md files and fix internal links and add a common header and footer. The author then found a Markdown parser implemented in C and therefore interfaced to it in C (which of course involves a bunch of buffer manipulation and memory management and looks incredibly clunky compared to any obvious choice of language). > I looked for a better alternative and found md4c, which is a parser written in C with no dependencies other than the standard C library. It also has only one header file and one source file, making it easy to embed it straight into any C project. I see three of each looking at the repository's src/ folder. > My website converter script, which is all in this 250 LOC source file (less md4c) is feature-complete and runs on any compiler that supports the C standard from 1999 onwards. There's no platform-dependent code and it's portable to Windows, Linux, and MacOS. Feature-complete if you're the author, I guess. Portable if you're willing to edit source code and recompile just to change file path configuration. Except for the part that makes a system call to `find` (prepared in a statically allocated buffer using sprintf without bounds checking). As far as I can tell, <ftw.h> is also Linux, or at least Posix-specific. 250 LOC if you ignore the author's own array, file and string libraries as dependencies. And, again: that 250 LOC is way more than it would be to do the equivalent in a higher-level language. > It seems better than some alternatives like pelican which is written in Python and thus will be slower to parse md files. You'd think experienced C programmers would know to benchmark things and not make assumptions. And if the goal is to find just a markdown parser, this simply doesn't reflect looking hard enough. For example, I can easily find https://pypi.org/project/Markdown/ https://pypi.org/project/Markdown/ ; in fact it's what gets used under the hood by Nikola (and I'd guess Pelican too). It's less than 1MB installed, pure Python with no further dependencies. I imagine the story is similar for Hugo. Sure, I wouldn't at all be surprised if it's slower, but it seems like there's considerable acceptable slack here. It's good enough to enable Nikola to implement an auto-refresh using a 1-second watchdog timer on the source directory, for example, despite that it's also feeding the Markdown result into a full templating system.
- tony-allan 2y agoThe C program converts Markdown (written by the author) to HTML and is run by the author (and therefore no attack surface). Actual hosting uses GitHub Pages so there is nothing to worry about there. Simple; job done. "The only work I needed to do was to write a C script (which turned out to be ~250 LOC) to call md4c functions and parse my md files, and then chuck those converted files into the GitHub Pages repo."
- kopirgan 2y agoInteresting.. Don't think Hugo needs to be as complicated as he described. I'm using it for a couple of static sites and you can ignore most of the complexity just treat it pretty much like a md converter. There are minimalist templates available as well that get your site going. It's lightning fast too & whether there's a GC at the back of it seems not relevant.
- sgt 2y agoWhy doesn't the site allow for navigating to the other articles?
- billforsternz 2y agoI like this, and used the same approach myself (well C++ that's basically C plus a a few nice things from C++), including the same single md4c external dependency, for a little static website generator of my own that I use extensively myself https://github.com/billforsternz/winged-spider https://github.com/billforsternz/winged-spider. I haven't touched it since I created it, but I use it all the time, eg https://wellingtonchess.club https://wellingtonchess.club and it builds my site instantaneously. I then use Filezilla to deploy like a primitive caveman. I didn't have problems with a C++ toolchain, I just go g++ *.cpp. No make, no cmake, no autotools (shudder). It's fine for small projects with a handful of source files and a few thousand LOC.
- Alifatisk 2y agoI built a site using D once, I almost forgot how instant websites could be.
- rurban 2y agowhile getc != EOF really? You stat the file for its size, then alloc the buffer with that size and fread into that. Or fseek the end and get the size via ftell and fseek to the front
- int_19h 2y agoWhat problem are you trying to solve, exactly?
- tasuki 2y agoMaybe start with preserving the urls you've created in the past? Longevity isn't just for programs, it's also for content...