LWN: Comments on "Quote of the week"

Some idle comments about Linus' e-mail response and Linux

i3839 — Thu, 08 Mar 2007 23:49:38 +0000

He doesn't ask for a GUI front-end slapped on top of a command line interface, he asks for programs that have both both kinds fully functional. And preferably the GUI version prints out the command with options what would do the same action as the GUI action just performed.

Good taste is to write your programs in a modular fashion so that slapping different kinds of interfaces on top of it is peanuts, no matter if yourself are only interested in one.

This makes it also easier to write KDE/Gnome/Qt/GTK/FLTK/ncurses versions of GUIs, as not everyone wants to install all existing kitchen sinks just to run a single application. And you know what, it makes it much easier to port such programs to different environments much easier. 3D OpenGL GUI, or a low resources embedded device: Same code, only different GUI, your program shouldn't care.

Other good taste is to dynamically load needed libraries when you need them, instead of creating a dependency hell of mostly unused libs, which cause programs to fail starting up when they miss. Compile options are NOT an option: Distro's will just enable them all, just in case.

Some idle comments about Linus' e-mail response and Linux

bk — Thu, 08 Mar 2007 10:36:21 +0000

While I agree in general, the GUI-frontend-to-a-command-line-engine design is backwards and horrid. The communication is nearly always in one direction with no clear way to communicate failures or unforseen events to the user. In fact most of the time the app can't even indicate 'busy, please wait...', it just hangs frozen for an indeterminate period of time.

strncpy

ncm — Thu, 08 Mar 2007 06:53:08 +0000

In its origin strncpy() had one purpose: filling in directory entries in Version 7 Unix file-system code. It was always called with a length argument of 14, which was the size of the filename field in the struct, and the limit on filename length. Directory entries were zero-filled, not null-terminated.

The real mistake was adopting it into the ANSI C standard library as if it were a regular string function. Of course it's equally a mistake to use it. Nowadays, snprintf() might be a better choice, but a function that calls abort() if its argument is longer than the buffer would be better still. The BSD strlcpy() is another mistake, a fact fortunately recognized by POSIX.

Of course the right thing is to eliminate null-terminated string operations, but that's harder to retrofit.

bad taste

nix — Tue, 06 Mar 2007 23:07:47 +0000

Also h_errno and all that it implies; hell, the entire
grossly-non-Unixlike BSD networking stack.

bad taste

nix — Tue, 06 Mar 2007 22:52:52 +0000

Quite.

Plus, the length byte was never long enough, and the overhead of keeping
the length up to date dominated surprisingly often, even dead-reckoning
them. At least with null-terminated strings you don't need to work out the
length unless you need it.

String ADTs make more sense :) internally they can do whatever they like,
possibly a varying representation depending on the length.

I did this and more with an adaptive string ADT I wrote a few years ago
for an application my then employer wanted. If you kept asking for the
length of a string it started tracking the length itself; if you kept
inserting and deleting from it, and it was long enough, it switched the
representation to a buffer-gap; if you kept on asking for subsets of the
string and it was long enough to blow the dcache (I randomly picked 64Kb),
it turned itself into a position-keyed binary tree, and if the string was
long enough and rarely-read enough it started zipping the longer and
more-rarely-referenced hunks up with zlib.

There would doubtless be more tricks I could have used, but that was all I
needed to get performance up for that application. It wasn't dealing with
strings longer than 200Mb, after all. ;)

One of these days I should rewrite it (I'd call it `clean it up' but it's
too dirty for that, it needs a rewrite, not least because I want to hold
the copyright this time) and release it, only there's probably no point as
someone else has doubtless written something much better.

(Judy trees, which I didn't discover till much later, of course knock the
socks off this, but their API uses such awful names for basically all its
functions that I've not yet been able to bring myself to use them. I
wonder if they'd accept a patch adding names that it's actually possible
to remember? The Great Lowercase Letter and Vowel Shortage ended *years*
ago...)

Some idle comments about Linus' e-mail response and Linux

bronson — Tue, 06 Mar 2007 15:49:23 +0000

strncpy(3) leaving truncated strings unterminated.

