Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fixing C

embedded.com

Post reply on HN
Print view View original

91–100 of 123 posts

Re: Fixing C

#91

Post by rkangel »

Terribledactyl wrote: post #86
rkangel wrote: post #75

Earlier quoted context omitted.

It will print 10. There's absolutely no issue there at all. You've changed the value of the pointer which is NOT const. const int \*b Means a pointer to a thing that is const. The pointer itself (which is on the stack in this case) is NOT const. const int *b = 9; *b = 10; ^^^ This will NOT compile. const int b = 9; int main() { int *a = (int *)b; *a = 10; } ^^^ This will compile (possibly with warnings). If you run i…

No I don't want to throw it out, I kinda like C. And you can also do seemingly weird things with it. I was trying to bring some light to how const and immutable could be conflated. A lot of people see const and think, no aspect of this is changeable.

If you think that though, you haven't got a clear picture of what pointers are and how they work. The pointer itself and thing it is pointing to are two completely different variables in memory. Being unclear about the difference is likely to cause lots of problems when coding C.

Using a pointer to iterate through a string/array/other data structure, that is stored in const is a completely standard thing to do.

Re: Fixing C

#93

Post by _kst_ »

A less drastic change that would achieve the same purpose would be to require braces in selection and iteration statements, and to add an "elseif" or "elsif" keyword to replace "else if" chains. That's what Perl does, and it works pretty well.

Of course it would break a lot of existing C code, which is why it will never happen in any language named "C".

Re: Fixing C

#94

Post by ArkyBeagle »

noir_lord wrote: post #83
ArkyBeagle wrote: post #70

Earlier quoted context omitted.

This happens because people don't use the tools properly.

If different people keep chopping into themselves with a power tool it's probably wise to consider a safety guard.

Wrong is still wrong, and if someone did it, they did it wrong.

This really isn't complicated. It's hardly obscure. There's no excuse.

Re: Fixing C

#95

Post by joeld42 »

jandrese wrote: post #80
adwn wrote: post #54

Of all the things in C that cause problems and that could be fixed by waving a magic wand, the author chose "curly braces"?! That betrays an immense lack of imagination! Worse, it shows that the author isn't even aware of the actual causes of lost productivity and bugs in C programs. What about buffer overflows (it happens to the best of us)? Mounds of undefined behavior exploited by optimizing compilers (even in see…

I've always wanted a heap inspection function. Give it a pointer and it returns the amount of data allocated to it. I mean free() can figure it out, why can't I see it? I'm sure there are some good technical reasons that make this difficult/expensive, but there aren't even any half measures available. Not even something that requires the pointer be at the start of the originally malloc()ed memory and can return an er…

So write your own allocator...

EDIT: That might sound snarky, it's not meant to be. I just mean that you can do something like this:

https://gist.github.com/joeld42/74f67cde97a789467a2f681961b8...

people complain about C's memory manager, but really it's one of the most flexible out there because you can do stuff like this. Well written C libraries will provide hooks to use a custom allocator if needed.

Re: Fixing C

#96

Post by cyphar »

Of all the things you could have chosen, you picked the most trivial? I hate loops and logic in bash because you need to always do things like this:

  for i in {1..20}
  do
    echo $i
  done
What is the purpose of having the `do` and `done`? And with if statements, what's the purpose of having `then` and `fi`? Curly braces fix that issue and are much easier to read. Not to mention that literally every single real editor has a plugin for making sure your braces always match up.

I think `else if` to `elif` would be a much better change to fix people who write `else if` and other things that make it hard to read code. However, it should be noted that you couldn't do some pretty horrible macro hacks that way (but maybe if you made the no-brackets format of blocks no longer valid, then that problem would be fixed).

Not to mention that `end ` is syntactic clutter. We all know what block it must terminate -- that's why brackets work.

Re: Fixing C

#97

Post by cyphar »

mfukar wrote: post #66
veli_joza wrote: post #59

Earlier quoted context omitted.

Exactly. When array is passed into function, you lose length information and array construct is reduced to pointer. Array syntax is just synthetic sugar for dereferencing pointer with offset.

This discussion won't get very far if all you think arrays are is syntactic sugar. The array type is useful - think in terms of a static analyser if it helps - in different ways than pointers.

"array syntax" != "arrays". He means things like a[i]. Arrays are only really arrays in their local scope, if you pass them to functions they suddenly are pointers (but for some insane reason, C compilers let you specify "the size of the array in a function argument" which doesn't actually compile to any code).

Re: Fixing C

#98

Post by jamessu »

Terribledactyl wrote: post #86
rkangel wrote: post #75

Earlier quoted context omitted.

It will print 10. There's absolutely no issue there at all. You've changed the value of the pointer which is NOT const. const int \*b Means a pointer to a thing that is const. The pointer itself (which is on the stack in this case) is NOT const. const int *b = 9; *b = 10; ^^^ This will NOT compile. const int b = 9; int main() { int *a = (int *)b; *a = 10; } ^^^ This will compile (possibly with warnings). If you run i…

No I don't want to throw it out, I kinda like C. And you can also do seemingly weird things with it. I was trying to bring some light to how const and immutable could be conflated. A lot of people see const and think, no aspect of this is changeable.

His point was that you aren't interpreting the `const' the same way the compiler does.

To the compiler, this:

    const int *a;
    a = NULL; // perfectly OK
    *a = 0;   // does not compile
Is a pointer to a constant int, not a constant pointer to an int.

You're probably confusing it with this:

    int *const a;
    a = NULL; // does not compile
    *a = 0;   // perfectly OK
Which is a constant pointer to a regular int.

Of course you can combine both as follows:

    const int *const a;
    a = NULL; // does not compile
    *a = 0;   // does not compile
Which is a constant pointer to a constant int (which, of course, makes no sense at all in this case since 'a' is uninitialized and cannot be initialized without an unsafe cast, but it's a perfectly valid statement in C).

Re: Fixing C

#99

Post by Retra »

I despise BEGIN/END blocks, and here's why:

One of the most beautiful and elegant ideas in syntax is that of pattern matching. You want your syntax to match your semantics. That means, for instance, that your arrays (being a fixed, ordered sequence of items) should be presented syntactically as a fixed, ordered sequence of symbols. Your functions (being means of converting inputs to outputs) should syntactically separate inputs from outputs. (This is why I also despise INOUT and it's brethren.) And the most elegant languages will even use pattern matching for control flow, by syntactically differentiating different branches in parallel.

Part of C's brilliance was using pattern matching to declare variable types. So when you write this:

    int *a;
If you solve for `a`, you get an `int * `, and if you solve for `* a`, you get `int`. That kind of general purpose symmetry is the goal.

However, BEGIN/END as delimiters of blocks of code are far to imperative. The words refer to positions in the code, not to the structure of the code itself. This allows it to create noisy ambiguities:

    FOR i=0; i  0
            ....
        END FOR
    END WHILE
This is nonsense, because the terms are too granular and don't work in relative position. It may be more explicit, but explicit is only good when you're actually making decisions. Nobody should be deciding to overlap loops or blocks of code. Explicit is not good when there's one best way to do something, and `{}` always implicitly denotes a block. Nesting is easy, and doesn't need to be explicit. It just needs to be readable.

Re: Fixing C

#100

Post by dpc_pw »

I generally don't use downvote button on social sites, but this time I really miss it.

This article is contentless... I mean there's absolutely nothing informative in it. And anyone who things that curly brackets is the thing to fix in C must have been never using C in the first place.

Post reply on HN