I love when a seemingly simple snippet of code demonstrates so many layers of understanding and misunderstanding.

To all those who do not understand why to program in C, several of the posts address this well. I’ll add this:

Cis essentially a ‘portable assembly languge’, and it is in fact more portable than any other language, when some consistent care is taken to be portable. The language is very expressive and occupies the closest thing to a sweet-spot between the machine model and the human mental model, and it is quite readable, if a modicum of discipline and consistency is applied when writing in it.

There are more platforms out there than most programmers generally imagine. Everything from embedded systems that run the telephone networks to various realtime industrial processes, to global scale transaction processing on mainframes, to network management, robust database internals, cryptography, and operating systems are often written in C. It’s not all just Windows, Linux and the Web.

Using strdup() isn’t really sensible either, although it’ll probably work. The issue is that strdup() and friends can all return NULL when OOM (Out Of Memory) occurs, which just piles on to the code’s length.

The other issue is that a general rule of thumb in C is to never expect to have to call free() yourself. If you’re making an API that handles, say, foobars, you’d probably have a foobar_new() which returns a new structure of that type, and a foobar_del() or likewise, even if it just does a simple free().

Reasoning behind it is that it allows the API to expand or shrink. It is a crucial part of API design; never let the user (the user of the API) fiddle with the internals. There’s a Google TechTalk on it, I’d link it but I’m much too tired.

The correct code is entirely logical. People saying “C isn’t for humans” just aren’t used to how manual memory management works (the alloca() version isn’t a good idea either.)

As a decent C programmer, and that’s what our original poster is trying to say, you know what to do here. The callee will give the called function operational space. (See numerous functions in libc; fgets(), recv(), …)

Oh and for the record, just malloc()ing senselessly isn’t such a good idea either because you have to check if you actually got memory allocated.

If I had to do this I’d use a char[128] or so, and then pass it to the getpass() function which would _naturally_ only copy so many chars into a given char *.

With all due respect, I understand the feeling that washes over a person once one comes to “understand” the deep intricacies of any topic via having read a seminal book on the topic. However, I feel that being required to read such a thing before being able to ask questions about the standard difficulties one encounters when coding C is too curt, akin to RTFM, Stockholm Syndrome-style. Yes, it’s a badge of honor, but it’s not worth anything to anyone but your peers. If it seems to most everyone coding in C that C has some really wacky problems inherent to it, then the onus is on you to refrain from RTFMing the loln00bz. The onus is on you to justify obvious shortcomings of C (which happen to be side-effects of its truly obvious advantages).

Even if C’s shortcomings are just the fact that most people who start coding in C don’t follow the properly-prescribed way of doing so. I mean, do YOU read the entire book that comes with your cellphone before you dive in and start messing around with its features? No. Like TCP/IP, the human way is a “best effort” attempt at extracting what “just works”, even if it’s “highly illogical”, and even if, in the long term, there would be significant time-savings to learn things “the proper way”. Some of us trade depth for breadth sometimes and wish for smoother translation between the breadth component of our existence and the depth of yours. Without snippety YOU CLEARLY DIDNT READ uZ TEXTBOOKZ,NOOBIAN.

“Computer, end program.”