Talk:C (programming language)/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

→

Archive 10

image of C crashing

I don't see how the image contributes to the article. It gives the misleading impression that many C programming mistakes manifest themselves in those symptoms, which is not the case. Therefore I removed the image. Neilc 00:55, 29 January 2006 (UTC)

C generally has a bad rep for quality, but there certainly are high-quality C apps. I agree that the image is misleading. It's hard coming up with images for an abstract programming language, but more suitable might be a picture of something famous/infamous written in C, like the logo for the Linux kernel. Deco 01:09, 29 January 2006 (UTC)

Usually on 'nix things just go belly-up with a segmentation fault error or something (and not something as "spectacular" as depicted), but the image appears to be a program running in DOS/Windows, which doesn't afford the same kind of protections that 'nix does... Dysprosia 04:51, 29 January 2006 (UTC)

I didn't look at the image, but I don't think the last statement is true. Windows protects against null dereferences and references to code areas in pretty much exactly the same way Linux does, via page mapping and trapping system exceptions. It only differs in its response after killing the process, which instead of printing "Segmentation fault" to the console and dumping core is to pop up a window saying that the application terminated abnormally with some debugging data. Deco 09:44, 29 January 2006 (UTC)

Perhaps I should have qualified first by saying that I don't really know about how DOS/Windows deals with things on a deep level (Sorry about that). I know Windows tends to handles things better, and definately more so with the later versions, but I still think DOS (more) and Windows tends to give greater latitude to errors than 'nix or the later versions of Windows do. My point still remains that an image of a mangled screen selectively chosen to demonstrate what goes wrong isn't really appropriate or common to what really happens when errors occurs. Dysprosia 13:09, 29 January 2006 (UTC)

