Pointer confusion in C -language

[TheCalligrapher]

If you think you need to consult the C standard to prove why the above is not a constant with value 1, I recommend switching to a different programming language, or perhaps another career.  The purpose of the C standard is to describe existing behaviour developers should be able to rely on, according to the very cover sheet of the standard.  Proving why existing, intuitive, correctly working as expected code should not work because of an esoteric strict reading of the standard, has nothing to do with programming, and everything to do with linguistics (of human language) and language-lawyerism.

While I understand the point you are trying to make, I don't see why you decided to abuse the language terminology while doing so.

In general case the above expression is not a constant at all (regardless of its value). And if you don't want to dive into the peculiarities of C standard, I can instead demonstrate it with a simple practical example

Code: [Select]

char static_buffer[1];
int a[static_buffer == (char *)(&static_buffer)];

int main()
{
  char local_buffer[1];
  int b[local_buffer == (char *)(&local_buffer)] = { 0 };
}
In the above code sample declarations of `a` and `b` are invalid, i.e. they will fail to compile in many real-life C compilers. And they will fail to compile specifically (!) because in C your `(buffer == (char *)(&buffer))` is in general case not a constant at all, not a constant expression.

http://coliru.stacked-crooked.com/a/24d47b2b9caf797e
http://coliru.stacked-crooked.com/a/9c6591575b93393d

Again, while I understand the point you are trying to make, your remarks along the lines of "If you think you need to consult the C standard..." clearly and unambiguously indicate that it is you that would be better off "switching to a different programming language". I hope you simply misspoke.

This kind of abuse of terminology is underlying reason for 99 misunderstanding out of 100. Most of unnecessary internet noise grows out of such roots.

[DiTBho]

@TheCalligrapher
are you a C-compiler writer? if so, for which architecture, and based on what? LCC-v3? LCC-v4? lib-llvm/clang?

[Nominal Animal]

In general case the above expression is not a constant at all (regardless of its value).

If that is exactly true, give me one example case where it evaluates to anything but 1.  I'll wait right here; don't you dare just brush this off.

The fact that compilers have difficult time recognizing that fact, and instead treat the arrays as VLAs, and therefore interpret the code to be in error, is a separate issue; compilers are stupid, but we work with them because we have nothing better.  And I know at least half a dozen expressions that do that to a compiler; so what?

(Edited to add: Yes, I fully expect you to respond with something as inane as "Even if the value of an expression is always 1 and can never be anything but 1 in C, that does not make the expression a constant". From the point of view of someone using C to write actual real world programs, that statement is illogical and insane.  I prefer sanity and the real world over the world of language lawyers and theoretical abstract state machines every single day.  The only concession I am willing to make to a C compiler writer is, if they just come out and say that "okay, the expression is constant, but we don't really have a good way to make the compiler see it, so at least for now, we cannot treat it as a compile time constant in all cases, especially those calculating array sizes.  It has to do with the phase at which the constant-ness of the expression is detected, you see", then I nod and shrug and deal with it.  Real world and all.)

[TheCalligrapher]

If that is exactly true, give me one example case where it evaluates to anything but 1.  I'll wait right here; don't you dare just brush this off.

It cannot. The value of that expression is always 1. But from the language point of view it is neither a "constant", nor a "constant expression".

The fact that compilers have difficult time recognizing that fact, and instead treat the arrays as VLAs, and therefore interpret the code to be in error, is a separate issue; compilers are stupid, but we work with them because we have nothing better.

Compilers just follow the language specification. It is the language specification that is supposedly "stupid", by your logic. But the reality is that the language specification often has good (if non-obvious) reasons to make the decisions it makes. Especially in situations where address comparisons are involved.

C language does not even recognize `const int a = 42;` as a constant. This might be called "stupid", but that's just a historical peculiarity.

[Nominal Animal]

