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

C Questions and Answers

kukuruku.co

Post reply on HN
Print view View original

121–130 of 135 posts

Re: C Questions and Answers

#121

Post by rm445 »

ChuckMcM wrote: post #30

I think this was silly, the author clearly does know C but they are complaining about optimizing compilers which do things "behind your back" and are becoming an increasing nuisance. It's sort of a passive aggressive "I think this should be an error but it isn't an error because twisted logic that the compiler uses with respect to undefined operation." That people can teach themselves what to expect the compiler to d…

That's only the one example, and the author could have thrown his hands up with the usual explanation that undefined behaviour entitles the compiler to launch missiles at you or whatever.

But in fact it's quite a reasonable (the only reasonable?) approach to optimisation, given a function that might invoke undefined behaviour on certain arguments, to emit code that is optimised for work on arguments that don't.

That doesn't seem to me to be tortured logic. The compiler ought to make that optimisation, always. It might be perfectly clear to the programmer that the function in question can never be sent a null pointer, but only by reasoning about the program on a level the compiler can't. It's only a minor side benefit that this can allow a certain amount of reasoning about the code paths that might be taken when you DO invoke undefined behaviour. That usually won't be much use, but might help one identify the kind of error one has made.

I expect most of us here have puzzled over some confusing output from a C program and tried to work out, from the output, whether we made an allocation error or overflowed a buffer or were off-by-one on some bounds. It's a wonderful language in some ways, but the pitfalls are there. Which is the point the author is trying to make.

Re: C Questions and Answers

#122

Post by seba_dos1 »

5 is IMO nothing else than nitpicking. 2 and 4 (and maybe 6) might have some importance in real life, while others are easy and kinda expected (although comma operator in 8 might not be known to less experienced programmers). I can't really see the point of this article other than "hey, do you remember that there is a concept called undefined behavior in C?".

Re: C Questions and Answers

#123

Post by seba_dos1 »

zamalek wrote: post #87
geocar wrote: post #58

Earlier quoted context omitted.

That is not a pointer. In C I can perform arithmetic on a pointer. `v` is a symbol which references an object. It might be acceptable to refer to `v` as a reference if we're being sloppy. JavaScript has a DataView[1] which could be used to implement what I think is a pointer, but I do not think that most JS developers have used it. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

As compiled by the JIT, `v` is a pointer. That is how it is implemented, `v` is not a copy of `{}`, it points to a location of memory that contains `{}`. A pointer is not defined as being "allowed to do arithmetic" it is defined as "points to a location in memory," no more, no less. > In computer science, a pointer is a programming language object, whose value refers to (or "points to") another value stored elsewhere…

So from now on we should call every structure which is implemented inside library, compiler or JIT using a pointer, a "pointer"?

> In computer science, a pointer is a programming language object, whose value refers to (or "points to") another value stored elsewhere in the computer memory using its address.

You have your answer here. In JavaScript ("programming language"), v ("object") has a value of JavaScript structure called object. Internal representation of v sure does use a pointer, but from JavaScript perspective, it surely is NOT a pointer. If you get the value of v in JavaScript, you don't get memory address ("value [that] refers to (or "points to") another value stored elsewhere in the computer memory using its address") - you get the object itself. That's what references do, not pointers.

Re: C Questions and Answers

#124

Post by skazka16 »

belovedeagle wrote: post #112

Why the heck was the name of this post changed? It rather conveniently puts the author in a better light by downplaying the anti-intellectual nature of the article I commented about above. I thought the general rule was that posts should be titled with the title of the linked article, which was the case before but now is not the case. EDIT: To answer my own question, the submitter is clearly the author based on his s…

Not exactly true. I publish articles, which we translate into English (mainly from Russian). The original author is Dmitri Gribenko and it seems he is not a member of HN community.

Re: C Questions and Answers

#125

Post by pjmlp »

ericfontaine wrote: post #98
pjmlp wrote: post #92

Earlier quoted context omitted.

> I have trouble imagining how to make something like C any lower without becoming architecture-specific or cumbered with details that are more economically-suited for a compiler. You mean Algol, Mesa, and few others from the same vintage or even older? Or rather Macro Assemblers like MASM, TASM that provided higher level macros for structured programming?

what I mean in my paragraph is that C has all these (nasty) details that are necessary due to C's position as being almost assembly language (but not quite) AND being cross-platform. Macro assembles like MASM and TASM use ISA-specific assembly languages, so you can't write cross platform code. I suppose one could image a sortof cross-platform LLVM IR structured macro assembler might be an example of something lower t…