As the originator of the image, I take exception (pun intended) to it's removal and the reason given. I contend that the image perfectly illustrates what I think of as a feature of C, rather than a criticism - in C, if you don't program robustly, you don't get robust programs. I've been programming in C since 1988, and taught the language at college for three years, and while I have moved on to the beautiful abstractions and environment protection of ++ and .NET, I still like to code test-routines in good old vanilla C - if I can get it to work, and work every time, in the unforgiving world of C, I know it's gonna perform at the higher level. I got the image just yesterday, when I miss-cast a double to a long pointer, and ending up "pointing" at screen memory - but hey, sometimes you want to "point" to screen-memory! C enthusiasts love the language's brutal, down-to-earth honesty, and part of the fascination is that programming in C is difficult - but people don't build Cutty Sark's out of match-sticks because it's easy, they don't build houses of cards without ever expecting them to fall; sometimes it's fun to bike without a crash helmet, and that's what C can be like. But with dedication and attention-to-detail, C forces you to program robustly, exposes you to spectacular falls, and you become a better programmer for it. (Even in ++, I never use automatic garbage collection, I always handle my own exceptions - I don't want the system to tidy up after me, I take responsibilty for that myself, as any good craftsman does).
In my experience of teaching C, I often found that students would initially baulk at C's rigour, but many ended up loving it - C's a hard task-master, but if you program diligently, the results can be highly rewarding.
I concede that the tag-line I added to the image may have been a bit flippant, and if it gave the impression that such symptoms are common, then that is misleading - in 18 years, I've only seen such a crash twice. But I contend that the image adds an important idea to the article - in C, if you program sloppily, you get sloppy programs.
So I am going to restore the image, with a better explanation. Please respect the wishes of an experienced C programmer, and Wikipedia inclusionist. Camillus (talk) 11:37, 29 January 2006 (UTC)

Incidentally, when I tried to preview this comment, my machine completely froze - I had to re-boot, I hadn't saved my remarks, and I had to start all over again - but hey, who's fault is that? As the image illustrates, shit happens!

I'm afraid we discuss things to reach consensus, not "respect the wishes" of just one user. I reiterate my point that an image of a mangled screen is not really representative of what happens most of the time errors occur in modern C environments. Dysprosia 13:09, 29 January 2006 (UTC)

Fair enough, if the consensus is that it's not representative, then remove it. It's no big deal. Camillus (talk) 14:55, 29 January 2006 (UTC)

I don't believe the image portrays anything particularly unique to the C language. You can achieve the same result by misusing pointers in Pascal or assembly, for example. Also, the submitted image seems to be illustrating a crash inside a virtualised DOS window running Turbo C, however modern day operating systems won't let you write directly to video memory from userland, so the image isn't a common depiction of what would happen after a C program has crashed, assuming the article needs one. See Crash (computing). ozzmosis 13:15, 29 January 2006 (UTC)

Me, I quite liked the image. It reminded me immediately of a spectacular bug which (A) I perpetrated 20 years or so ago, and which (B) occured under Unix. I was trying to add visual attributes (bold, inverse video, underline, etc.) to a full-screen, emacs-like editor I was writing, and I was trying to save memory by doing it with 4 bits per character cell, or two character's worth of attributes per stored byte. Naturally this involved some concise, cryptic pointer manipulations, and naturally I got it wrong at first. The etiiology was different than Camillus's, though: instead of scribbling on screen memory (which this editor didn't use; it was doing everything with ANSI escape sequences sent down the RS232 wire to a terminal), I had accidentally used a random pointer as the source of my array-of-nybbles screen attribute overlay. The rest of the code actually worked perfectly, displaying the proper underlying text, but with each individual character cell receiving one of 16 different random combinations of attributes. It was a marvelous piece of screen confetti, and it ended up being a nice affirmation of the fact that the rest of my attribute-rendering code was robust and properly general.

No, Camillus's image is not of a particularly common, specific consequence of a pointer error, nor are these errors unique to C, but it is a plausible consequence, and it is certainly a vivid, demonstrative, accessible image, particularly for the novice or non-programmer. As Deco notes, it's hard coming up with images for programming-related concepts, and I think we ought to celebrate the fact that we've actually got a half-decent one here. Steve Summit (talk) 16:30, 29 January 2006 (UTC)

Thanks for that, Steve - I knew an old hand would appreciate the image. It was meant to be slightly tongue-in-cheek, and appeal to the programmer and non-programmer alike. One of the things I love about C is that when you get spectacular crashes, you always go back to the code and find yourself saying - well yeah, it did exactly what I told it to do! (GIGO) - and sometimes you actually learn something quite useful! I don't do much C now, having moved on to the wonders of ++, but I was wanting to try something yesterday while I was away from my machine, so downloaded Borland's free C++ v1.01 - when I got the crash, I thought - hey - er, nice! and I thought other programmers would appreciate it. Apparently not. Anyway, I've zapped the image, as the consensus seemed to be arising that it was not representative. Oh well :( Camillus (talk) 18:28, 29 January 2006 (UTC)

The issue is not one of "appreciation" whatsoever. C does not always crash like that, and to have an image of a very rare form of crash like that may give the impression that this is normal behaviour in relation to C -- it isn't. It's really a matter of NPOV policy. Dysprosia 20:31, 29 January 2006 (UTC)

Hey - lighten up, why don't you? I deleted the image hours ago as I took the point that it was not representative of modern C. Get off your high horse. Camillus (talk) 20:46, 29 January 2006 (UTC)

I'm sorry? There was an issue at hand here, and I responded to it. This is what these discussion pages are for, discussion about issues and facts that are relevant to the article. I was not intentionally provocative, I made a reference to NPOV policy for your benefit, in case you were not familiar with it, and I don't see how participating in a discussion is in some way mounting a "high horse". Dysprosia 01:02, 30 January 2006 (UTC)

Well, for what it's worth, I thought your "issue is not one of 'appreciation'" reply was, if not provocative, certainly more strident than it needed to be. Yes, this page is for discussion of issues relevant to the article, but there can be legitimate differences of opinion on those issues. In particular, the issue here arguably is one of "appreciation" -- whether the reader would appreciate, and learn something useful from, the image. I believe that many readers would have learned something, and that with an appropriately-worded caption, there would have been little risk of misrepresentation. I'm sorry Camillus capitulated so soon in the face of a 2- or 3-critic "consensus". Finally, your definition of NPOV is very different from mine if you think it applies here. This was a valid illustration of a stray-pointer symptom -- a vivid one, albeit not an everyday one. But there's no POV involved. (The NPOV claim is particularly odd in the context of an article that has as many significant POV problems as this one does -- but that's an argument for another day.) Steve Summit (talk) 04:42, 30 January 2006 (UTC)

I said so in response to the comment that "I knew an old hand would appreciate the image", since debates about content inclusion are rarely about appreciation of the content and more about suitability for placement in an article. If that came over as overly "strident" then I apologize for the connotation. I was merely trying to draw attention back to the suitability of the image. However, an argument can be made, that, because of an image being placed on the article of a rare and uncommonly spectacular error occuring due to a C mishap, the reader may arrive at the mistaken conclusion that all C errors are as bad as this and thus form a negative opinion of the language -- clearly straying outside the bounds of NPOV. Dysprosia 10:45, 30 January 2006 (UTC)

Let's just draw a line under this, eh? I've withdrawn the image, accepted that it's not representative of modern C, therefore not suitable for the article. Next case? Camillus (talk) 12:24, 30 January 2006 (UTC)

Ok, I've provided one below ;) Dysprosia 12:59, 30 January 2006 (UTC)

After thinking about this I've somewhat changed my perspective. It makes a lot more sense in the context of the "Criticism" section where it was placed - if it were inserted as a lead image that would be misleading and inflammatory. If I could see it I might support inclusion, but it's gone now. Deco 23:05, 29 January 2006 (UTC)

Confusing wording

  >Parameters that are always passed to functions by value, never by reference

It is typical in C programming, and promoted by the C syntax, to pass pointers to functions. I agree that pointers are passed as parameters and by value, however, functions typically do end up with pointers. Therefore, a function may manipulate the value of variables, arrays and structures which have been passed to it using pointer parameters, which is the point of the issue. I suggest this to be more concise, and accurate:

  Parameters and references are always passed to functions by value.

What ??? this whole item is silly and wrong. this isn't C++, its C. Pointers are refererences: I make a struct. I pass the address of the struct to a function. What about this isn't pass by reference?

Actually, scalar arguments are passed by value, but arrays are passed by name.

No, they aren't. They decay to pointers when passed to a function (like they do in almost any expression), which are then passed by value. --Mellum 06:09, 13 September 2005 (UTC)

Pointers themselves (being scalars) are passed by value, but the pointer may be be used to pass by name / address (e.g., &num). (Remember to sign your contributions by entering four tildes) wrp103 (Bill Pringle) - Talk 01:38, 13 September 2005 (UTC)

Passing by name is different from passing by reference (which is similar to what happens if you pass the adress obtained with &num). Call by name reevaluates the expression every time it is needed, and is not supported by C. --Stephan Schulz 22:18, 18 September 2005 (UTC)

The statement is well worded. It is true that parameters are always passed by value in C, and it is the only parameter-passing mechanism C supports. However, one can emulate pass by reference to some degree by passing pointers (which are also passed by value) to a data object. Denis Kasak 11:12, 23 September 2005 (UTC)

  Some features that C lacks that are found in other languages include:
  >Automatic garbage collection

Local variables defined in a function are unallocated when the function is exited, unless defined static. Thus, C implementations do automatically free memory without the programmer needing to explicitly unallocate memory. Unless the memory has been allocated dynamically using malloc(), in which case, specific deallocation is required. I suggest:

  Automatic garbage collection of dynamically allocated memory

I believe the issue here is that in some languages (e.g., Java), you can explictly allocate data but you don't have to (or can't) explicitly free data. In Java you can use the new keyword to create an object, and Java will free it when it goes out of scope. You can do the same thing in C++, but you have to explicitly free each object. Local variables defined within a function are automatic variables, not dynamically created variables. wrp103 (Bill Pringle) - Talk 01:38, 13 September 2005 (UTC)