As an aside: If you ever use a C or C++ compiler to write complex freestanding code, for example to implement an operating system kernel, you do need to be fully prepared to deal with the developers of the compiler you use.  Some of them will insist that just because the C standard says that this expression is undefined, although you have shown that the only sensible real-world usable code generated for that expression is this machine code, and it yields a crucial operation needed in practice, and here is the patch that makes it do so in a manner that is natural to the codebase, does not mean that the compiler should be changed.  In fact, they will reject any such patches with extreme prejudice, because they simply believe they are servicing the C standard, and not the users of their product.

Let that sink in.  It is true, and for example the GCC - Linux Kernel cases well documented, and numerous.

This is annoying, but even very technically adept humans can be utterly, utterly stupid about the real world.  No, they never change or learn; but they do sometimes get replaced when the number of complaints by the users reach high enough numbers (a number of core GCC devs got kicked out because of exactly this years ago).

We have to deal with them, because killing them on sight is a crime.  Which is a pity.

[Nominal Animal]

Compilers just follow the language specification.

That's where we fundamentally disagree.

Compilers translate human-readable code to machine-executable code.  They do so on behalf of their users.  They are not envoys of the C standard.

And there is nothing on this Earth that will make you understand or accept that.  Not even if I point out that even if the C standard was completely abolished and removed from all media today, it would not affect whether a single C compiler worked tomorrow or not.  However, if all C compilers started suddenly producing code that technically follows the C standard, but is useless in the real world, they would be replaced with something sane faster than you can read your Holy Standard from end to end.

C language does not even recognize `const int a = 42;` as a constant.

Are you terminally stupid, or do you just skip what I've written?  I've explained what const volatile int x means from the programmer perspective, and it has nothing to do with constancy, and everything to do with promises between the programmer and the compiler.

At this point, I'm dropping you into my ignore list, because I just cannot stand people who believe that doing X is okay because "the standard says so" or worse, because "the standard doesn't say that doing X is okay, so I must assume it is not okay", even if it is utterly idiotic and useless in the real world.  I'm not interested in the make-believe La-La world where The Standard is the truth and the real world is just an irrelevant side note, because I live in the real world, and utterly reject the relevance of the standards except to the extent they are useful in the real world

[DiTBho]

As an aside: If you ever use a C or C++ compiler to write complex freestanding code, for example to implement an operating system kernel, you do need to be fully prepared to deal with the developers of the compiler you use [...]

Yup 

Just to give a fresh example of what I am fighting against just right now, Linux kernel v3.4.39 doesn't compile with anything > gcc-v4, and if you look at the reasons ... you find it uses several inner functions that explicitly rely on how gcc-v4 handles some implementation details.

If you hack the compiler-check to force a build up with gcc-v5...v10, the kernel somehow compiles, but then it doesn't work correctly, it emits oops like if it was raining and does panic pretty immediately after the boot, whereas when compiled with gcc-v4.1.2, everything works as expected.

