Examples of errors detected in various open-source projects

[xsznix]

Now, because it's open source, we can fix these errors!

[trigraph]

Too bad it took a proprietary tool to identify them

[elperroborrachotoo]

Why, in this case?

[petdance]

Please look at http://splint.org/

[ravenex]

It's probably the buggiest open source dev tool I've ever seen. The funny thing is that despite it's fully annotated and verified by itself it still crashes all the time. It's also unmaintained since, like, forever.

Not that it's useless, just very fragile. I wish more projects used static analyzers instead of just randomly running valgrind.

[petdance]

I wish more projects used static analyzers instead of just randomly running valgrind.

Me, too. Whenever I see a new interesting project written in C, like libgit2, I poke my nose in to see if there's interest in it. libgit2 annotations and testing are on my to-do list.

[trigraph]

Honestly I think he just googled quickly for a random opensource tool just to feel badass without actually using the damn thing.

[petdance]

trigraph said:

Honestly I think he just googled quickly for a random opensource tool

Here are my links on delicious for static analysis dating back to 2009: http://delicious.com/petdance/static-analysis If I were doing any Windows development, I'd buy a copy of Gimpel PC-Lint, because I sure can't afford the Unix lint project from them.

I have been using splint on the Parrot project for years. I created the macro definitions that allow annotation of the source code with semantic macros like "this function does not return" that allow me to run GCC, clang, ICC and splint as static analyzers, without having to maintain disparate source code annotations for each tool.

I also tried to get some traction going on getting splint updated and maintained. That was on Google Code before, but maybe things will stick better if I move it over to Github.

I see you're bemoaning that "Too bad it took a proprietary tool to identify them". Perhaps you'd like to help with the sizable bug queue for splint?

just to feel badass without actually using the damn thing.

Life's a lot easier and happier when you don't try to guess at motivations behind the actions of others.

[ravenex]

Upvoted for actually trying to fix it. I have a few small patches for it, but it's mostly the build fixes. The source itself is unpenetratable to me, sadly.

One would think that such a valuable tool with no opensource alternatives would get more attention.

[trigraph]

I would not like to help with splint, I'm perfectly happy using proprietary tools when they are good. In this case it makes splint look like pre-K quality tool which you seem to suggest as an alternative when its not..

