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

Show HN: I wrote a Java decompiler in pure C language

github.com

Post reply on HN
Print view View original

61–70 of 104 posts

Re: Show HN: I wrote a Java decompiler in pure C language

#61

Post by 1718627440 »

norir wrote: post #59
gibibit wrote: post #27

I am always curious how different C programs decide how to manage memory. In this case there are is a custom string library. Functions returned owned heap-allocated strings. However, I think there's a problem where static strings are used interchangably with heap-allocated strings, such as in the function `string class_simple_name(string full)` ( https://github.com/neocanable/garlic/blob/72357ddbcffdb75641... ) Somet…

Many command line tools do not need memory management at all, at least to first approximation. Free nothing and let the os cleanup on process exit. Most libraries can either use an arena internally and copy any values that get returned to the user to the heap at boundaries or require the user to externally create and destroy the arena. This can be made ergonomic with one macro that injects an arena argument into func…

That might be true, but leaking is neither the critical nor the most hard to find memory management issue, and good luck trying to adapt or even run valgrind with a codebase that mindlessly allocates and leaks everywhere.

Re: Show HN: I wrote a Java decompiler in pure C language

#62

Post by AgentME »

Sophira wrote: post #60
kamma4434 wrote: post #45

I cannot help but wonder why starting a new project in C in 2025. It’s like driving a car with no seat belts. You sure you want to do that?

We need people who can (and do) write in C, assembly, and all these low-level languages. Otherwise, software will just get slower and slower.

Rust has the same low-level memory model as C without the footguns.

Re: Show HN: I wrote a Java decompiler in pure C language

#63

Post by 1718627440 »

uecker wrote: post #58
mdaniel wrote: post #20

Earlier quoted context omitted.

This has been my life experience with things written in C/C++, so speed doesn't matter. Or, I guess from an alternative perspective, it ran very fast, but exited very fast, too :-D $ ./objdir/garlic $the_jar_file -o out-dir -t $(nproc) Progress : 85 (1024)Segmentation fault: 11

Is it? This is my experience with Python. The C/C++ programs I use daily never seem to crash (Linux, bash, terminals, X, firefox, vim, etc.). It must be years ago one of those programs crashed while I used it.

Also a segfault IS the protection layer intervening, it is equivalent to a exception in other languages. The real problem is, when there is no segfault.

Re: Show HN: I wrote a Java decompiler in pure C language

#64

Post by johnisgood »

zerr wrote: post #44
johnisgood wrote: post #8

Earlier quoted context omitted.

LLMs can explain the process, and you can build projects with LLMs explaining the process.

It's not about explaining the process but experiencing it.

Well, they can experience it if they wish to. Sadly most vibe-coders do not.

Re: Show HN: I wrote a Java decompiler in pure C language

#65

Post by guerrilla »

1718627440 wrote: post #61
norir wrote: post #59

Earlier quoted context omitted.

Many command line tools do not need memory management at all, at least to first approximation. Free nothing and let the os cleanup on process exit. Most libraries can either use an arena internally and copy any values that get returned to the user to the heap at boundaries or require the user to externally create and destroy the arena. This can be made ergonomic with one macro that injects an arena argument into func…

That might be true, but leaking is neither the critical nor the most hard to find memory management issue, and good luck trying to adapt or even run valgrind with a codebase that mindlessly allocates and leaks everywhere.

Pretty sure you can just disable leak checking.

Re: Show HN: I wrote a Java decompiler in pure C language

#66

Post by 1718627440 »

guerrilla wrote: post #65
1718627440 wrote: post #61

Earlier quoted context omitted.

That might be true, but leaking is neither the critical nor the most hard to find memory management issue, and good luck trying to adapt or even run valgrind with a codebase that mindlessly allocates and leaks everywhere.

Pretty sure you can just disable leak checking.

But for example verifying that memory is not touched after it is supposed to, is much harder when you can't rely on it being freed.

Of course literally running valgrind is still possible, but it is difficult to get useful information.

Re: Show HN: I wrote a Java decompiler in pure C language

#69

Post by uecker »

1718627440 wrote: post #63
uecker wrote: post #58

Earlier quoted context omitted.

Is it? This is my experience with Python. The C/C++ programs I use daily never seem to crash (Linux, bash, terminals, X, firefox, vim, etc.). It must be years ago one of those programs crashed while I used it.

Also a segfault IS the protection layer intervening, it is equivalent to a exception in other languages. The real problem is, when there is no segfault.

This is absolutely true. But even this does not happen in the software I use every day. Software written is C is definitely the most stable I use - by far. That there are people running around claiming that it is impossible to write stable software in C and it crashes all the time due to bugs is rather unfortunate, as it is far from the truth.

Re: Show HN: I wrote a Java decompiler in pure C language

#70

Post by nick__m »

1718627440 wrote: post #66
guerrilla wrote: post #65

Earlier quoted context omitted.

Pretty sure you can just disable leak checking.

But for example verifying that memory is not touched after it is supposed to, is much harder when you can't rely on it being freed. Of course literally running valgrind is still possible, but it is difficult to get useful information.

You cannot have use-after-free if you never call free, so there are no points at which memory should not be touched.

That's the beauty of the never free memory management strategy.

Post reply on HN