I've been using AntennaPod for years, about 2 years back they updated the UI into what it is today. Worse UI update of any app I use, it was simple before, now it's confusing, cramped, and just visually ugly.
Having said all that, I haven't found anything better. Watching this thread with interest.
That's a real bummer. Is there any way the author can prevent this? Can he generate random indexes that don't repeat while keeping this random number generator code public?
The only way to address this would be validating the answers server-side. Any information you leak in the locally executed code can be discovered without much effort.
I think Wordle doesn't server-side validate because of volume, and also because it's a fun little game and cheating brings you nothing of value.
C programming - luckily in my opinion - has a culture of very rigorous evaluation of programming techniques especially towards memory-unsafe programming, arguably the biggest weakness of C as a programming language.
This book uses gets() which is a function that can not be used safely. Any input that exceeds the buffer length will corrupt memory. The conventional wisdom in the C community is to NEVER use gets. I personally stopped reading in chapter 4 where this is done.
Unfortunately strictly avoiding memory issues is somewhat involved und thus often ignored in C beginner books. It is also hard to see unless you are pretty familiar with C's pitfalls. IMHO this is why this list of bad books is desperately needed.
Unfortunately, there are not a single but a multitude of cultures within the C programming community that compete with others, most of them claiming they are safer than others.
The aforementioned list for example has Jed Shaw's Learn C The Hard Way as having "[t]oo many factual problems and a presentation that gets you to do things wrongly before being shown how to do it correctly, and not even always then". This is an opinion held by the ##c channel, not necessarily every (competent) C programmer. LCTHW itself did a great service by introducing valgrind very early, and most criticisms [1] seem to be presentation issues that might be partly necessary for beginners and partly a matter of taste. (I personally think LCTHW was in particular unfairly attacked because of its merciless treatment of K&R. It's a shame that Jed Shaw gave up then.) To this date I don't have any good beginner-level C book to recommend, including K&R.
I see usages of fgets in Ch4, not bare gets (didn't check thoroughly)
/* Read a line of user input of maximum size 2048 */
fgets(input, 2048, stdin);
So that fgets does not read in too much data we also must also supply the size of the buffer 2048.
Maybe they updated? Also I'd understand not trying to be 100% safe in the code here to make the code easier to read, unlike in a production version of the tool.
At least some of the things on that list have long been bugbears and known as sources for either incorrect/erroneous explanations and code (most of Schildt's output for instance). So it may be an attempt at gatekeeping but on the face of it seems a reasonable one.
I have little C experience. I've always wanted to learn it properly to broaden my horizons, so I really respect the opinions of the gatekeepers: C is a small footprint language with plenty of footguns.
It goes beyond matters of style and straight to things like memory leaks that can cause security issues.
My first reaction to those reviews was that they read pretty disrespectfully. Writing a book is extremely challenging and some of the feedback is not appropriate for a page that's associated with a standards body.
Then I wondered, "If these are the resources to avoid, where do these people recommend I find the good information?"
Alas, those links are mostly broken.
As a long time programmer recently learning C, I've been surprised by how prickly and unhelpful C culture tends to be.
The concensus seems to be that no published information is good enough, and none of the critics are willing to publish the good information.
It would be nice if they actually bothered to explain. I'm inclined to trust Build Your Own Lisp over blah blah dot info if the latter is going to engage in nonspecific mudslinging.
It teaches bad C, and more importantly bad Lisp implementations.
MPC for a lisp? No macros? No GC? No readline but editline, but not on Windows? fgets? A lisp is fine with a readchar() and putchar() alone. The rest should be done in a safe and more expressive language, lisp. Compare to a good and small Lisp instead. It need not to be "Lisp in Small Pieces", rather your typical lisp in 10 days or in 1K project.
I found this book, it's approach and tone to be really engaging, it answered a bunch of questions I didn't know I had and allowed me to understand and engage with my work as a web dev on another level. Parser Combinators for example are fascinating. I find Daniel Holden's work similar to many ways to Brian Lonsdorf's... Honestly surprised there are haters for this type of thing!
I'm currently re-learning C, and I've been going through one of the books that they recommend (C Programming - A Modern Approach).
Whilst "A Modern Approach" is a great book, it's hard for me to keep focused as I'm not really implementing anything other than the exercises and projects (for which there are too many IMO, and I struggle to get them all done).
I've been working through Build Your Own Lisp in parallel, and it's great fun. I get to work on an actual project, and any holes I find in my knowledge can usually be filled in via A Modern Approach.
"Effective C" is usually what I recommend people nowadays on Libera #c, which is where that wiki originates from.
The books were triaged based on the feedbacks we heard, the kind of questions that are asked on the channel, or how confused those readers are after reading through them.
