Live data from Hacker News

Show HN: A fast, dependency-free traceroute implementation in pure C

github.com

31–34 of 34 posts

Re: Show HN: A fast, dependency-free traceroute implementation in pure C

#31
post #30

Earlier quoted context omitted.

Instead of ranting and showing a huge warnings output to make a point fitting your agenda, you could have just disabled the false positives yourself (like I did, by the way) and you would have seen that that vastly reduces the warnings. Oh, and to disprove your other claim, here is a link to the godbolt with added clang-tidy flag: https://godbolt.org/z/G31Ws8aa1 . This has the clang-tidy invocation changed to disable…

Were they false positives though? How come "which isn't that easily to provide in compiler explorer, " suddenly becomes me telling that was impossible? If you enjoy typing a endless list of clang-tidy flags on a tiny text box, well fun is on the user. The first concern is that some parts of the industry keep reaching to C when there are better alternatives, even the language authors have moved on to creating better l…

> Were they false positives though?

I've looked at them -- not all of them but all that I've looked at were the same kind recommending memcpy_s instead of memcpy, and were ridiculously easily to classify as false positives. So yes.

> How come "which isn't that easily to provide in compiler explorer, " suddenly becomes me telling that was impossible?

You claimed it wasn't easy but it is easy. VERY easy. It's one flag to disprove your point. Be honest.

> The first concern is that some parts of the industry keep reaching to C when there are better alternatives, even the language authors have moved on to creating better languages.

Many still enjoy it, are productive, and are creating infrastructure for billions of people to use. Let's keep things in relation.

Re: Show HN: A fast, dependency-free traceroute implementation in pure C

#32
post #21

Earlier quoted context omitted.

It has now been changed to if (rtt https://github.com/davidesantangelo/fastrace/blob/e8b19407a4...

And the update message has a reference to "50µs localhost responses", indicating the comment calling the code out was directly fed into a prompt: "Fixed Removed artificial RTT clamping that was hiding legitimate network measurements Previously clamped RTT between 0.05ms and 800ms Now reports actual values including sub-50µs localhost responses and >800ms satellite/long-distance links Added sanity check for negative R…

Thanks for pointing this out. If someone reports a bug in my software, I usually acknowledge the reporter in the commit message. Seems like vibe coding also allows one to get rid of this pesky obligation.

Re: Show HN: A fast, dependency-free traceroute implementation in pure C

#33
post #26

Earlier quoted context omitted.

Instead of ranting, you should have realized that is the default output without configuration file, which isn't that easily to provide in compiler explorer, without going through the trouble of a project template. Naturally on a real project there would be an heavily customised static analysis tool, that would only allow a build to succeed with the feedback from the SecDevOps team, alongside feedback loop from pentes…

Instead of ranting and showing a huge warnings output to make a point fitting your agenda, you could have just disabled the false positives yourself (like I did, by the way) and you would have seen that that vastly reduces the warnings. Oh, and to disprove your other claim, here is a link to the godbolt with added clang-tidy flag: https://godbolt.org/z/G31Ws8aa1 . This has the clang-tidy invocation changed to disable…

I always assume that anyone that says that something is a false positive without providing any rigorous proof has confirmation bias and are sadly deluding themselves about their ability and the correctness of their code.

Re: Show HN: A fast, dependency-free traceroute implementation in pure C

#34
post #33

Earlier quoted context omitted.

Instead of ranting and showing a huge warnings output to make a point fitting your agenda, you could have just disabled the false positives yourself (like I did, by the way) and you would have seen that that vastly reduces the warnings. Oh, and to disprove your other claim, here is a link to the godbolt with added clang-tidy flag: https://godbolt.org/z/G31Ws8aa1 . This has the clang-tidy invocation changed to disable…

I always assume that anyone that says that something is a false positive without providing any rigorous proof has confirmation bias and are sadly deluding themselves about their ability and the correctness of their code.

I said "probably" because the other messages from clang-tidy were so low quality obvious false positives too, a waste of time. I've already given the remaining warning a look and the code seemed fine to me. I didn't follow the whole massive linter output. Did you?
Post reply on HN