Automatic garbage collection commonly refers to automatic freeing of dynamically allocated objects. Local objects in C are not dynamic and therefore not garbage collected as such; their automatic nature is rather a consequence of the design of the language. Their scope is limited to the function in which they had been defined and they do not exist outside it. This kind of behaviour is not commonly referred to as 'garbage collection' and in my opinion nothing needs to be reworded. Denis Kasak 11:58, 23 September 2005 (UTC)

Reorganization!

I propose a reorganization of the series on the C programming language. I put forth the following four general article headings:

1. History of the C programming language—The creation and original uses of C, its development at AT&T/Bell Labs, the various attempts at standardising
2. Syntax of the C programming language—The syntax (grammar rules, not behavior) of C
3. Semantics of the C programming language—The semantics (behavior and relationships of syntatic components) of C
4. Standard C library—History of std library, list of headers, platform variations (BSD, GNU, VC++/Win32, Borland/Win32, etc.)

I think that the current situation is a mess and needs reform. Comments welcome, of course.—Kbolino 06:00, Apr 7, 2005 (UTC)

Sounds good. I assume you will also have a main article that will provide an overview of the language and pointers to the subarticles w/ explanations of their content. I would suggest that we also add a section on common techniques, which would cover and/or refer to additional articles that cover other subjects (e.g., malloc, the dynamic array issue, etc.) wrp103 (Bill Pringle) - Talk 16:03, 7 Apr 2005 (UTC)

