|
Top-level
 It really gets rolling when we learn about the format of the format string. We wanted to print a string, not a constant character pointer to a "format string", but we can roll with that. "The overall syntax of a conversion specification is: %[$][flags][width][.precision][length modifier]conversion" We're getting warmer you know? You can really feel it. We're close to figuring this out. 54 comments
Let's try something different, maybe gcc --help will do something. And holy shit does it ever.  @mhoye I am currently working on a short tutorial about date-time manipulation in SQLite. I just reached the part where I explain what Julian days are. Well, let's see if we can find the error we got in that first message somewhere in the help file, the "-Wmultichar" thing we got in that first warning message. Let's see.... nope? "apropos multichar" comes up empty too, assuming I know about it. Tell me what I should have done differently. This is a _typo in 'hello world'_. What trail of breadcrumbs should I have followed that would have gotten me from "incompatible integer to pointer conversion passing 'int' to parameter of type 'const char *'" to "You want double-quotes, not single quotes there", using the error messages and docs? You complain about "StacktGPT Developers?" Well, this is what people are up against. @mhoye I think this is an excellent walkthrough of an all-too-common situation. Thanks for taking the time to make it. @mhoye The number of responses in the thread treating this as purely a documentation problem is also really alarming, tbh. There are human factors issues at multiple stages of this! The earliest one is probably the design of C, where the difference between values occupying types with wildly different semantics is expressed via the shift key alone, for example. @mhoye Docs and error messages retrench that design problem without meaningfully remediating it, and that gets us to docs as one of the multitude of cultural failure points in this chain.  @mhoye This 100%!! My god I can't believe how many times I've looked with despair at convoluted docs when a series of explained, code examples would have gone 1000x better. That's why people love StackOverflow, because the answers usually include *example code*. It's the programming equivalent of 'a picture is worth a thousand words'. Show me don't tell me.  I often suspect if the ultimate “zen” of documentation is just a well structured and indexed series of code examples with outputs and inputs. Similarly for research papers except with figures and plots. @graydon yeah. We’ll get to the point where this is understood as a load-bearing archaeology exercise, I think, that yes there’s lead in the pipes and asbestos in the walls and you don’t even wanna know how big those roaches are, but _some_ of these pipes still bring people drinkable water and heating, and here are the skills and tools you need to work safely in this environment, but we’re not building anything new like this ever, whatever those weird PDP-11 Reenactment Society people say.  @mhoye What's interesting is that all of those would've worked in #Elisp without ever leaving #Emacs. Much of it with #CommonLisp and #SLIME too. Most of the implementations also come with #info #manuals and their source-code (for those things not mentioned in the manual), and hyperspec.el also handles searching through the #HyperSpec locally on one's machine (it's packaged on Debian) and provides keybinds to search symbols automatically right from your editor. C lacks most of this. @mhoye #Interlisp did it better than most modern #CommonLisp environments though, if what I recall hearing is correct, as the documentation didn't require additional setup (pointing the editor at the docs' location).  @mhoye@mastodon.social this is one of the reasons i generally stray away from things written in C(++) and why to some "not written in C" is seen as a selling point  Almost all projects/products have two mutually exclusive problems at the same time; "Too Much Information" and "Too Little Information", depending on WHO you ask and WHEN you ask. I think the "real" problem is much more about psychology and personal character. Why would software require less "practice" to reach "proficiency" than for instance becoming a doctor, a lawyer, a musician,...? I would argue that no matter what docs you have, it can't replace experience/practice. But maybe I am missing your whole point... If this was only about C/C++ not understanding what are warnings and what are errors, then perhaps you should chose to work with a different language. Most of the weird errors in C are due to legacy code, and you could (I do) set compiler switches to treat all warnings to errors. Every single one of us has probably made a joke about searching recipe blogs for basic information, and finding "Here's how you make boiled eggs. It's easy and fun! I was in an alley in the outskirts of Algiers in 1987 the first time I watched a man die. I can still remember the blistering sun, the smell. Since then" for like forty pages of meaningful story and protein chemistry, all while you are in front of a pot of boiling water with an egg and your question is "how long do I boil an egg". That is most of the tech documentation experience. Precisely like that, but with the detailed spec and the interface details instead of the dead man in an Algerian alleyway and the protein chemistry. I understand that might seem like a big difference but the experience is the same. @mhoye and in the end, it turns out the story actually took place in Tangier...  @mhoye also please note that this is the wrong printf manual, this is the manpage for the printf command-line tool not for the C function. if anything that strengthens your point, heh  @mhoye no no you're supposed to know gcc and a few other highly doctrinaire programs have a totally different help system called "info" that no one remembers to use.  @mhoye I'm not a fan of GCC's manual for a number of reasons, but it's infuriating how many distros feel like it's necessary to split out the documentation from it. Just package it as gcc-full (aliased to gcc) by default and if someone *absolutely* wants it without documentation then they can install gcc-bin or whatever. @mhoye you complain there's no docs and you stop reading the docs where there are examples using double quotes. Plus your issue is you're not specifying a string literal correctly. This is covered in the very concise K&R C book written over four decades ago. Every language has rules about literals. You do need to learn a language to use it...  Without disagreeing with you, I wonder whether it's possible (without true Artificial Intelligence) to consistently provide really useful error message, given the immense flexibility and power of even the simplest of programming languages (and the immense variety of ways a programmer can screw up). Documentation, on the other hand, suffers from having been written from the perspective of the people creating the program, not the people using it. I don't know how to fix that, either.  @publius @mhoye if you use your own thing, and you hire or work with people who are not as familiar with the thing as you are, or you just occasionally read the top Stack Overflow questions about your thing, it becomes fairly obvious where the documentation and/or error messages need to be improved. "For experts by experts" isn't a way to make software for anyone but yourself. @wakame @tess @publius @mhoye That sounds like a very dangerous experiment with significant privacy issues. In highly expressive and/or dynamic languages, it could also be of very limited use. (But then such dynamic languages usually also have dynamic checks that can tell you *why* the type of something is wrong.) "Rust has fixed that problem" ― in what way, and for whom? As someone who very occasionally writes computer programs when needed to solve a problem (I wrote a very useful one in Motorola 68000 assembly, that time), I've seen a lot of discussion about Rust, none of which seemed to address that question. Also I've seen suggestions that it's often necessary to call some kind of "foreign function interface", in which case, why not program in the target language instead? The Foreign Function Interface situation is best understood, I think - thank you, @Gankra ! - by reading this: https://gankra.github.io/blah/c-isnt-a-language/ ... but more generally Rust gives you a set of guardrails that obviate entire classes of sometimes sec-critical errors, and the error messages they give you during the development process are just generally wildy more helpful and humane than you see in most other languages. Yeah pretty much. Rust has managed to give better error results without AI or whatever. @mhoye A whole lot of that is just C being an awful language. Which okay might be related to the unix brainworms, but it's a bit chicken and egg at that point. Also the last error message literally tells you what to do right with a short example too. Which I think might be related to relatively recent improvements in GCC's messages (there's ongoing work there).  @lispi314 @mhoye the third leg on that stool is K&R, or short of that an undergrad course with C. There is a barrier of entry where you have to know what you are doing to know what you are doing. You have to get whacked by the paddle before they teach you the secret handshake. And like other kinds of hazing, or weeder courses, making people want to quit is the point @flyingsaceur @mhoye I didn't have much issues with such courses, but then I was already *working* in C by the time I had it so I unfortunately wouldn't quite know. I'm not sure which book I used to learn it, but definitely I wouldn't say that C is the kind of language you have a fun time learning exploratively. It's no Racket (which incidentally also has pretty great docs and error messages thanks to all the dynamic checks and contract stuff). @lispi314 @mhoye Yup - the UNIX way is to build up calluses and muscle memory. You probably saw that failing example and remember the figurative nun rapping your knuckles for mixing them up and never forgot. Pain, some will say, is the best teacher. On the other extreme, I’ve worked with Python stuff where I had to read the source to find things they never bothered to document. I’m still not sure how I feel about that @flyingsaceur @mhoye I'm not very fond of languages and systems that are not self-documenting at this point (which basically removes all non-dynamic languages). #Scheme implementations tend to not do this as well as #Lisp implementations in my experience, and rely more on external tooling to handle it. #Racket again does it somewhat better than other Schemes, but yeah. Unfortunately, I also recognize the need in some places for static languages, so I insist on duly standardized ones. |
Gregory's Server
"The arguments must correspond properly (after type promotion) with the conversion specifier. By default, the arguments are used in the order given, where each '*' (see Field width and Precision below) and each conversion specifier asks for the next argument (and it is an error if insufficiently many arguments are given)."
Uh... ok... look maybe we're getting off track here, that first error message said "character constant too long for its type", let's look for that.