News for hackers. Stuff that matters.
Re:Show HN: My C compiler compiled itself by keyvank on Wednesday December 04, 2024 @05:37AM (#42316225)
thanks man!

yes that makes sense. unfortunately 30cc is not able to compile that syntax, and will probably give type-checker errors when passing a void* to pointer of another type. but will implement it sometime soon!

Re:Show HN: My C compiler compiled itself by unwind on Wednesday December 04, 2024 @05:41AM (#42316253)
Aha, so it doesn't know about void* being compatible with all (object) pointers, but so far just requires the pointers to match exactly? I see.

Not sure why I was down-voted, I think that is ... not nice. :(

Re:Show HN: My C compiler compiled itself by nar001 on Wednesday December 04, 2024 @08:35AM (#42317280)
I don't think you can be downvoted, there's no downvote button
Re:Show HN: My C compiler compiled itself by hollerith on Wednesday December 04, 2024 @08:46AM (#42317366)
Users with enough karma can downvote comments.
Re:Show HN: My C compiler compiled itself by quuxplusone on Wednesday December 04, 2024 @05:12PM (#42322610)
A beautiful example of Cunningham's Law! :)
Re:Show HN: My C compiler compiled itself by dataflow on Wednesday December 04, 2024 @08:45AM (#42317354)
I downvoted just because I thought it wasn't great advice. It makes the code incompatible with C++ compilers, and being able to compile C with C++ compiler is often useful.

Also... it felt kind of... unnecessary? to tell someone who is making a compiler how to write basic code in the language they're writing a compiler for. It almost felt like telling an overweight medical student/doctor that he should avoid eating fatty foods.

Re:Show HN: My C compiler compiled itself by Gibbon1 on Thursday December 05, 2024 @04:46AM (#42326562)
Writing C code so won't compile with a C++ compiler is gods work.

Because C++ is why C can't have nice things.

Re:Show HN: My C compiler compiled itself by KerrAvon on Wednesday December 04, 2024 @12:15PM (#42319575)
I disagree with that advice, FWIW -- (void *) is the cause of a lot of bugs in C programs, and much stricter type checking was often the norm for compilers like CodeWarrior on platforms like classic Mac OS, where (a) if you got something wrong you'd corrupt app memory at best and the filesystem at worst and (b) many developers were used to Pascal, which was stricter. (Moving to GCC on Mac OS X and unexpectedly getting much more lenient type checking was a big surprise.)
Re:Show HN: My C compiler compiled itself by munch117 on Wednesday December 04, 2024 @12:28PM (#42319715)
But adding the cast doesn't make type checking stricter, quite the opposite - it destroys any hope of the compiler checking the assignment.

C++ shot itself in the foot by removing automatic conversion from void* to T*, because it forces programmers to add casts that weaken type safety.

Re:Show HN: My C compiler compiled itself by cataphract on Wednesday December 04, 2024 @12:48PM (#42319937)
It doesn't make it any safer because the cast is unchecked. It could be argued it's discouraged[1] for a reason that doesn't really apply to modern C versions where implicit-int isn't allowed anymore.

But while the cast is a matter of style (or C++ compatibility), sizeof(*ret) is definitely superior to sizeof(thing_t). The reason is that people sometimes change the type of ret but forget the change the size of the allocation, especially if ret is assigned to on a different line it's declared.

[1]: https://c-faq.com/malloc/mallocnocast.html

Re:Show HN: My C compiler compiled itself by KerrAvon on Wednesday December 04, 2024 @12:19PM (#42319611)
If you're implementing C23 compatibility, you could do

  auto p = (thing_t *)malloc(sizeof(thing_t));
and you get both DRY and avoid (void *) casting.
Re:Show HN: My C compiler compiled itself by dcuthbertson on Wednesday December 04, 2024 @02:08PM (#42320834)
> and you get both DRY and avoid (void *) casting.

While that line of code is DRY, it doesn't avoid casting "void *" to "thing_t *".