(edit: yes, it for that bloody Allwinder H3 SoM ... it's really a horse kicking)

[TheCalligrapher]

Wow!

I think, folks, we are dealing with a classis case of either

1. An individual, who realizes that understanding the language specification (aka "The Holy Standard") is beyond their intellectual capacity, and subsequently assumes defensive/hostile/combative stance towards said standard. Basically, it is a case of "if I can't comprehend it, then it's stupid". This is a rather widespread behavioral pattern, a form of "sour grapes syndrome", which we see expressed quite often on the Net. Expressed towards mathematics, towards physics, and now towards language standards, apparently.

or

2. An individual gets so embogged in their own grassroot delusions and misconceptions about the language (and likely for a long time), that when they finally get exposed to the proper fundamental ideas and principles of that language, they assume defensive/hostile/combative stance towards said concepts. They choose to stick to their delusions because it is easier that making an effort to relearn. It is form of a "baby duck syndrome" apparently.

I don't see why the proper formal knowledge of the language should be seen as contradictory to its real-life usage. In fact, such perception usually indicates incompetence. We do use C language in massive real-life projects, yet I've never seen a professional who'd have to perceive the language specification as some sort of impediment in that process. The latter would get laughed off the marked rather quickly.

[PlainName]

Linux kernel v3.4.39 doesn't compile with anything > gcc-v4, and if you look at the reasons ... you find it uses several inner functions that explicitly rely on how gcc-v4 handles some implementation details.

Isn't that an excellent illustration that persuading the compiler writers to ignore the C standard and "do what's right in the real world" just leads to tears later on? If you need particular assembler, write in assembler rather than C.

[Nominal Animal]

Linux kernel v3.4.39 doesn't compile with anything > gcc-v4, and if you look at the reasons ... you find it uses several inner functions that explicitly rely on how gcc-v4 handles some implementation details.

Isn't that an excellent illustration that persuading the compiler writers to ignore the C standard and "do what's right in the real world" just leads to tears later on?

No; it shows you that not everything useful and necessary is captured by the C standard.

Even the GNU C library relies on GCC extensions and GCC-specific behaviour.  Are you too seriously suggesting that instead of talking to the tool developers to see if everyone agrees a specific behaviour is useful, desired, and does not negatively affect other use cases, people should just consult The Oracle Of Correct Behaviour, preferably via a lawyer who gets to redefine all terms to mean what they want them to mean, regardless of their real-world usage?

Sounds pretty damn stupid and inefficient to me.

Development does not occur because the C standard writers invent it.  It grows from the grassroots up.  Features get added, because they are needed and useful.  When enough people agree the features are useful and necessary, it gets codified into the standard.  I'm liking Clang over GCC right now, exactly because they do this, and GCC is once again moving away from this.

Only idiots like Microsoft push stuff through standards first.  How many of you actually use the Microsoft-specific C11 and later Annex K functions (bounds-checking with a _s suffix)? Or their OOXML formats? If you develop only for Windows, and believe no other OS actually matters; sure.  Makes sense then, as your world is limited to that.  None of my systems have those.  Why?  Because users did not ask for those, Microsoft pushed them into the standard by stuffing the committee (well known and documented business tactic of theirs, as they need to stop C diverging from C++ so they can keep claiming their C++ compiler does C too, and at the time they were desperately looking for walls to stop leaking developers from their walled garden).  Using the standard to steer where C is heading for is not working, and will not work, because the users do what users do, not what the C standard says them to do.  And if you wonder why, you are much less smart than I gave you credit for.

Then again, it seems I am among the very small minority who believe programmers, as software engineers, should be as responsible for their work product as e.g. structural engineers are.

[brucehoult]

Then again, it seems I am among the very small minority who believe programmers, as software engineers, should be as responsible for their work product as e.g. structural engineers are.

I also believe that.

I just no longer -- unlike my first couple of decades in the industry -- think bondage&discipline languages are the key to that, or even all that helpful.

The things that do make a difference are creating and using appropriate safe abstractions -- which can be done with structs, functions, and macros -- and test driven development. Garbage collection and appropriate exception handling techniques (*very* different to C++ and Java ones) allow the use of better abstractions.

A good engineer should be able to write perfectly safe code in assembly language.

However, you can do it faster and generate faster code by using an optimising C  compiler. That's because of the automatic management of register allocation, minimising peak register usage in each function (and thus the number saved/restored) by reusing registers, and cleaning up code generated by macro-expansion or function inlining using compile-time evaluation, constant propagation, dead code elimination (including if/then/else with known condition).

A higher level language such as Swift or Lisp can further increase programmer productivity and program performance (from more efficient implementation of high level abstractions), but the additional gains are small and there is a big price to pay in loss of portability compared to C/C++ and lack of support for small or unusual machines.

[Nominal Animal]

A higher level language such as Swift or Lisp can further increase programmer productivity and program performance (from more efficient implementation of high level abstractions)

Yes; and for those learning C, exposing oneself to different languages can help understand abstractions and how abstractions differ between programming languages.

Furthermore, there are situations where a single programming language is not the most efficient approach.  (I often mention I like to write UIs in high-level interpreted languages like Python, because that way the UI is most malleable to end user modification, and I can still keep the heavy computational core in C or C++ or perhaps some other systems programming language.)

There are good reasons why so many games and applications incorporate domain-specific languages (from Lua to Lisp to Python), and it is not just "because it lets us use cheaper developers for the unimportant stuff" –– sometimes it just makes new and worthwhile things possible.  NPC logic is easier if you have abstractions to support behaviour creation, instead of lifting it directly from low-level arithmetic with few abstractions, like you'd do if you do it in C. Recent discussions on design software supporting arithmetic expressions, instead of just numerical constant is one too: you can implement a simple numerical processor, but if you instead embed a scripting language, you suddenly make things parametric and programmable. Of course the key is whether users need these or find them useful or not; a feature nobody uses nor needs is only a plus in the marketing wank.  Seeing the need for another language is very difficult to see unless you have experience using them as an user in similar situations and have found their power first hand, or have some experience in using those different languages to solve different problems can have some grasp at the different abstractions they provide; and you notice your mind telling you "feature X of Y would be nice here".  (Sometimes it is wrong, though; mine is, at least.  It is not an oracle, just bubbles up ideas to test/check/verify.)

I myself use C for freestanding and systems programming.  I can do full graphical UIs (and have used GTK+ for this) in C, but it is not a very good fit; I only do so if I am resource-constrained and higher-level abstractions cannot perform sufficiently well on a given hardware.  Computational power growth in the last couple of decades means even the cheap SBCs have enough memory and CPU power so that just doesn't happen anymore, so I don't.  Using a language just because it is the one you know is not really a sensible way to pick a language, unless you are doing it for learning purposes or fun more than any other long-term reason.  Besides, if you use C++, you can use Qt even on top of a raw framebuffer on an embedded machine.

Quite a lot of high-performance computing (often written in C, or a subset of C++) nowadays embeds CUDA or OpenCL code.  On the graphics side, we have HLSL and GLSL (Direct3D and OpenGL shader programming languages), and so on.  Thus, sometimes an "embedded" or domain-specific language is a compiled, low-level one, too. There are counter-efforts like SYCL, that try to unify these so that a single compiler can handle all in the name of programming productivity, but I'm not convinced: there will always be cases where specialized, purpose-designed tools beat the generic ones, no matter how powerful its abstractions, for the very simple reason that some abstractions are contradictory so a single tool can never hold them all.  I think of the history of PHP as an example why trying to do that – be everything and all things for everybody – backfires.

If someone tells you that language X is the only one you ever need; I suggest you think of it the same way you would if they had told you foodstuff Y is the only one you should ever eat.  Even if they were technically correct, and I don't think they are or ever will be, it'd be rather dull and constricting.

I am following Rust with interest.  The way its "borrow checker" operates when it constructs "pointers" to provide/enforce its safety guarantees, seem similar/compatible to the approaches I've used in C for a couple of decades, and described here and in the other pointer thread.  No, I'm not saying that shows I'm smart; I'm only saying one reason I'm interested is because I can see useful common ground to build on.  I do like the idea of people trying to create something better, to avoid pitfalls found by earlier effort, while reaching for better heights.  But, I haven't an opinion on Rust overall yet, not even on things like adding Linux kernel support for writing (parts of) it in Rust.  Could be good, could be irrelevant, could be bad; I don't know yet.  Only interested.

Comparing to the C standard, well, I just haven't believed the standard writers have C programmers' interests anywhere near the top of their priorities for well over a decade now, because of the things they have concentrated on and pushed forward, and things they have completely failed to try and address, so I am slowly moving on.  For the longest time, POSIX (at the systems programming level, which is what I've done most of) offset/overrode any issues I could have had with the C standard, but now that "almost-POSIX" environments like WSL are cropping up again, it too may be going the way of the Dodo, due to confusion and frustration engendered in the developers.  Reality wins over theory and texts, but if reality becomes unreliable or chaotic, developers tend to move on.  This is not fast, however; I'm talking about one or two decades here, not next year.

None of this should alarm a new programmer.  Their experience will be different to mine; just take note, observe, check/verify, and decide for oneself.

[DiTBho]

people should just consult The Oracle Of Correct Behaviour, preferably via a lawyer who gets to redefine all terms to mean what they want them to mean, regardless of their real-world usage?

That's precisely the attitude I see with theoretical researchers.

Basically their minds do operate trying to grab some good construct from the HyperUranium, but since their minds are limited they cannot physically grab anything, so they operate in the mathematical world where math can be used by their intellect to reconstruct a an imperfect copy (but hey? better than nothing) of what partially seen in HyperUranium,  ... that's their daily job, knowing it will be up to someone else to push their math models into  in the miserable prosaic of the world

Code: [Select]

HyperUranium ---> mathematical world ---> miserable prosaic of the world
(Plato's vision)

HyperUranium is a true concept of Plato expressed in the flesh. According to Plato the Hyperuranium the world beyond the celestial vault that has always existed in which there are immutable and perfect ideas, reachable only by the intellect, which is not tangible by the earthly bodies and corruptible.

It is an evergreen vision as old as the Greek philosophy of the aforementioned Oracle.

Speaking of this, the modern view is ... only after the singularity will there be an AI capable of penetrating the HyperUranium ... which leads to the question ... if the AI was created by humans, and the human being is imperfect, how can a creature be superior to the creator? ... you see this question in movie like Alien Prometheus , when David asks some questions to Young Peter Weyland, and he replies him to serve a cup of tea.

[peter-h]

I think the problem is that everybody here is a C expert, while those who are not aren't posting I run a "tech" forum (not electronics) so I am well familiar with the psychology.

Most people I know who do C spent some time writing crap, because they didn't do a formal course.

And if you go back far enough, programming teaching was crap anyway. At univ, 1975-78, the 8080/6800/Z80 already existed, but were they teaching them? No. We did Pascal! An almost totally useless language for embedded work (IAR did a sort of usable Pascal compiler, for about 1000 quid, IIRC) due to its ridiculously strict typing. It survived in Delphi for many years though. And I even developed a user programmable protocol converter c. 1990 which had a Pascal compiler (from HiSoft - another long gone company) built-in, along with a Wordstar compatible editor

Most C coders learnt the hard way, and a lot of crap got written.

My exposure to C is occassional so I will never get really current in it, so I use it as a "simple language" and that way I avoid getting subtle bugs.

One of the issues with pointer arithmetic (rather than operating on an explicit array index, and bounds-limiting it) is that bugs are more likely to remain hidden because the program can appear to work but is actually crapping over some memory which you just happen to not be using at that moment. That was always a risk in assembler, of course (I wrote literally megabytes of that) but one was naturally more careful with that.

I also think asm background is useful for C because you tend to know where the skeletons are likely to be buried

[brucehoult]

And if you go back far enough, programming teaching was crap anyway. At univ, 1975-78, the 8080/6800/Z80 already existed, but were they teaching them? No. We did Pascal!

What did you use Pascal *on* in 1975-78? It would pretty much have had to be on a CDC 6000 or ICL 1900, and in the UK, I'd think. Or Switzerland, obviously.

UCSD Pascal started widespread use of Pascal, but wasn't available until late 1977 and probably not widely at first -- it became very popular on the Apple ][ starting in late 1979.


The university I went to was teaching FORTRAN to 1st year students until 1980. In 1981 (the year I started) we got Pascal on a PDP 11/34. At first we were using a compiler from the US NBS (National Bureau of Standards). It was rather buggy. Halfway through the year we switched to OMSI Pascal.

We learned assembly language programming and interfacing to hardware in 1982 using Rockwell AIM65 (6502) boards, though I taught myself PDP-11 assembly language/machine code the year before.

An almost totally useless language for embedded work due to its ridiculously strict typing.

Perhaps in the official standard.

I've never used a Pascal compiler that didn't have extensions making it effectively a different syntax for C and just fine for low level programming, if a bit more verbose. That includes Apple (UCSD) Pascal, OMSI Pascal (it had octal constants, bitwise operations, direct access to memory, inline assembly language), VAX Pascal, Turbo Pascal, THINK Pascal, MPW Pascal.

[PlainName]

I also think asm background is useful for C because you tend to know where the skeletons are likely to be buried

I agree with pretty much all of your post, but this bit I think is quite important in a non-obvious way and applicable not just to programming. One doesn't need to be an expert in the lower (and higher) levels, but a working familiarity smooths things along.

[brucehoult]

I also think asm background is useful for C because you tend to know where the skeletons are likely to be buried

I agree with pretty much all of your post, but this bit I think is quite important in a non-obvious way and applicable not just to programming. One doesn't need to be an expert in the lower (and higher) levels, but a working familiarity smooths things along.

Absolutely.

I always recommend that people should start by learning an assembly language before high level languages.

Just not x86.

[peter-h]

Pascal and Fortran were on ICL1900S, punched cards But in 1978 we got teletypes and you could feed in paper tape!

The unfortunate thing about the crappy univ course ("Electronics and Applied Sciences", Sussex Univ) was that IF you could program a micro anytime in the 1975-1985 timeframe, you could print your own money. We were paying £500/DAY to somebody, early 80s, writing a token ring LAN around a WD2840, for months, before I decided to abandon throwing money at him and did it all myself with a Z180+85C30 (SDLC, MILSTD1553 physical). People I knew who were good at embedded devt and working as product devt consultants were driving Ferraris (back when a Ferrari cost real money), but they had to be good at digital hw and sw and analog, which was always rare, and is even more rare today.

80x86 asm is horrible.

I don't think many used Pascal for actual products. It was all done in asm and/or C. I didn't touch C until 1994.

I still don't really get subtle pointer stuff I find it is like the devt tools. You need a not of currency to get good and stay good. I struggle with the POS called ST Cube IDE, and the crappy libraries where somebody was paid €10/line and put in error traps even in places where the code cannot possibly fail. I don't think any of this has got better. The silicon does a lot more; that's all. The software is as crap as ever.

[SiliconWizard]

Even at the time when C was still officially taught at universities as a major programming language, courses were already kind of crap IMO. I'm not as old as some others here I guess, but at uni, Pascal, was still the main language taught for introductory courses at the time. That was in the early 90s. (But I had already learned it in high school on CP/M machines.) I think courses were much better than anything I've seen with C. Which is not surprising; Pascal was designed from the ground up for teaching purposes; C definitely wasn't.

Apart from the particular merits and characteristics of C, one point explaining this IMO is a matter of chronology. C wasn't standardized before 1989, and frankly, original C was not all that good for teaching, especially for teaching good programming practice. In the 90's and even 2000's, most teachers were still knowing C from original C. So C was a moving target and there was some confusion between original C and ANSI C. Then things moved on and universities switched to other languages, so time was up for teaching C. After that, C was mainly taught as a tool for  EE students, not in proper programming language courses. So the situation is not surprising.

And, Pascal was still actually used in products in the 80s and 90s. Heck, it's still used today in the form of Delphi and derivatives. Although a small market, it's definitely alive.

[Siwastaja]

C is problematic for teaching because C doesn't have a clear scope which it tries to solve. It's kind of universal tool and the official specifications are not touching all practical aspects.

C was originally conceived as a high-level language to create applications (something like what we run on our desktop computers, or which run on servers), definitely not for what's now called "embedded", especially microcontroller. But nowadays, C has primarily become de facto embedded language, despite not being most optimal for that purpose.

In reality, C isn't optimal for anything. But it's good enough; or surprisingly good for many different uses which explains its popularity; but also explains why it's difficult to teach, because teachers want a clear, easily specified goal, not a messy bazaar where anything goes but you get what you needed. Instead, universities like cathedrals such as UML diagram specified over 5 years and then implementation written in C++ or Java over the next 5 years, after which is obvious to everyone the resulting software does not work and no part of it can be practically reused because everything is built on the top of the object hierarchy.

Being able to efficiently use C in real world projects (where the aim is not sadomasochism, but getting the job actually done) also requires to understand that the standard is not the Holy Bible. This is unsuitable in the mental model of university teachers.

[peter-h]

The main "problem" with C, but also what makes it so powerful for embedded work, is that you need a clear understanding of what it is doing underneath i.e. the machine, addressing, word sizes, etc. It is thus like assembler but a lot more productive.

If one doesn't understand the hardware in great detail, one just writes something like ch=getc(), not realising this is a blocking function and will hang for ever if it is a serial port and nothing comes in. That's probably why you can't teach C generally; anybody who can use it well could code the job in assembler, given enough time.

[SiliconWizard]

C is problematic for teaching because C doesn't have a clear scope which it tries to solve. It's kind of universal tool and the official specifications are not touching all practical aspects.

Yes and no. I only partly agree with this. As a general-purpose language, of course it doesn't have a clear scope. Isn't that what general-purpose is all about? That can be said about many other programming languages.

As I said, I personally think that the best languages for teaching programming are those that are specifically designed for this task. In CS teaching history, if you think about it, the languages that were most successful for teaching all were designed in universities, often by professors and their teams. OTOH, those languages were often not quite fit for "industrial use", so to speak. Conversely, languages designed in industrial settings have been a better fit for real-world use, but poorer for teaching. Yes, even Java - I'm not very fond of it, and I'm not too convinced it's all that good for teaching. Sure there are worse alternatives out there. Python is definitely one IMO.

C was originally conceived as a high-level language to create applications (something like what we run on our desktop computers, or which run on servers), definitely not for what's now called "embedded", especially microcontroller. But nowadays, C has primarily become de facto embedded language, despite not being most optimal for that purpose.

I'm not sure I completely agree with this. It was clearly designed to be low-level enough for implementing low-level parts of an OS, and at the same time be high-level enough to be fit for writing complex applications. It addressed both right from its conception. You can argue that it ended up not being particularly good for either, but it's simple enough and it "works".

Being able to efficiently use C in real world projects (where the aim is not sadomasochism, but getting the job actually done) also requires to understand that the standard is not the Holy Bible. This is unsuitable in the mental model of university teachers.

I'm not sure what you mean exactly. The standard is, IMHO, actually one of C's strong points. Of course reading it is clearly not enough for using C right and efficiently, but IMHO it doesn't hinder much either. As is often discussed here, not following the standard should be usually done with a lot of caution, sparingly and should be the exception. I'd much rather have young engineers taught perfectly standard C properly, and then teach them some possible deviations and compiler extensions in the field, than engineers taught weird non-compliant stuff that are likely to get them more confused than anything and later on have to teach them the standard to get back on track, which unfortunately is the most common option I've seen, by far.

Now again there certainly are languages that are much better for both teaching and everyday development. C is popular though because in the end it seems to have made the "right" compromises for real-world use and wide acceptance.

[hamster_nz]

The main "problem" with C, but also what makes it so powerful for embedded work, is that you need a clear understanding of what it is doing underneath i.e. the machine, addressing, word sizes, etc. It is thus like assembler but a lot more productive.

The main "problem" with C is that the C programmer has two key skills:

- Solve the programming problem that they have at hand.

- Keep the execution environment health (i.e. keep track of resources, be sure to only address things that you should, avoid undefined behavior, detect and handle errors appropriately)

Most learning resources seem to think that the second skill is not required, or can be treated as "on the job" learning. Heck, even the man pages for "fopen()" don't advise you that you should call "fclose()". But keeping the execution environment health is the most important thing.

For example the 'man' page for fopen() should explicitly state "all valid file pointers returned from fopen() should be be closed by calling fclose() then the file is no longer needed."

Have a look at https://www.geeksforgeeks.org/c-fopen-function-with-examples/ - sure it uses fclose() in the example, but no motion of why it is vital to close files. FWIW it doesn't even detect if fopen() fails either.

Here's code from http://faculty.winthrop.edu/dannellys/csci325/02_c_IO.htm - which I assume is part of "CSCI 325 - File Structures (3).":

Code: [Select]

/**********************************************
Demo Three - Use C to copy file1 to file2
*********************************************/
#include <stdlib.h>
#include <stdio.h>

/******************************************************/

int main ()
{
   FILE *infile, *outfile;
   char string[20];

   /***** open input and output files *****/
   infile = fopen ("file1", "r");
   if (infile == NULL)
     {
      fprintf(stderr, "Error opening input file\n\n");
      exit (1);
     }
   outfile = fopen ("file2", "w");
   if (outfile == NULL)
     {
      fprintf(stderr, "Error opening output file\n\n");
      exit (1);
     }

   /***** copy everything  ****/
   while (!feof(infile))
     {
      fscanf  (infile,  "%s", string);
      fprintf (outfile, "%s ", string);
     }
}

When people are learning with these piles of crap, is it any surprise we get such bad results?

[brucehoult]

As I said, I personally think that the best languages for teaching programming are those that are specifically designed for this task. In CS teaching history, if you think about it, the languages that were most successful for teaching all were designed in universities, often by professors and their teams. OTOH, those languages were often not quite fit for "industrial use", so to speak. Conversely, languages designed in industrial settings have been a better fit for real-world use, but poorer for teaching. Yes, even Java - I'm not very fond of it, and I'm not too convinced it's all that good for teaching. Sure there are worse alternatives out there. Python is definitely one IMO.

Python has the very great advantage over Java of being able to write a simple program e.g. HelloWorld in a single line of code, without ten lines of boilerplate code that that won't be and can't be explained until you know much more about the language. C is worse than Python in that, but a lot better than Java.

I have three major beefs with Python:

- I will never accept significant whitespace.

- having no type declarations at all is bad. Even if you have dynamic typing -- i.e. you can accept objects of different types -- it's good to be able to declare what messages you will be sending to the objects and expect them to be able to respond to. It's documentation of intent for yourself, later. Or others, of course.

- the language is not orthogonal. Scheme has all the same advantages as Python (except popularity), but you can combine Scheme features in arbitrary ways and it works. Dylan and Julia have the advantages of Scheme, but with optional type annotations.


My attributes for a good language to learn programming:

1) trivial programs are small

2) it's easy to learn essentially all of the language, so you spend your time learning to program, not learning the language.

3) it's easy to form a correct mental model of what is happening when the program runs

4) it's easy to know what you CAN'T write. If something seems to make syntactic sense then it should be permitted and make semantic sense.

5) a good facility for abstraction, so you can create features that could have been built into the language, but weren't

6) when you create new abstractions they look but especially PERFORM as if they had been built into the language.

Obviously there are other desirable characteristics of the programming environment, but I'm concentrating on the language here.

[peter-h]

I was never a fan of "teaching languages" because you basically leave university having learnt little that's actually useful anyway, and not learning useful "computing stuff" makes it even worse.

I designed a function generator which drove a 256 byte fusible link PROM from an 8-bit sync counter and fed its output into an 8-bit DAC (state of the art stuff in 1978!) and I needed to generate the binary data to program into the PROM (setting up every byte with toggle switches on the programmer!). So, to generate a sinewave, I wanted a program which would print out sin(x), with x going 0-255 representing 0-360deg, and the value going 0-255. In Pascal. Impossible! Nobody knew how to write it. I did it in Fortran...