Any reorganization should probably reflect that an encyclopedia article on a programming language might have several goals to address different kinds of readers, but that being in any way a tutorial (or even a reference manual) is probably *not* one of those goals. I can think of three worthy sections, all worthy of inclusion (i.e. as subsections):

1. classification (among other programming languages)
2. history (including versions of standards)
3. description of salient features (minimal, lotsa punctuation, much functionality deferred to library functions, etc.)

There's definitely a place for a few examples, if a reader wants to be able to recognize a C program when he sees one. But I doubt that a full syntactic or semantic definition of the entire language is necessary or appropriate. Steve Summit 05:53, 13 July 2005 (UTC)

Am I the only one that thinks this article needs a serious trim? Large parts of it should be split onto their own page; the main page should be about 20% of what it currently is. Akihabara 09:23, 22 September 2005 (UTC)

O Operators

can somebody please expand on the O(1) req on operators? O(1) as a function of what? Is a C impl on x86 for example is not complaint if for example the expr:

' x >>= c; ' is O(c) ? (since x86 shl reg,cl is O(cl)), how about mult/div? --Oyd11

I would try to explain it if I could find it, but I can't. Does this comment refer to some obsolete text? Steve Summit

---

Do you think it's good to use Evolution for writing down the changes, or K and R C will suffice? Thanks, Uriyan

Actually I don't think either topic deserves a sub-page. I think a section on the main page would do. --drj

Eccentricity

In C, the months of the year are numbered wrong. They are all low by 1. For example: January is month 0. December is month 11. This is not an obvious problem to English-speakers, but if your native language uses numbers to name the months of the year...

Numbering from 0 is not eccentricity. It's how computers think. --Taw

That also has nothing at all to do with the C language, but with the standard libraries--that distinction should be made. --LDC

Then why aren't days-of-month numbered starting from 0? 193.167.132.66 08:53, 10 Feb 2005 (UTC)

Because you probably don't have an array that stores the days of the month in text format. It is quite common to have an array of character strings w/ "Jan", "Feb", "Mar", etc. The same thing applies to week days ("Mon", "Tue", etc.) wrp103 (Bill Pringle) - Talk 15:43, 10 Feb 2005 (UTC)

I don't even think thats an eccentricity since its fairly common in programming to do it that way --Alan D

Fairly common today, but it wasn't in the Good Old Days. That makes it a fad, albeit a fairly long running one. Hint: make a list of languages since Day 1 and see when numbering from 0 began. GregLindahl

Java uses the same numbering scheme. Possibly because there is a zero-based array of month names. Although numbering from zero in both C and Java is more of a convenience for the routines that perform array handling than anything else. If your array starts at location AC00, the address of the 0th element is AC00, the address of element 1 is AC00 + element_length, the address of the 2nd element is AC00 + 2 * element_length, and so on. I prefer to start at element 1, but we're all pretty much stuck with the convention. (Perhaps I'll step up and start writing about software engineering, something I actually have some expertise in.) Ed Poor

---

Example date (works for C and Java): May 29
Month=4, day=29

Why is the month shifted but not the day of the month? Besides, if it is "the month is not a number", you deserve a slap in the face from your Korean (or Japanese or Chinese) secretary; ask her about it! In all these languages, May is literally "five month". (I think.) -- Juuitchan

Yes, but you'd translate it into english as 'month five' if you didn't want to use the name - 五月 is how you'd write it in chinese characters.

If you want to blame someone for the system in use, I'd suggest starting with the Jesuits, who as the scientific wing of the catholic church spread clockwork and steel cannons across much of asia. They also brought their date systems with them, which is why a 24 hour clock and seven day week is pretty much universally accepted.

The difference between day and month in terms of indexing can be reduced to that of the difference between both nominal and cardinal values and ordinal values.

The system we use uses nominal values for months, and ordinal values for days and years. It should probably use ordinal values for the lot. Note, though that Korean (and I expect Japanese and Chinese) uses cardinal values, rather than ordinal values for month. O-Ueol (五月) vs' O-Beon-JJae-Ueol (五番째月), except that normally the chinese characters aren't used in the second case.