I'd love to know who was responsible for this one. He should spend the rest of his days trying to explain it to people just learning C. Students seem to think it's some strange example of good design ("well, if strncpy does it, then it must be OK") and emulate it in their own programs. *shudder*

bad taste

njs — Tue, 06 Mar 2007 06:59:12 +0000

Dunno what nix was thinking either way, but I'd draw a real sharp distinction between "length prepended" and "length indicated". string buffer plus length sitting next to it (or wrapped up in a structure) = The Right Thing, string buffer with initial byte overloaded to indicate length = eewwwwwwww.

bad taste

ldo — Tue, 06 Mar 2007 00:50:53 +0000

Back in my Mac programming days (pre-OS-X), the APIs were full of "Pascal"-format strings, which started with a length byte. A maximum length of 255 may not sound like much, but I estimated that over 90% of the string objects in my programs fitted quite comfortably into this limit.

One thing, I was always careful to pass maximum buffer lengths. To reduce the chance of mistakes, I used macros like this:

#define Descr(v) (void *)&v, sizeof v

which I would use like this:

CopyString(Src, Descr(Dst));

That way, if the destination buffer was too small for the string, the worst that would happen was that it was truncated--you would never get overwriting of random memory.

bad taste

ldo — Mon, 05 Mar 2007 23:29:55 +0000

...but can someone give me an example of bad taste in programming?

errno(3).

bad taste

k8to — Mon, 05 Mar 2007 21:14:01 +0000

Is there a real problem with length-indicated strings, or just using them in environments that are built around something else?

Certainly using them where they don't belong is awful, but I don't see a problem with them fundamentally.

bad taste

nix — Mon, 05 Mar 2007 13:35:12 +0000

Also, length-prepended strings. :)

Some idle comments about Linus' e-mail response and Linux

k8to — Sun, 04 Mar 2007 09:04:53 +0000

Oh absolutely. I just find it impressive that they couldn't even figure out that "files" are not just windows api constructs, but really exist on the disk, and so the name is just wrong. It's like opening and closing quotes to the explitive which is the implementation.

I've unfortunately programmed the win32 api before, although in its "sanitized" form, called Mono.

Some idle comments about Linus' e-mail response and Linux

dwkunkel — Sat, 03 Mar 2007 17:40:22 +0000

Oracle's SQL Developer does this. Almost anything that you can do with the GUI has a tab labeled SQL that shows the SQL code that will be executed. This has also been an integral part of Oracle's Enterprise Manager for many years.

bad taste

ldo — Sat, 03 Mar 2007 04:37:12 +0000

...but can someone give me an example of bad taste in programming?

Null-terminated strings.

Some idle comments about Linus' e-mail response and Linux

nix — Sat, 03 Mar 2007 02:08:12 +0000

The &bad_ctype is non-tasteless, I'd say. It's *transparent* and you can
easily tell what it's doing when you read the code. And it doesn't dump
core if you dereference it :)

Some idle comments about Linus' e-mail response and Linux

nix — Sat, 03 Mar 2007 02:05:11 +0000

The billion insane flags and magic secret interactions are worse. It makes
open()+fcntl() look sane and pleasant.

Off-topic: Windows ME

pr1268 — Fri, 02 Mar 2007 05:26:54 +0000

Off-topic: I think the Windows ME period of my home computing history lasted all of 3 hours. Spring 2000, if I remember correctly, and I installed it fresh on my homebuilt computer.

