Email or username:

Password:

Forgot your password?
Top-level
mhoye

"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.

34 comments
mhoye

Let's try something different, maybe gcc --help will do something.

And holy shit does it ever.

Greg Wilson

@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.

mhoye

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?

mhoye

The printf manual doesn't admit the existence of "multichar" either.

mhoye

"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.

immibis
@mhoye in this particular case the trail of breadcrumbs would have been basic language knowledge.
powersoffour

@mhoye I think this is an excellent walkthrough of an all-too-common situation. Thanks for taking the time to make it.

immibis replied to powersoffour
@powersoffour but the example is something you would see if you tried to learn the language by trial and error. It reminds me a little bit of the question about trying to compile a PNG file in that the problem is someone using the language without knowing the fundamentals. Otherwise we can imagine many other similarly confused questions: A very common one is

void f(char *s) {
s = malloc .......
}
followed by asking why calling the function doesn't modify its parameter. How do you tell someone this without teaching them how pointers work?
@powersoffour but the example is something you would see if you tried to learn the language by trial and error. It reminds me a little bit of the question about trying to compile a PNG file in that the problem is someone using the language without knowing the fundamentals. Otherwise we can imagine many other similarly confused questions: A very common one is
owen

@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.

owen replied to owen

@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.

Sherri W (SyntaxSeed)

@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.

maegul replied to Sherri W (SyntaxSeed)

@syntaxseed @mhoye

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.

MikeStok replied to Sherri W (SyntaxSeed)

@syntaxseed @mhoye @gvwilson after a few decades watching and doing software development and maintenance I have these recurring thoughts:

- I wish I had been taught the basics of technical writing at university.
- When I need to do some focussed thinking it seems the tooling and environment developers often use seems designed to prevent that focussed thinking.
- How things fail is just as important as if they succeed to both users and maintainers.
- (thatโ€™s enough)

Graydon Hoare

@mhoye On the one hand I agree that the error messages are unhelpful here and, if we were a gcc dev, we could set off on working on this.

On the other hand, I think that (gestures to mountain of even worse unix and C diagnostics, docs, and even conceptual structures) realistically isn't going to have a dent put in it in our lifetimes. Too much sunk cost, too much compatibility burden, too much else competing for attention of the people working in that space.

I think there's a way to approach it as a historical expedition, where you accept it on its own terms and adapt yourself as you would if learning to build a shelter out of sticks or whatever; and there's a way to deal with it by mere avoidance; and definitely a constructive thing for those of us with the scar tissue to do (produce more appropriate tools that function at a similar level). But I think the "retrofit in place" approach is potentially even more work than that, and will produce worse results.

@mhoye On the one hand I agree that the error messages are unhelpful here and, if we were a gcc dev, we could set off on working on this.

On the other hand, I think that (gestures to mountain of even worse unix and C diagnostics, docs, and even conceptual structures) realistically isn't going to have a dent put in it in our lifetimes. Too much sunk cost, too much compatibility burden, too much else competing for attention of the people working in that space.

mhoye replied to Graydon

@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.

Yahe

@mhoye It also told you that the format string is not a string literal?

LisPi

@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.

LisPi replied to LisPi

@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).

Mark W. Gabby-Li ๐ŸŒ

@mhoye The problem is not documentation, it's the C programming language.

While C is an excellent and elegant language in many ways, it's simply not designed with user-friendliness in mind.
It doesn't even offer basic type safety, as your example plainly demonstrates, letting the user do extremely destructive things that they would almost never want to do, with almost no guardrails.

It is legal to send an integer where a pointer is expected. That's C. Can't fix that with an instruction manual.

@mhoye The problem is not documentation, it's the C programming language.

While C is an excellent and elegant language in many ways, it's simply not designed with user-friendliness in mind.
It doesn't even offer basic type safety, as your example plainly demonstrates, letting the user do extremely destructive things that they would almost never want to do, with almost no guardrails.

delta :akko_bean: :verified_gay:

@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

sure C is fine if you're already an expert in it, but if you're not? its just pure pain

Niclas Hedhman

@mhoye

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.

Niclas Hedhman replied to Niclas

@mhoye

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.
Number of warnings tend to build up over time and quickly becomes "invisible" due to the noise.

mhoye

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".

mhoye replied to mhoye

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.

Jan Stฤ™pieล„ replied to mhoye

@mhoye canโ€™t say I havenโ€™t been there myself

Greg Wilson replied to mhoye

@mhoye and in the end, it turns out the story actually took place in Tangier...

mhoye replied to Greg

@gvwilson I think we can agree that the important thing is that the egg was easy to peel and firm on the outside with just a bit of runny yolk in the middle.

Irenes (many)

@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

Nelson Minar ๐Ÿงšโ€โ™‚๏ธ

@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.

Nelson Minar ๐Ÿงšโ€โ™‚๏ธ

@mhoye I totally agree with your larger point! I'm making fun of the GNU info program, which (I believe?) is still the authoritative docs for the GNU C Compiler. Your answer isn't those docs either.
Part of the blame here lies with C as a programming language and some of the weirdness of the type signature of printf. It's tricky for a C compiler to print a more useful error here, although I think printf would be worth a special case in the error handling. I'm not sure any set of docs can swiftly get to this answer, a Google search actually works OK.
I do appreciate that Python tries to be more humane about this kind of thing, but it has plenty of rough spots too.

@mhoye I totally agree with your larger point! I'm making fun of the GNU info program, which (I believe?) is still the authoritative docs for the GNU C Compiler. Your answer isn't those docs either.
Part of the blame here lies with C as a programming language and some of the weirdness of the type signature of printf. It's tricky for a C compiler to print a more useful error here, although I think printf would be worth a special case in the error handling. I'm not sure any set of docs can swiftly get...

Dr. jonny phd

@mhoye
I fucking choked laughing at this holy hell

LisPi

@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.

Kevin Lyda

@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...

Go Up