This was probably far more than you wanted to know, but the point is that given that there are trivial mappings between these forms, the particular representation format chosen isn't that big a deal.

If you want to see _real_ problems with computational notions of time, I'd refer you to 'A Long, Painful History of Time' (Erik Naggum [1]).

-- 203.231.161.129

You know, some research shows the idea of clock work and units of 12 come from a much older basis even if promotion of that method was performed by others: This page examines the history of the 24 hour analog dial

-- laundrypowder

---

The claim that C is the dominant microcomputer applications language is now somewhat dubious, IMHO. In the Windows world, it's probably a toss-up between Microsoft's C++ and Visual Basic, I'd guess. C still rules for embedded systems (that is, the ones not written in Assembler), in the Unix world (particularly for apps that don't have a GUI), and people who can't be bothered remembering C++'s arcane semantics for multiple inheritance and operator overloading :) --Robert Merkel

How much Visual C++ is actually plain C with a tiny bit of C++ here and there? GregLindahl

Good question, but one which I don't know the answer to. The only big Windows development project I ever saw was in "real" C++, with a class hierachy etc. etc. It was an absolute PITA to work with, though - in the end I just gave up and wrote the code I needed by monitoring a socket interface this code had with a socket monitor I ginned up with Cygwin.--Robert Merkel

Any windows programming that uses MFC is making extensive use of C++, just by virtue of modelling windows in terms of objects. I think that's actually a good portion of Visual C++ programming.

Yup. Visual C++ (the language) is mostly C++. Of course, the product Microsoft Studio, Visual C++, has compilers for both the language C and the language C++ (and options to turn microsoft extensions to both of those language on or off). Secretly the two compilers are the same, but accepting different input languages.

Programming languages on Unix and Windows

Recent stats of what percent of code in RedHat–dash is written in which programing language, clearly shows that C# is dominant, at least on Unices. It's very probable that C++ is much more popular on Windows Word, but I seriously doubt that many apps are written in VB. --Taw

Links to manuals and tutorials

It would be nice to have links to an online manual and online tutorials. There probably are some with under the GNU Free Documentation License. --Hirzel

---

comp.lang.c (a wonderful resource for C, btw -- some very competent people there) recommends Tom Torfs' tutorial at http://www.geocities.com/tom_torfs/c.html and Steve Summit's class notes at http://www.eskimo.com/~scs/cclass/cclass.html.

Honestly, most online tutorials for C are terrible and demonstrate that the author has little clue about the actual C standard. --mgmei

High level language

Moved from article:

C is a high level language, meaning that the source code of a program can be written without detailed knowledge of the computer's CPU type. Before the program can be used, the source code must be translated into the required machine language by a compiler. In contrast, programs written in an assembly language can only be run on one type of CPU.

(The above definition of high level language is not meaningful. Consider the evolution of the x86 instruction set toward virtual machinehood. Does this mean that x86 assembly is a high level language?)

If we insert "of abstraction" between "level" and "langauge", the phrase becomes less ambiguous, but also

somewhat awkward. Regardless, can a language which saddles the programmer with responsibility for

memory management really be considered to have a high level of abstraction? C is clearly more abstract

than most assembly languages, but that hardly makes it high level.

I'm not sure what 203.231.161.129 means about "virtual machinehood", but I can see that under this definition, x86 assembly language could be considered a high level language due to the existence of emulators. -- Tim Starling 07:54 26 Jun 2003 (UTC)

Modern x86 implementations are more and more moving toward risc cores running virtual machines (in microcode or whatever) which provide x86 compatible instruction sets. Hyperthreading for example, is a case of attempting to exploit such an underlying architecture without affecting the definition of the x86 machine (ie, mapping many registers to the x86's few, so that you can increase some hparallelism).

In this regard the x86 architecture is shifting toward defining a virtual machine, much like JVM, rather than specifying a hardware cpu. Not that there is a meaningful distinction in any case.

Likewise, we can see C programs running in a virtual machine defined by the C standard, and supported by the runtime structure of the binary produced.

High and low level are fundamentally ideological terms, and have almost no objective meaning, nor objective definition what-so-ever. So far the only meaningful definition of level that I've found has been in terms of 'the ability to express invariant structure' with more being higher level. Note that by this definition, python ends up being only slightly higher than assembly, since it has almost no ability to define invariant structure.

I wish people would stop using these terms, anyhow, as they are very silly.

-- 203.231.161.129