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

61–70 of 135 posts

Re: C Questions and Answers

#61

Post by copsarebastards »

1.

    int i = 10;
Q. Is this code correct?

A. Yes.

2.

    extern void bar(void);
    void foo(int *x)
    {
      if(x == NULL)
      {
        return;
      }

      int y = *x;
      bar();
      return;
    }
Q. It turns out if you check the validity of your variables before you use them it prevents you from having to understand undefined behavior.

A. Is there a question here?

3. There was a function:

    #define ZP_COUNT 10
    void func_original(int *xp, int *yp, int *zp)
    {
      int i;
      for(i = 0; i
I optimized it this way:

...because nobody had any idea what it was doing and so it wasn't used anywhere.

4.

    double f(double x)
    {
      assert(x != 0.);
      return 1. / x;
    }
Q. Is it possible for this function to return inf?

A. If you're at the point where you're asking that question you should have been using a decimal library a long time ago.

    int my_strlen(const char *x)
    {
      int res = 0;
      while(*x)
      {
        res++;
        x++;
      }
      return res;
    }
Q: The provided above function should return the length of the null-terminated line. Find a bug.

A. They didn't use `strlen()`.

Re: C Questions and Answers

#62

Post by icebraining »

oneeyedpigeon wrote: post #54
zamalek wrote: post #52

Earlier quoted context omitted.

> javascript is a [...] language for amateurs He never said that or implied it.

"If you only know Javascript" - why even bring that up? There is no mention of Javascript in the original article at all.

Because it's a language that many people know exclusively?

Re: C Questions and Answers

#64

Post by heinrich5991 »

fizixer wrote: post #42
obstinate wrote: post #27

Earlier quoted context omitted.

Since he's talking about undefined behavior in a lot of the cases, the answer to all your questions is, "Yes." That's pretty obvious, so maybe he thought it went without saying.

Not sure which of my questions you're referring to. As I replied to others, saying "bar() is invoked" is not only not obvious, it's incorrect. bar() may or may not be invoked.

That's correct, what he wanted to say is probably that there exists compilers where `bar()` is invoked. Don't be so snarky, try to understand what the author ment.

Re: C Questions and Answers

#65

Post by icebraining »

rtpg wrote: post #26
_RPM wrote: post #2

This reminds me of tests I took in earlier CS classes. Knowing those things are utterly useless in practice.

only useless if you never make a mistake ever. This shows what you should be vigilant for (alternatively , an argument for using a language with more checks) As someone on HN once said (in jest), it's easy to write bug-free C, you just need to never make a mistake ever and spend a million hours auditing it.

If those mistakes are so teachable, wouldn't it be better to put them into a linter?

Re: C Questions and Answers

#66

Post by valleyer »

fizixer wrote: post #42
obstinate wrote: post #27

Earlier quoted context omitted.

Since he's talking about undefined behavior in a lot of the cases, the answer to all your questions is, "Yes." That's pretty obvious, so maybe he thought it went without saying.

Not sure which of my questions you're referring to. As I replied to others, saying "bar() is invoked" is not only not obvious, it's incorrect. bar() may or may not be invoked.

You are misparsing. He's effectively saying: imagine you are testing this code, and x == NULL but "bar() is invoked". Is the compiler buggy?

Re: C Questions and Answers

#67

Post by pmr_ »

xenadu02 wrote: post #60
userbinator wrote: post #56

Earlier quoted context omitted.

On the topic of (overly) aggressively optimising compilers: http://blog.metaobject.com/2014/04/cc-osmartass.html ...and attempts at turning C into something a bit less programmer-hostile: https://news.ycombinator.com/item?id=8233484 My point of view is that compilers should be optimising at the level of machine instructions, not by attempting to second-guess the programmer and remove code that it thinks invokes UB. I…

Meh, the problem is the preprocessor. A lot of really silly things are produced by macro expansion, so the "obviously silly" optimizations really do end up mattering.

That sounds interesting, but I'm suspicious. Do you have any examples of such macros and maybe some statistics or ideas how often they are actually seen in the wild?

Re: C Questions and Answers

#69

Post by joosters »

icebraining wrote: post #65
rtpg wrote: post #26

Earlier quoted context omitted.

only useless if you never make a mistake ever. This shows what you should be vigilant for (alternatively , an argument for using a language with more checks) As someone on HN once said (in jest), it's easy to write bug-free C, you just need to never make a mistake ever and spend a million hours auditing it.

If those mistakes are so teachable, wouldn't it be better to put them into a linter?

They are in linters, and many of them will be thrown up as warnings by the compiler in the first place.

Re: C Questions and Answers

#70

Post by joosters »

bgvopg wrote: post #15
kdoherty wrote: post #10

Unsigned int >= 0 in a decrementing for-loop is a classic trap

Some would twitch at this: for(i = length - 1; i but it is completely valid.

The twitchers are right. Whoever wrote that line of code is a smartass who is deliberately obfuscating stuff. Don't work with these people!
Post reply on HN