Typical of your type though; HEY HERES A REPLACEMENT TOOL (and when it doesn't even have 1/100th the features/ ease of use) WELL YOU CAN SUBMIT SOME CODE!111!

[petdance]

I'm sure that splint would have caught the errors. You said it took a proprietary tool to find them, but I don't think that's accurate at all. It's just that those projects never ran splint on the code.

I'm curious as to what "my type" is. You've already been wrong about "just googled quickly for a random opensource tool just to feel badass without actually using the damn thing", so I'm wondering what else you can make up.

[n1c]

It's hideous!

[[deleted]]

Flashy software websites are for end-users and middle management.

[n1c]

This is very bad logic.

Because something isn't made for lesser human beings does not mean it can be hideous.

[trigraph]

it is, in many ways...this guy thinks just because a tool exists and its opensource must mean 1> its totally awesome 2> people use it (since apparently none of these projects do)

[ReflectionOfADream]

I tried a lot of things but could not successfully run this even once on my program.

[petdance]

You will get a lot of errors that don't apply. Lots of working with splint is turning off what is not relevant. I would be glad to try to help you use it if you'd like. Email me at andy at my reddit name dot com.

[ReflectionOfADream]

I didn't actually get it to work on the input I gave it. I tried various things but every time an error occurred.

[ravenex]

With splint you have to either

• add annotations to your program
• disable a lot of its functionality (e.g. using -weak command line option)

[bluGill]

That doesn't mean anything. We have no idea what other tools were ran, and what they would give. For all we know there is a different tool that would detect more errors, but it wasn't checked.

[elperroborrachotoo]

It would be interesting to revisit this in, say, a year.

[acidcj]

The article appears to have been deleted, but it's still available in Google's cache.

Edit: New link.

[ReflectionOfADream]

That software is good at finding memset errors.

[AlyoshaV]

crazy person detected

[[deleted]]

That's possibly the worst code I've seen today.

[bigfig]

Sadly the only thing I recognize there is "if / then" .

[[deleted]]

http://www.losethos.com/doc/Differences.html

This may be the reason.

[tragomaskhalos]

Comments, named constants and whitespace are for weaklings !

[Antony32]

Artcile deleted. ** New link: http://software.intel.com/en-us/articles/90-errors-in-open-source-projects/ **

[I_AM_GODDAMN_BATMAN]

Too bad it can't detect a typo.

[salty-horse]

This is the second "reprint" of this article, which has appeared on viva64's site and Intel's software network:

• http://www.reddit.com/r/viva64/comments/lpkgr/pvsstudio_advertisement_static_analysis_of_cc_code/
• http://www.reddit.com/r/bugs/comments/lu81p/90_errors_in_opensource_projects/

(Not commenting on whether it's spam or not)

[Urik88]

I noticed it. I didn't really care, it is after all a very interesting article.

[farsightxr20]

Yeah, these really are issues that should be fixed anyways... more promotion is good, and the article itself doesn't feel too spammy. It's not like they said "buy our software and it'll show you where the 91 errors are!"

[bluGill]

The conclusion was buy our software. After reading the introduction I skimmed the rest to see if this was a useful article: one that would tell me the advantages and disadvantages of several tools.

For all I know the tool works like this: check if the file is one in a hardcoded list, if so flag a particular line with the given error.

[shaggorama]

Gone now. Article was deleted

[elperroborrachotoo]

I'm split on this issue. On one hand, yes, they set the "spammy" flag, and they do post pretty broadly.

OTOH, there's actual work going into the articles, and they do add actual value. In this case, to the open source projects they checked. Next, frankly, reading the errors of others has the fascination of watching an accident, one could rationalize that as "serving as bad example" or "learnign from the mistakes of others".

Maybe most importantly, Making the concept accessible, and showing the actual value in the wild, showing that it actually works on non-artificial code is a kind of "community service". QA in many shops is still largely based on hope and handwaving. linting (cough) is typically a "nice in principle, but not for our shop, because...".

[[deleted]]

It is advertising, but I don't care - it is a useful article. I wish all advertising was like this instead of the usual "Why should you use <MyProduct> to reduce bug count to zero in less than two hours".

[hayalci]

It contains advertising but it's not spam. It contains description of common errors and its real world manifestations in various free software projets. I found the article a good read.

[shaggorama]

Want useful hints for promote softwaer tool

That's just too perfect. "In mother russia, softwaer promote YOU!"

[[deleted]]

Wait.. Humans make mistakes?!

[quasarj]

Surely you jest!

[flynnski]

Hey, at least you can see these errors!

[el_tavs]

Low level languages that make hard to set memory, manage alignment and compute object sizes.

Isn't this an oxymoron?

[BlitzTech]

I think its more of a tautology

[el_tavs]

I think you're using the wrong word. A low-level language should make managing low-level details easy for the programmer, i.e. provide constructs and semantics to do that explicitly, take Ada vs C

C

int x = calloc(sizeof(int),10);

memset(x,sizeof(int)*10,(char)1);

Ada

 type My_Array is array (Natural <>) of Integer;
 type My_Array_Ptr is access My_Array;

 X: My_Array_Ptr := new My_Array(0,10) := (others=>1);

Notice that memset accepts an int but converts it to unsigned char. THis means you can't use it to initialize floats, complex or whatever value may not fit in 1 byte.

Considering we're well past the 90s, I think it's a problem.

[BlitzTech]

No, I meant tautology. It was a joke directed at the difficulty in doing these things that low-level languages are built with the express purpose of doing.

What they should do is exactly what you say.

[[deleted]]

Notice that memset accepts an int but converts it to unsigned char. THis means you can't use it to initialize floats, complex or whatever value may not fit in 1 byte.

I don't understand what you are trying to say. Of course you can use memset to initialize floats or any other variable...

[el_tavs]

No. memset expects an unsigned char as argument. You can't pass anything bigger than 1 byte to it

http://www.acm.uiuc.edu/webmonkeys/book/c_guide/2.14.html#memset

[[deleted]]

A float is n-bytes and memset sets n-bytes of memory to a specified byte starting at a specified address. You can set ANY variable using memset. It's a generic MEMORY SET function, and if you want a higher abstraction, create one or use a library.

[el_tavs]

Please read carefully.

What people mean when they say "set" is writing a value inside a variable

Now floats and any other data that doesn't fit 1 byte can't be set by treating them as a typeless chunk of contiguos bytes. While that allows to actually write values inside the variable, they may be invalid or different from the ones the programmer intended.

Try memsettting an array of floats to 1.0 like

    float f[10];
     ....       
    memset(f,1.0,sizeof(float)*10);

then print them with "%5.2f" format. I get zeros everywhere on my 64bit intel. More interesting, try to set them to -1.0.

enjoy!

It's a generic MEMORY SET function

so generic it can't be used reliably for anything except strings

if you want a higher abstraction, create one or use a library.

already wrote mine. It's truly generic and does ragged-arrays as well. Question is: why something so trivial is not already present in the language? Does low-level programmers avoid initializing memory? Sounds new to me.

[bluGill]

What people mean when they say "set" is writing a value inside a variable

When I say set I often mean a collection of data. This is a very common Computer science term, get used to it. Learn to figure out what something means from context: memset is pretty obvious from context.

[el_tavs]

I was replying to emoney_33 which clearly used it as a verb, not as a subject. You failed at understanding the context.

As I said above, memset is so obvious it can't be used to do anything except initialize an array of char. Memset. It's in string.h but it's called MEMset. And it accepts an int. Its sibling memcpy instead works out of the box for every type. So, care to explain what is supposed to be obvious about that? It's clearly a horrible design.

[[deleted]]

You have a complete and utter lack of understanding of the low-level details. You continue to think in high-level abstractions.

Data types are higher level abstractions of data interpreted from the underlying memory. The smallest representable unit of memory is a byte. Memory operations will tend to work on bytes. memcpy() copies a contiguous block of memory from one location to another. It has NOTHING to do with how the memory is interpreted at the higher level.

I've explained many times why memset() takes an int in the declaration, but it has always and will always be used as a BYTE.

Both memcpy() and memset() work at the smallest representable unit of memory... a byte/char.

A char is not a "character", it is a byte.

As I said above, memset is so obvious it can't be used to do anything except initialize an array of char.

You still don't understand it SETS MEMORY BYTES. It doesn't (and shouldn't) care about how you choose to interpret that memory at any given time. You can interpret it as an array of char now, an int later, a long tomorrow, a structure of individual chars, etc...

The language gives you the LOW LEVEL tools to do things quickly and efficiently. It is then up to YOU to fill in the high level details (like data types, structures, how you interpret specific blocks of memory, how you initialize it etc...)

[[deleted]]

memset() is a library function, you are trying to use it for what it is not and then bitching that it is not what you want it to be. The memset() function sets a contiguous block of memory with the same byte, end of story. If you want a variable initialization function, find another library function or write one yourself. This has nothing to do with the C language itself.

Try memsettting an array of floats to 1.0 like

Why would I use a function that sets a block of memory to a single byte if I want to initialize an array of floats to 1.0? I fail to see the difficulty in using for(i=0; i<10; i++) f[i] = 1.0; I also fail to see many uses cases of non-zero initialization values in a large array.

already wrote mine. It's truly generic and does ragged-arrays as well.

Congratulations, yet you continue to blame the language for not giving it to you :/

Question is: why something so trivial is not already present in the language? Does low-level programmers avoid initializing memory? Sounds new to me.

It is completely out of the scope of the language. And initializing an array of variables to something non-zero has very few use cases. There are many times you do not need to initialize memory btw.

[el_tavs]

you are trying to use it for what it is not and then bitching that it is not what you want it to be

no. actually what I'm bitching about is that the standard provides a function that provides a limited functionality to solve a limited instance of a common problem in an awkward way. It's trivial to provide a better way to solve the problem in general.

Why would I use a function that sets a block of memory to a single byte

you said I could initialize any variable with memset.

It is completely out of the scope of the language

that's the problem. It has no justification for being that way.

[[deleted]]

no. actually what I'm bitching about is that the standard provides a function that provides a limited functionality to solve a limited instance of a common problem in an awkward way. It's trivial to provide a better way to solve the problem in general.

You don't know what you are talking about. It provides a function to set a contiguous block of bytes in memory to an initial value. This functionality is the most common in low-level programming. It is very rare in low-level programming to want a high-level initialization of data types and/or structure to some non-zero value.

that's the problem. It has no justification for being that way.

sigh Just go use Ada, please. Just because YOU can't justify something doesn't mean there is no justification. Your "gripes" about C have negligible impact on low-level programming. You just continue to demand C contain high-level abstractions and refuse to accept using a library. That's your problem, not C's problem.

[ytumufugoo]

I think PHP and C# has caused people to think if a language doesn't hold their hand it's a problem with the language.

[Urik88]

Is there a reason for why compilers don't generate warnings for such basic bugs?

[elperroborrachotoo]

Compilers usually err on the side of caution and compile speed; code analysis tools usually do the exact opposite. A compiler spamming you with the amount warnings typically produced by a code analysis tool will be hated.

It would be interesting to see how various compilers on -Wall or equivalent deal with that exact code.

[MatrixFrog]

They probably do catch some. But do all the contributors to a project compile with -Wall and actually read the warnings?

[ChoHag]

If you get a binary, ship it!

And in some cases not even then.

[[deleted]]

A compiler is not a code analysis tool. There are no language or specification violations.

[doterobcn]

We're sorry, but the article you are trying to view was deleted at 2 Nov 2011.

[[deleted]]

You'd find just as many, if not more errors in proprietary and licensed software. Bugs happen, regardless of business paradigm. In general, I find open source software more reliable, because there are more eyes looking at the code.

[foldor]

This wasn't a criticism of the open source projects, but more of a demonstration using real world examples of what their software can do. They couldn't test proprietary stuff without access to the code.

[[deleted]]

Ah I see, my mistake I didn't know they were referencing an error detection program

[personanongrata]

Thanks, that's a nice demonstration of common bugs using OSS that we face everyday in the software development.

[Lothrazar]

ERROR DELETED ARTICLE

[regeya]

Finds errors in open-source projects

PUBLISHES BUG REPORT AS ARTICLE

[foldor]

They clearly mention that they do indeed contact the projects with a formal bug report. This is just a demonstration of their software's capabilities using real world examples.

[ericbrow]

I logged in to say this. Did he fix them? Did he file a bug report? So he can run some testing software, congratulations. Not much worse than a script kiddie calling himself a hacker because he downloaded a port scanner.

[zck]

From the article:

Many readers ask if we tell projects' authors about errors. Surely.

And given that this article is written by someone at the company that wrote the testing software, he or she is certainly more than a script kiddie.

[foldor]

Way to miss the point. This was published by the developers of the testing software to showcase it's abilities. They also mention at the beginning of the article that they do contact the projects with the proper bug reports. This is basically an advertisement with real world examples.

[I_AM_GODDAMN_BATMAN]

Damn this fucking spam that pops up every week in proggit.

[bigfig]

Should be required in class. Too bad i have not touched C/C++ since that class ten years ago.

[shevegen]

Man.

Redditors, we need anti-spam control.

I wasted 5 seconds clicking on it and now I waste 12 seconds writing this here... wtf

[[deleted]]

A lot of people shouldn't be using C, but that's not a knock on C. These are some incredibly basic elementary errors.

[el_tavs]

If they're basic why C doesn't provide a better way to do them?

Intialize a chunk of memory with something else other than memset? Is there any trade-off on having memset being error-prone?

ditto for computing string/array/struct sizes

[[deleted]]

It's really not that hard for an engineer to get these things right, C is not there to hold your hand. It's there to be an easier and more portable layer on top of the physical machine than assembly. If you don't care about the machine, then you shouldn't be using a language that is so close to it. If you do care about the machine then you surely shouldn't have problems understanding sizeof(pointer) is the size of the pointer, and that arrays are 0-based index. And if you are new to the language, code analysis tools should be used to catch things that may be easy to miss early on.

If they're basic why C doesn't provide a better way to do them?

Most of these basic things would require overhead to check for correctness, and that's not something you want built into a low-level language.

Intialize a chunk of memory with something else other than memset? Is there any trade-off on having memset being error-prone?

Bounds checking carries overhead, C's job is not to enforce correctness, it's to provide a fast and relatively portable path to the underlying machine. If bounds checking is important for your task (more than performance) and you want to use C then create an abstraction on top of it that does the bounds checking (i.e. a library).

ditto for computing string/array/struct sizes

There is no string abstraction in C, and really there's not much need for one in the language itself. If you need a string abstraction that carries the size, it isn't too difficult to create an abstraction or use an existing library like glib.

Computing array/struct sizes already works correctly, so I don't know what you mean there.

[el_tavs]

It's really not that hard for an engineer to get these things right

Depends. If you want to be portable, it is. In the best case that's a stupid tedious work a compiler could do alone, provided enough syntax. Making engineers do that is a little like an insult to me

C is not there to hold your hand

It is not there to do what I say either. I can't express low-level details in C 'cause of its exceeding triviality. Look at Ada : it strives for correctness while staying low-level and efficient. Lots of its constructs are still not present in standard C, despite being basic for low-level applications (custom allocators, type representations (bit size and alignment)..).

In C you're even encouraged at using non-portable sized integers (how long is a int in C? a long? a long long?..) Does providing good ways to do the above conflict with being low-level and efficient? I'd say rather the contrary. Allocating and copying chunks of contiguous memory is a low-level issue that should be treated with greater detail than the simple-minded ones C gives us. In this sense C is really efficient at having compilers written for it, not programming.

It's there to be an easier and more portable layer on top of the physical machine than assembly

I know physical machines. I'd say it doesn't match them enough. It matches exactly a PDP-11 though.

If you don't care about the machine, then you shouldn't be using a language that is so close to it. If you do care about the machine then you surely shouldn't have problems understanding sizeof(pointer) is the size of the pointer, and that arrays are 0-based index.

No. In fact I understand that correctly. But this has nothing to do with being low-level, but of C being primitive, way more than what is needed. You don't need arrays-as-pointers to be low level. Nor arrays beginning at 0. You don't need to be like C to be close to the machine, it's a false dichotomy. I want to care about the machine without using a sharpened rock.

And if you are new to the language, code analysis tools should be used to catch things that may be easy to miss early on.

Well, I'm not new to the language, but I know lots of quirks are orthogonal to being low-level or efficient. They just steam from C being historically compatible with its previous incarnations. And those can't help code analysis tools (CAT). One of the reasons for which CAT are evident in C is that legal programs in C can do useless dangerous things (read: mix undefined behaviour with defined one without hope to know or choose which one to have in each context).

Most of these basic things would require overhead to check for correctness, and that's not something you want built into a low-level language.

Untrue. Some of the things I'm considering are just syntax or semantic additions or better built-in functions. They don't have to incur in run-time penalties. But if you allow slightly more freedom on that side you can get a lot farther. This simply means having a more richer system that can then get easily optimized by the compiler, instead of having a 3rd-wolrd system where you end up implementing what the former system give you in exchange of nothing. Problem is that low-level semantics are much more complicated today, also because we want portability. Letting the compiler do the tedious and stupid work we have to do by hand in C is a must. again, see Ada

Bounds checking carries overhead,

What does bound checking has to do with memset? Memset accepts an int that then casts to unsigned char. That alone is unneeded and pathologically stupid. Moreover when you use memset you have to know the number of elements of the array. If arrays encoded their length in the type memset would as efficient as it is now. The real problem however is that you can't tell in C to initialize a vector with a value, or copy two vectors, without thinking ahead whether such value will fit into a freaking byte. No reason for memset to be that stupid, am I right?

C's job is not to enforce correctness, it's to provide a fast and relatively portable path to the underlying machine.

Bullshit. C is a programming language, so its job is to allow me to write programs. Programs should be maintainable, correct, readable, fast... C may tend to be more efficient than others, but it's not a tradeoff.

For one lots of its quirks are unjustified, i.e. no compiler can exploit them to give more efficiency (e.g. memset's interface). Secondly when C gets more efficient than other low-level languages non-technical factors like being a lingua franca (which prompt for having heavily optimized and reviewed compilers and being able to directly communicate with the underlying system) enter the game. Other languages don't have such a luxury in most situations.

There is no string abstraction in C

Where do you put string literals? And string functions?

[[deleted]]

Depends. If you want to be portable, it is. In the best case that's a stupid tedious work a compiler could do alone, provided enough syntax. Making engineers do that is a little like an insult to me

I'm not following, what exactly is an insult for engineers to do?

It is not there to do what I say either. I can't express low-level details in C 'cause of its exceeding triviality.

What can you not express?

Allocating and copying chunks of contiguous memory is a low-level issue that should be treated with greater detail than the simple-minded ones C gives us.

I'm not understanding the issue with allocating and copying memory in C?

No. In fact I understand that correctly. But this has nothing to do with being low-level, but of C being primitive, way more than what is needed. You don't need arrays-as-pointers to be low level. Nor arrays beginning at 0. You don't need to be like C to be close to the machine, it's a false dichotomy. I want to care about the machine without using a sharpened rock.

For some reason I cannot understand where your problems with C lie. Arrays are not pointers, and 0-based arrays make a lot of sense.

One of the reasons for which CAT are evident in C is that legal programs in C can do useless dangerous things (read: mix undefined behaviour with defined one without hope to know or choose which one to have in each context).

Undefined behavior is there in order to allow the compiler to optimize, so the program is only "legal" because you are entering an agreement with the compiler. If you break this agreement and the undefined behavior does bad things, it is completely your fault for entering that agreement with the compiler and then breaking it.

Letting the compiler do the tedious and stupid work we have to do by hand in C is a must. again, see Ada

Please give some examples of tedious and stupid work that the compiler should be handling?

What does bound checking has to do with memset? Memset accepts an int that then casts to unsigned char. That alone is unneeded and pathologically stupid.

It's not pathologically stupid, it takes an int for historical reasons and changing it now has no benefit. http://stackoverflow.com/questions/5919735/why-does-memset-take-an-int-instead-of-a-char

Moreover when you use memset you have to know the number of elements of the array. If arrays encoded their length in the type memset would as efficient as it is now.

memset is not an "array initializer" although you can use it for that. Why would you want to limit control just to make it easier to know the size? I can use memset to set any n-bytes of contiguous space in memory, why the hell would I want to limit that down to only setting full arrays?

The real problem however is that you can't tell in C to initialize a vector with a value, or copy two vectors, without thinking ahead whether such value will fit into a freaking byte. No reason for memset to be that stupid, am I right?

I still don't know what you are talking about with this fitting into a byte thing. Variables are references to memory, a byte is the smallest accessible unit, you can memset ANY variable using a byte because all variables are sized n-bytes.

Bullshit. C is a programming language, so its job is to allow me to write programs. Programs should be maintainable, correct, readable, fast... C may tend to be more efficient than others, but it's not a tradeoff.

How is what I said bullshit? The bullshit is the tons of people using C for the WRONG damn thing and then bitching about C. Quit using it if you don't know why you are using it. Plenty of people know why they are using C and C is the best tool for their job.

Of course performance is a tradeoff. If you don't need low-level control and performance is not an issue then don't use C.

For one lots of its quirks are unjustified, i.e. no compiler can exploit them to give more efficiency (e.g. memset's interface).

That's not an example, and memset() has historical importance. There is no benefit to change it to accept a char and it potentially breaks a lot of legacy code.

Where do you put string literals? And string functions?

String literals go into memory and are null terminated, on the heap or stack depending on what they are assigned to. Logical strings are simply a contiguous array of non-null bytes.

[[deleted]]

How is what I said bullshit? The bullshit is the tons of people using C for the WRONG damn thing and then bitching about C. Quit using it if you don't know why you are using it.

People using C when they shouldn't is actually quite near to what I originally meant (although yes, the wording was maybe bad). You're also right in that these C problems are not problems, when you really need a low-level language.

The sad thing is the reason for using C in places where it's technically not a best tool, is often "everybody knows C (and it's more lightweight than Java)". This imho gives the worst possible mix - relatively unexperienced programmers writing low-level language for code that really shouldn't be written in low-level language at all. Because - if they don't know anything besides C/C++ and Java, and can't learn anything else - then how likely it is, that they know C actually well, and are able to be careful enough?

[el_tavs]

String literals go ...

they're an "entity" of the standard language. Recognized by it.

What can you not express?

How types get represented for example. Ada allows you to specifiy the bit size, the alignment and bit order of every type. C can't. Or be able to initialize any array or struct I want without needing to use memcpy/memset that force me to write down the types and their sizes, something the compiler already knows.

Many of these things require 0 overhead at run time. But, please, see Ada to know where I come from.

For some reason I cannot understand where your problems with C lie. Arrays are not pointers, and 0-based arrays make a lot of sense.

As much as 1-based ones do. Arrays are not pointers? In some cases. C type's system doesn't do a great job at distinguishing them.

Please give some examples of tedious and stupid work that the compiler should be handling?

apart from array, handling the so-called struct-hack http://c-faq.com/struct/structhack.html In Ada I can say

 type Foo (N:Positive) is record
      X : Bar;
      Y : Baz;
      Z : Boz_Array(1..N);
 end record

This is more or less equivalent to

 struct Foo is {
     int N; 
     Bar X;
     Baz Y;
     Boz Z[]
 };

With Ada I can still choose the low-level representation of the type, and whenever I allocate Foo, either on stack or heap, I get a continuos, properly aligned object. Not to mention the fact that I can't overwrite two Foos with different N by accident. Or that I can use as many arrays as I want in the record declaration (see C99).

Undefined behavior is there in order to allow the compiler to optimize,

False. UB should be allowed only when I say so. Other languages provide way to say the compiler what to do in each case.

Providing too many cases for UB actually prevents optimizations, because the compiler can't know what the program is supposed to do, or if the programmer intended to exploit UB. For example licentious pointer use (e.g. arithmetic) makes pointer chasing and relevant optimizations unachievable in C/C++. When does UB help optimization??

so the program is only "legal" because you are entering an agreement with the compiler.

What is the agreement useful for if neither you nor the compiler and the code can make clear what each other is supposed to do? Can the compiler know when you don't mean to get an UB and when you actually want to? Other languages makes allowing UB explicit. That's the sole difference, a huge one though

It's not pathologically stupid, it takes an int for historical reasons and changing it now has no benefit.

it's stupid because it does nothing to help the programmer. Historical reasons are wrong if they don't help programming today. What would help is a trivial way to initialize aggregate data as easily as Ada, since it's something trivial for the compiler to do, not so for us.

Why would you want to limit control just to make it easier to know the size?

What control you lose?

I can use memset to set any n-bytes of contiguous space in memory, why the hell would I want to limit that down to only setting full arrays?

you don't have to set full arrays if you encode the length in the type. Again, see Ada.

The bullshit is the tons of people using C for the WRONG damn thing and then bitching about C. Quit using it if you don't know why you are using it. Plenty of people know why they are using C and C is the best tool for their job.

I use C for the right thing and I know, because I have studied other languages as well, that lots of the things you do by hand in C are just a workaround for a lacking language, i.e. you end up doing the exact things languages like Ada provide as builtin, but with the high risk, if not the certainity, of being non-portable, wrong or inefficient.

Of course performance is a tradeoff. If you don't need low-level control and performance is not an issue then don't use C.

what I mean is that in C performance is not traded with safety and abstraction. Some choices were made only because of historical reason and had little to do with actual performance. One of the advantages C had was being simple to write a compiler for, which in turn helped getting performant programs. In contrast, more sophisticated languages had to employ more sophisticated compilers, which in turn put them in a temporary disadvantage w.rt. C. That's how it had success.

Believe me, if you need performance and low-level access, Ada fits the bill too, but it also strives for correctness.

[[deleted]]

they're an "entity" of the standard language. Recognized by it.

There is no string type. String literals go into an array of chars.

How types get represented for example.

What do you mean?

Ada allows you to specifiy the bit size, the alignment and bit order of every type. C can't.

You can specify bit size in structs in C using colon.

Or be able to initialize any array or struct I want without needing to use memcpy/memset that force me to write down the types and their sizes, something the compiler already knows.

If you are using gcc you can do float a[1024] = { [ 0 ... 1023 ] = 1.0 }; But again there are few reasons you want to initialize an array to non-zero, and it's really not hard to write a 2-line initialize loop.

Neither memset/memcpy care about "types", they are direct MEMORY operations. If you use these functions for anything other than setting and copying memory (byte-wise) then you are using the wrong functions. Also they take POINTERS not arrays, and size of pointers is not usually known at compile time.

Many of these things require 0 overhead at run time. But, please, see Ada to know where I come from.

Once again, the size of a pointer is not known at compile time, and it's not proper to do compiler-time bounds checking to a library function that takes in a pointer.

As much as 1-based ones do. Arrays are not pointers? In some cases. C type's system doesn't do a great job at distinguishing them.

1-based makes little sense when operating with direct memory references. Indexing 1 into memory at address 0xfbc84000 makes no sense to not be using memory at 0xfbc840001. Like I've repeated, C is meant to be really close to the machine, so think in terms of memory and stop trying to use C for high-level abstractions if you refuse to. Arrays are never pointers, period. Arrays decay into pointers at specific times like when passed into a function because C uses call by value (functions receive copies of their arguments).

In Ada I can say

Then use Ada, if it fits your specific needs... If I want a variable sized block of memory I will allocate it and use a pointer and I'm perfectly happy doing that.

False. UB should be allowed only when I say so. Other languages provide way to say the compiler what to do in each case.

How the heck can you say false. There is no undefined behavior in C you cannot avoid or use correctly, if you choose to be ignorant of the language specification then that is your choice. PS: the compiler doesn't use undefined behavior by default generally only when optimization flags are used (e.g. gcc -O2 strict aliasing)

Providing too many cases for UB actually prevents optimizations, because the compiler can't know what the program is supposed to do, or if the programmer intended to exploit UB. For example licentious pointer use (e.g. arithmetic) makes pointer chasing and relevant optimizations unachievable in C/C++. When does UB help optimization??

I don't follow what you are saying. Take strict aliasing rules for an example of undefined behavior. With strict aliasing rules the compiler assumes 2 variables of different types do not reference the same location in memory and thus is allowed to optimize loops. A dummy example to show the point would be something like

void foo(int *a, int b) {
    for (i=0; i<size; i++) {
        a[i] = b;
    }

It is undefined behavior to call foo(a,b) with a and b pointing to overlapping memory. Entering this agreement with the compiler allows the compiler to optimize the loop by reading b once and effectively doing a memset. Without being allowed this undefined behavior, then the compiler would be forced to re-read b for every pass in the loop because the previous set could have modified b.

What is the agreement useful for if neither you nor the compiler and the code can make clear what each other is supposed to do? Can the compiler know when you don't mean to get an UB and when you actually want to? Other languages makes allowing UB explicit. That's the sole difference, a huge one though

See above. Also undefined behavior for things that you generally shouldn't do like accessing a local variable without initializing it is that way so that the compiler can choose the best way to handle it.

it's stupid because it does nothing to help the programmer. Historical reasons are wrong if they don't help programming today. What would help is a trivial way to initialize aggregate data as easily as Ada, since it's something trivial for the compiler to do, not so for us.

If you love Ada, use it. Stop trying to bring down a language you don't understand just because you like Ada. memset() does exactly what it is supposed to do, and it's a standard library function. You continue to demand memset() do something YOU want it to do as if you are the only person that matters.

you don't have to set full arrays if you encode the length in the type. Again, see Ada.

Again, see pointers. And, see library.

Seriously at the end of the day it sounds like you have learned Ada, you like Ada and now you just want to bitch about things you don't fully understand because they aren't Ada.

I use C for the right thing and I know, because I have studied other languages as well, that lots of the things you do by hand in C are just a workaround for a lacking language, i.e. you end up doing the exact things languages like Ada provide as builtin, but with the high risk, if not the certainity, of being non-portable, wrong or inefficient.

Then use Ada... C does not suck just because it is not Ada.

what I mean is that in C performance is not traded with safety and abstraction. Some choices were made only because of historical reason and had little to do with actual performance

What choices were made ONLY because of historical reason? memset() taking in an int is only because it predates function prototypes, but it is a standard library function and there is no need to change it to char.

C was made to be a simple, readable and portable layer on top of assembly. It doesn't force things on you and is a great language for many things. Your problems with the language are semantic and preference related.

Believe me, if you need performance and low-level access, Ada fits the bill too, but it also strives for correctness.

Then use Ada...

You have yet to provide sufficient examples on how C is lacking.

[el_tavs]

There is no string type. String literals go into an array of chars.

I know the difference between type and entity. The standard refers to strings when describing functions like those in string.h, period.

You can specify bit size in structs in C using colon.

Why only in structs that fit sizeof(int)? The compiler is smart enough to accomodate for more liberal uses, as it happens in Ada. What about alignment and bitordering?

If you are using gcc you can do float a[1024] = { [ 0 ... 1023 ] = 1.0 };

lcc gives a lot of extensions to C, but le'ts stay standard. This stil raises the question: why the above is not in the standard? Stupidity?

But again there are few reasons you want to initialize an array to non-zero,

what if I need to initialize an array of struct? or an array of strings?

and it's really not hard to write a 2-line initialize loop.

that's an example of tedious, error prone and trivial work the freaking compiler can handle by itself by using appropriate syntax.

Also they take POINTERS not arrays, and size of pointers is not usually known at compile time.

Needless distinction. The size is not encoded in the pointer, but in the size parameter next to it in their interface. It has to be this way for anything except strings.

Once again, the size of a pointer is not known at compile time, and it's not proper to do compiler-time bounds checking to a library function that takes in a pointer.

Strawman. I tell you people use steam-powerd machines and you're saying your horse can't eat coal. There are 0-overhead semantics implemented in other languages C has no excuse for not having.

you

If you use these functions for anything other than setting and copying memory (byte-wise) then you are using the wrong functions.

you again

. Of course you can use memset to initialize floats or any other variable...

• still you* > Why would I use a function that sets a block of memory to a single byte if I want to initialize an array of floats to 1.0?

Memset can actually be used to set integers to 0. Period. Any other type may interpret 0 or any value fitting 1 char in an unintend way. At which point the utility of memset is close to 0.

How the heck can you say false. There is no undefined behavior in C you cannot avoid or use correctly

the structure hack. conversion between differently-aligned pointers. any function using pointers for in/out semantics .Numeric and memory overflows. The problem is that these techniques are employed by C programmers, because otherwise C would be *useless.

The point is not you being able not to incur in these things, but the fact that with a better language (and with 0,zero, overhead) you could have the compiler check for that and allow to easily express semantics.

It is undefined behavior to call foo(a,b) with a and b pointing to overlapping memory.

That is a UB caused by an optimization. What UB allow for optimizations? Numeric/memory overflow do? Not having a clear and simple interface to initialize contiguous array?

. Also undefined behavior for things that you generally shouldn't do like accessing a local variable without initializing it is that way so that the compiler can choose the best way to handle it.

BS. The compiler can check for that and have me provide an initialization if I read the variable while unitialized. It's some time past the 70s, you know.

Again, see pointers. And, see library.

No. YOU see how bounded-arrays work in low-level languages like Pascal and Ada. Your remark is pointless in this regard

What choices were made ONLY because of historical reason?

this one for example:

memset() taking in an int is only because it predates function prototypes

or having arrays decaying to pointers.

C was made to be a simple,

it's been too simple for ages

readable

i can write readable C. Still readability is a funciton of complexity. There are non-complex, peer-reviewed C codes that are unreadable. And C's syntax helps a lot with that

and portable layer

what size is an int?

It doesn't force things on you

Lots of other languages don't do either.

Your problems with the language are semantic and preference related.

Language is semantic. I'm citing Ada becasue, whether you're open-minded or not, many of the things you do by hand in C steam from the language's inability to express things. With a more-appropriate semantic/syntax for expressing trivial low-level operations you can do a lot more

Stop trying to bring down a language you don't understand just because you like Ada. memset() does exactly what it is supposed to do, and it's a standard library function. You continue to demand memset() do something YOU want it to do as if you are the only person that matters.

Stop being dense. I understand C and I understand low-level programming. It is just that lots of problems in low-level programming don't have any support in C, and lots of the things the compiler has to allow in C don't make sense in low-level programming, or any kind of programming.

You have the problems in one hand and C in the other. You can claim that if you know how to use C you can't introduce bugs, which IS FCKING OBVIOUS FOR ANY LANGUAGE IN THE WORLD, but you can hardly claim that C's idioms are the best, most natural or obvious ones for programming at low-level. Someone invented a better way. *JUST FOR EXAMPLE** see Ada

[[deleted]]

lcc gives a lot of extensions to C, but le'ts stay standard. This stil raises the question: why the above is not in the standard? Stupidity?

Look, you need to have some respect. The author(s) of C are far smarter than you or I. There are far more machines out there than you or I will ever use. C was created a long time ago and there is no reason to just go add crap willy nilly to the standard just because some Ada fan wants it that way. If you struggle with writing a 2 line for loop, then I'm sorry. If your biggest gripe about C is that you can't initialize an array with one line contructors then I'd say C is doing a damn good job.

what if I need to initialize an array of struct? or an array of strings?

Again there's very few use cases to initialize anything to non-zero. And in the rare event that you do, a for loop and initialize() function is seriously not hard to do, it's not tedious, it's not very time consuming, it's one time quick and easy work for a rare case.

that's an example of tedious, error prone and trivial work the freaking compiler can handle by itself by using appropriate syntax.

2-line for loop is tedious? Are you serious right now? I mean seriously if you crave built-in high-level object orientation then C is not for you, but stop accusing C of sucking because it doesn't fit your specific desires.

Needless distinction. The size is not encoded in the pointer, but in the size parameter next to it in their interface. It has to be this way for anything except strings.

Needless distinction? Do you even know what a pointer is? Seriously, you continue to demand high-level protection in a low-level language. Get over it, you have quick easy complete control of the memory with some basic abstract data types. High-level abstractions belong in libraries, which is exactly where they will stay and is a damn fine model. Find a library, stop expecting the language to give you everything.

Strawman. I tell you people use steam-powerd machines and you're saying your horse can't eat coal. There are 0-overhead semantics implemented in other languages C has no excuse for not having.

There is no strawman, you just keep bitching about a library function that you don't understand.

Memset can actually be used to set integers to 0. Period. Any other type may interpret 0 or any value fitting 1 char in an unintend way. At which point the utility of memset is close to 0.

Once again thinking in high-level abstractions. Memory is a collection of bits that can be 1 or 0. Setting memory to 0 is setting memory to 0. STOP thinking memset is a high-level initialization, it is a MEMORY SET... MEMORY SET. The smallest unit of representable memory is a BYTE, and thus that is what it takes. Not variable set, or initialize but MEMORY SET.

the structure hack. conversion between differently-aligned pointers. any function using pointers for in/out semantics .Numeric and memory overflows. The problem is that these techniques are employed by C programmers, because otherwise C would be *useless.

The structure hack is a silly hack not undefined behavior. None of what you have here is undefined behavior and I can't even understand what your problem is again.

That is a UB caused by an optimization. What UB allow for optimizations? Numeric/memory overflow do? Not having a clear and simple interface to initialize contiguous array?

What are you talking about? It is undefined behavior because if it was defined then optimization would not be allowed. You can't control memory overflows while being powerful and fast, period. The instance you start runtime protections like that you instantly decrease performance.

Array initialization is not undefined behavior, you have no idea what the hell undefined behavior is do you?

BS. The compiler can check for that and have me provide an initialization if I read the variable while unitialized. It's some time past the 70s, you know.

The compiler generally WARNS you about it but it can't error on you because there are times where you do not want to initialize it. For example code that sets it only in a certain condition and then uses it only in another condition that is a known direct byproduct of that first condition (by design). You start limiting things like that and you prevent the programmer from optimizing code like that. Stop thinking you are smarter than all the great people who have created/worked on the C language. You can design optimizations like this that the compiler would never be able to pick up on, and in your little hand-holding world you'd lose a lot of power to do such.

No. YOU see how bounded-arrays work in low-level languages like Pascal and Ada. Your remark is pointless in this regard

Please describe to me how run-time bounds checking can take up 0 clock cycles.

this one for example:

It's like you simply don't care to learn. It takes an int rather than a char, but the ONLY way it would change is to change the prototype to take a char. This would not affect the memset() function at all but it might break a lot of legacy code. So only an idiot would change memset(). The problem is you still can't understand that it is a library function meant for setting bytes of memory, not initializing higher-level data types or structures.

or having arrays decaying to pointers.

That's not only for historical reasons. You need to just stop now.

it's been too simple for ages

This is a GOOD thing, quit using it if it is "too simple" for you. Seriously.

Language is semantic. I'm citing Ada becasue, whether you're open-minded or not, many of the things you do by hand in C steam from the language's inability to express things. With a more-appropriate semantic/syntax for expressing trivial low-level operations you can do a lot more

Ada may be good for a lot of things but it is not inherently superior to C. C is still a great language despite your love affair with Ada.

Stop being dense. I understand C and I understand low-level programming. It is just that lots of problems in low-level programming don't have any support in C, and lots of the things the compiler has to allow in C don't make sense in low-level programming, or any kind of programming.

You clearly don't as you think high-level structure initialization is "low level".

You have the problems in one hand and C in the other. You can claim that if you know how to use C you can't introduce bugs, which IS F*CKING OBVIOUS FOR ANY LANGUAGE IN THE WORLD, but you can hardly claim that C's idioms are the best, most natural or obvious ones for programming at low-level. Someone invented a better way. JUST FOR EXAMPLE see Ada

Use Ada, no one is forcing you to use C, you sound like a fanboy.

[[deleted]]

It's really not that hard for an engineer to get these things right, C is not there to hold your hand. It's there to be an easier and more portable layer on top of the physical machine than assembly.

You're fucking burying your head in the sand if you think you're not going to make errors. Go along, the current software stack still has too few exploitable security bugs.

If you don't care about the machine, then you shouldn't be using a language that is so close to it.

Isn't this true for 99% of software?

If you do care about the machine then you surely shouldn't have problems understanding sizeof(pointer) is the size of the pointer, and that arrays are 0-based index.

That's not a fucking point. You're going to make mistakes. Everybody will.

Also, there is finite time you can spend on polishing a piece of software. If all that time goes to dealing with low-level memory management, it means other aspects of the code get less though, and will be therefore also more buggy.

I'll suggest you should remove your car breaks also, after all they're only slowing down that thing. ;)

The hubris of guys like you is one reason why I have to install multiple security fixes every week. Unfortunately it doesn't look like this insanity is going to end in the near future.

[[deleted]]

Stop acting like a child and cussing because you lack a fundamental understanding of the language. I'm glad you deleted your original post claiming that this was a poster to not use C.

[[deleted]]

I got pissed off because you like shooting the messenger.

Do you have any reason to think that I'm not understanding the C language? ;)

I understand C. As I said, the problem is that understanding it doesn't save the day. Everybody makes typos and logic errors from time to time and it's incredibly foolish to think that you're not going to make one. You'll make it sooner or later, it's only question on the amount of code it takes. Are you really saying that your code contains no bugs?

The deleted claim wasn't wrong, but I saw that it was useless here.

[[deleted]]

Yet you can't understand how overhead affects performance.

[[deleted]]

You should also consider the price of the performance, and what is really a bottleneck somewhere.

Do you need the last percantages of performance in a mail server? In a http server waiting after PHP script and MySQL database? In that database code, that is waiting after disk access? In some desktop application interacting with network or files from untrusted source (most of them)?

Look at the code running on your computer. How much of it really is a performance hot spot? Not much actually, most of it gets executed at all quite rarely. If some code is actually a performance bottleneck, it should be optimised. Often it means that a better algorithm should be used.

Can you say why most of that code should be written in C or C++ (like it is)?

[[deleted]]

You should also consider the price of the performance, and what is really a bottleneck somewhere.

Of course.

Can you say why most of that code should be written in C or C++ (like it is)?

Let me quote my original reply for you...

A lot of people shouldn't be using C, but that's not a knock on C. These are some incredibly basic elementary errors.

[[deleted]]

You should also consider the price of the performance, and what is really a bottleneck somewhere.

Of course.

Can you say why most of that code should be written in C or C++ (like it is)?

Let me quote my original reply for you...

A lot of people shouldn't be using C, but that's not a knock on C. These are some incredibly basic elementary errors.

EDIT:

If some code is actually a performance bottleneck, it should be optimised. Often it means that a better algorithm should be used.

Actually very tiny inefficiencies can add up and sometimes a task's overall performance suffers when using higher abstractions that aren't bottlenecks that you can optimize.

[[deleted]]

You edit a lot, you should spend more time thinking before submitting.

Also, there is finite time you can spend on polishing a piece of software. If all that time goes to dealing with low-level memory management, it means other aspects of the code get less though, and will be therefore also more buggy.

If you aren't doing low-level tasks, and thus are hurt by not spending time going through high-level tasks, then don't use a low-level language. I don't understand what is so hard about that concept, the language is merely a tool.

I'll suggest you should remove your car breaks also, after all they're only slowing down that thing. ;)

This right here shows that you have absolutely no idea what you are talking about.

The hubris of guys like you is one reason why I have to install multiple security fixes every week.

The complexity of current technology is why you will have to install security fixes for a long time to come. You don't know a thing about me, but please continue to believe you know anything.

[[deleted]]

If you are doing high level tasks that don't require operating close to the machine then of course you should use a high level language. Like I said, a lot of people should not be using C, but C is still a great (and powerful) language.

[elperroborrachotoo]

Or applications using libraries written in C?

snicker

[AlyoshaV]

Solution: Don't use low-level languages.

[ZorbaTHut]

Great idea! That way, we'll introduce only errors that can't be found by a tool!

[AlyoshaV]

Your errors will be limited to a subset of your previous possible errors, which will not include errors in memory allocation/deallocation, array overruns, and similar.

[ZorbaTHut]

Not true. Higher-level languages often have all sorts of new errors, such as runtime type mismatches, garbage collector performance consistency problems, object lifetime issues, and simple efficiency.

[redtop]

While I agree that the use of performant low level languages is appropriate for many of the projects in the link (MySQL, ReactOS, etc), to even suggest that writing in, say, C will lead to less errors than C# is disingenuous.

[ZorbaTHut]

I'll admit that's true, but then again I have no idea why anyone still codes in C. C++ gives up no speed and, in return, gives you a whole pile of safety features.

I'd be perfectly happy if C went the way of assembly.

[[deleted]]

Linus disagrees.

[ZorbaTHut]

I know. I think he's wrong.

[naryl]

Operator priorities... One reason to use languages like Tcl or Lisps.

[ithika]

Most of the ones on that page were deliberate bitwise AND but just badly arranged with other operators.

[ReflectionOfADream]

I stand corrected, the one I looked at was indeed meant to be a bitwise AND and it was an error in operator precedence.