When I tried right-clicking a file inside of Windows Explorer → copy → right-click in blank area of Explorer → paste, the Explorer shell screamed bloody murder telling me "Cannot paste file, it already exists!" (All I was trying to do was duplicate a file in the same folder. Every other OS I've ever used [including other variants of Windows] has allowed me to at least give a different name for the new file.)

I couldn't wipe the hard drive fast enough to rid my PC of that vile, contemptible trash.

Some idle comments about Linus' e-mail response and Linux

proski — Fri, 02 Mar 2007 02:04:04 +0000

And here we see Linus himself suggesting almost the same thing. No, it's not that bad, since it's a valid pointer, but it's close enough :)

Some idle comments about Linus' e-mail response and Linux

k8to — Fri, 02 Mar 2007 01:00:25 +0000

The name, for starters.

Some idle comments about Linus' e-mail response and Linux

cpeterso — Fri, 02 Mar 2007 00:41:30 +0000

Win32's CreateFile() API scores many Bad Taste points:

http://msdn2.microsoft.com/en-us/library/aa363858.aspx

Some idle comments about Linus' e-mail response and Linux

nix — Thu, 01 Mar 2007 19:36:37 +0000

All the examples so far have been macro-level.

On the micro-level, it's Bad Taste to write code which `happens to work'
without concern that it's grossly, obviously disgusting. e.g. one I saw
many years ago (and fixed at once) had a function looking ocnceptually
something like (identifiers anonymized to protect the guilty)

struct foo *get_foo(int a, long b, const char *c);

and they wanted to return `a foo', `no foo to find' and `error while
looking for a foo'. So they returned a foo, NULL, and, um, (struct foo *)
1.

And *that* was bad taste. Sure the pointer was never dereferenced if it
was 1, so it wasn't technically a standards violation. But the hidden
unexpectedness of that return value, and the absence of any hint except in
its various callers that this might happen made it Bad Taste. (To add
insult to injury get_foo() also assumed a different meaning for a
null-string-valued `c' parameter and for a NULL `c'...)

(of course I called it. Of course I didn't expect this return value. But
when the program crashed on an error path, I didn't consider it *my*
fault. It was the fault of the author of get_foo(). Some adjustment of
55-odd callers later, and it was no longer doing such a vile thing.)

Some idle comments about Linus' e-mail response and Linux

Randakar — Thu, 01 Mar 2007 11:37:48 +0000

Well, it's easy to gush; As far as kernel development goes his track record of being right on the money is pretty good IMHO*.

Of course one may not always agree with how he stands on the political divide with regards to licensing, but at least the man's viewpoint there is well-articulated and understandable. (wrong, but understandable ;-) )

*) and I've been watching for years

Some idle comments about Linus' e-mail response and Linux

NRArnot — Thu, 01 Mar 2007 10:57:26 +0000

Bad taste in programming?

Just about everything that inflicts a GUI interface without a scriptable command-line equivalent. Especially if it is obvious that the same thing is likely to need to be done many times over to a set of entities, and double-especially if the GUI actions spread themselves over more than one screen (so you can't even just type in the next entity name and OK again).

Really good taste would be a GUI interface that generated command lines where you could see them (and scroll, edit and re-execute them). Then the GUI would become a learning tool rather than a barrier to learning.

Clarification

pr1268 — Thu, 01 Mar 2007 06:49:48 +0000

The whole "skilled programmers with good taste" blurb was part of Linus' entire message; only an excerpt appears on this page. My original post is identical on both pages.

Some idle comments about Linus' e-mail response and Linux

drag — Thu, 01 Mar 2007 06:15:14 +0000

""I know the difference between skilled and unskilled kernel programming, but can someone give me an example of bad taste in programming?""

Windows ME

I know certainly that that POS left me with a bad taste all around.

Some idle comments about Linus' e-mail response and Linux

pr1268 — Thu, 01 Mar 2007 05:31:14 +0000

Having read Linus' reply, I kind of get why Linux has been so successful: It's the quality assurance model of hundreds of skilled developers with good taste all looking out for each other. A network of trust has been built amongst some of the more experienced kernel hackers (People such as Andrew, Greg, Alan, Theodore, Adrian, Al, and others come to mind) who are given a bigger share of responsibility for ensuring the quality of the kernel code remains high.

Plus, it seems anytime Linus' comments get posted on LWN, it's often a rant or tirade about sloppy kernel programming (if not about some marketing or legal blunder that negatively impacts Linux [i.e. DRM, etc.]). This is not meant as criticism. In fact, I bookmark a lot of these posts because Linus generally has nothing but adroit, intelligent advice on programming, operating system theory, and computers in general. I gather that Linux also owes much of its success to the idea that many FLOSS community members respect Linus for his expert knowledge. I certainly do.

Enough with the Linus-gushing. I know the difference between skilled and unskilled kernel programming, but can someone give me an example of bad taste in programming? ;-)