|
Top-level
 The number of people in this thread who are willing to tell me that the real problem is how stupid everyone is is incredibly embarrassing. Look, here's what happens when you compile Hello World with single quotes instead of double quotes. Note, please, that these are warnings, not errors. GCC finishes and produces an a.out executable. 73 comments
 @aburka it will segfault and crash. @aburka ...Running it, printf will attempt to find a format string at location 72 of the memory. And crash. There are helpers in GCC for printf, but currently they only check if *the static string* is a proper format and match the argument. They currently cannot check that the wrong type (a character instead of a string) was provided. @dryak that would require an intimate knowledge of the C language and its typing system (not trivial depending on one's background). And a complete overhaul of how C is parsed in order to carry over the necessary extra information about type to detect this. BUT!... @dryak @aburka Programmers don't like to specify conversions manually, so that's what you get, although C makes it extra spicy by quietly ignoring loss of precision or sign (and compilers don't catch all such errors, it seems). Geez, that doesn't look good, but they're just warnings, maybe not deal-breakers. So let's run it and see what happens! An... immediate segmentation fault. Ok, well all those warnings are in printf so let's go look at the manual for printf. https://www.man7.org/linux/man-pages/man3/printf.3.html Oh, yeah, check this out. You can tell we're on the right track: 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. "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. 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.  @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.) @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. @mhoye It's always funny to reply to Mr. Chu with a link to the CVE list for openldap. If he's going to argue the Tired Uncle Bob position of "just git gud, what's the problem," he should have his nose rubbed in his own results for it. @mhoye I've been doing a lot in Rust lately. The error messages are ultimately helpful, but can be overwhelming, especially when you start dealing with lifetimes or lambda functions. And I do get that "just learn to read" vibe when I see folks asking for help deciphering them. It's unfortunate. @mhoye It's not the *most* toxically-mastodon thread I've ever seen but "people are illiterate and stupid" -> "you just need regex bro" is quite the take. @mhoye I dunno man, I've seen some garbage error messages from compilers but this one is litterally pointing at the mistake. I've had to work a lot of juniors around how to read error messages and stack traces but I'm not really sure of a better way to indicate issues (especially in a way that's applicable to multiple possible problems). It might be nice to have a somewhat less judgmental place (than stack overflow) to search for common issues though, especially for beginners. @pxlplz I understand your point, but there's only so far away from the actual error you can with Hello World. It's a Hello World example, you know? We can try a slightly different example, with the quotes fixed but % in the string, but this one is a lot less dramatic - a person with the on-device docs would have a real shot at quickly realizing that "%" is a special-case escape character (at least, if they're lucky enough to read the BSD docs, which are notably better than the Linux versions.) @mhoye That's indeed a perfect example of PDP-11 concepts leaking into modern coding errors: As I've discussed elsewhere in the thread the main problem is C itself, it's too leaky as an abstraction of assembler, and its type system makes this code perfectly valid (but doesn't do what one think it does). If one isn't a C guru, it's difficult to track down. A linter to spot the pattern would have helped. The "multichar warning" could be a bit more expanded to cover that user error in details.  @mhoye I had a good laugh at this. Not defending GCC here, I am all in favor for a languages that help to avoid errors in all stages. Anyhow, the last line food be a give-away "%s" but in that it does a pretty bad job indeed. And while lots of docs are garbage, how about to condone the usage of C/C++ in the first place? |
Gregory's Server
@mhoye morbidly wondering what a.out does if you run it