> Algol is higher level than C.

Sure, but it is also safer and already had helped implementing a few operating systems before C's authors could imagine coming up with C.

Re: C Questions and Answers

#126

Post by ygra »

seba_dos1 wrote: post #122

5 is IMO nothing else than nitpicking. 2 and 4 (and maybe 6) might have some importance in real life, while others are easy and kinda expected (although comma operator in 8 might not be known to less experienced programmers). I can't really see the point of this article other than "hey, do you remember that there is a concept called undefined behavior in C?".

You'd be surprised how many C or C++ programmers don't know about UB. Some (I've worked with one of them) even went so far as to say »I know what assembly the compiler generates from that, even if it's UB I know how it behaves.« And those people then wonder that their code does something differently when moving to a new compiler version, or when switching to a different compiler.

Re: C Questions and Answers

#127

Post by weland »

JoeAltmaier wrote: post #107
weland wrote: post #104

Earlier quoted context omitted.

I don't remember any of that, either. The worst I've ever had was a silly bug due to operator precedence. Barring some truly uninspired things (like signed integer overflow being undefined), I really think most of those are cases one shouldn't run into, not even in a much more complicated situation.

Many of the complicated situations arise from macros and templates that use arguments in contexts the coder doesn't know. E.g. the stl. Also the macro writer doesn't know the context wherein the macro will be expanded. You can end up with issues of precedence, correct statement construction, expression evaluation order etc.

STL is not a problem in C land and fishy macros don't make it past code review in my book :-).

I don't disagree on the usefulness of teasing your brain with these things once in a while. However, I think the best way to ensure you don't hit bugs caused by such things is to avoid the situation altogether.

Re: C Questions and Answers

#128

Post by JoeAltmaier »

weland wrote: post #127
JoeAltmaier wrote: post #107

Earlier quoted context omitted.

Many of the complicated situations arise from macros and templates that use arguments in contexts the coder doesn't know. E.g. the stl. Also the macro writer doesn't know the context wherein the macro will be expanded. You can end up with issues of precedence, correct statement construction, expression evaluation order etc.

STL is not a problem in C land and fishy macros don't make it past code review in my book :-). I don't disagree on the usefulness of teasing your brain with these things once in a while. However, I think the best way to ensure you don't hit bugs caused by such things is to avoid the situation altogether.

It doesn't have to be a very fishy macro at all to be problematic. How about

  #define  Sum(a,b) a+b
This of course fails in any context where the precedence of '+' doesn't match your intent e.g. Sum(1,5)7 becomes 1+57

Do you remember to always define your expression macros with parentheses? Any time you didn't do that, you have a bug.

Re: C Questions and Answers

#129

Post by ericfontaine »

pjmlp wrote: post #125
ericfontaine wrote: post #98

Earlier quoted context omitted.

what I mean in my paragraph is that C has all these (nasty) details that are necessary due to C's position as being almost assembly language (but not quite) AND being cross-platform. Macro assembles like MASM and TASM use ISA-specific assembly languages, so you can't write cross platform code. I suppose one could image a sortof cross-platform LLVM IR structured macro assembler might be an example of something lower t…

> Algol is higher level than C. Sure, but it is also safer and already had helped implementing a few operating systems before C's authors could imagine coming up with C.

Right.

My understanding of history is compiled Algol wasn't nearly as fast as compiled C, which was needed for operating systems and performance-critical code.

Re: C Questions and Answers

#130

Post by ericfontaine »

_kst_ wrote: post #116
ericfontaine wrote: post #97

Earlier quoted context omitted.

#1. Tentative definitions are historical baggage from Fortan Common blocks ( https://blogs.oracle.com/ali/entry/what_are_tentative_symbol... ), which may have helped adoption of C by Fortran users. Although it remains in the C language specification, this feature can be ignored. #2. Treating dereferencing a NULL pointer as undefined behavior means that the compiler is not required to generate additional instructions…

5. size_t doesn't necessarily have to be the width of an address. An address (say, a value of type void* or char ) has to be able to refer to any byte of any object. A size_t only has to be able to represent the size of any single* object. The limit on the size of a single object and the limit on the total size of memory are often the same on modern systems, but C allows them to be different (think segments). 6. size…

I forgot about segments... Thanks for clarifications...I guess I don't know C. :)
Post reply on HN