News for hackers. Stuff that matters.

A comment on Recreating the US/* time zone situation. Parent comment

Re:Recreating the US/* time zone situation by azinman2 on Sunday September 14, 2025 @11:38AM (#45240621)
Looking at that code I’m shocked that Postgres allows two-liner if statements without a matching {} (I’m sure someone pedantically will point out that I’m using the wrong terminology or that it was actually several lines of conditionals).

This practice is very bug prone, and has lead to high profile failures like goto fail

[ Parent | on HN ]
Re:Recreating the US/* time zone situation by yencabulator on Sunday September 14, 2025 @06:08PM (#45243745)
The project history goes back to 1982. There may have been rewrites in the later 80s, but it's some of the oldest C around, and a very conservative codebase (e.g. Linux kernel gets much more aggressive refactorings regularly).

That particular git repository has history imported from 1996 onward, but Postgres was a very established project by then: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...

These days people might not blink an eye at gofmt/rustfmt rewriting the AST to clean it up, but those toolchains were built that way largley because automating anything about large C codebases is so hard.

[ Parent | on HN ]
Re:Recreating the US/* time zone situation by azinman2 on Sunday September 14, 2025 @06:16PM (#45243817)
Except this was new code.
[ Parent | on HN ]
Re:Recreating the US/* time zone situation by yencabulator on Sunday September 14, 2025 @06:23PM (#45243872)
Generally, large C projects have their own style that is followed whether the code is new or not.
[ Parent | on HN ]
Re:Recreating the US/* time zone situation by azinman2 on Sunday September 14, 2025 @07:11PM (#45244249)
And thus it’s surprising to me they haven’t changed their style moving forward when it’s known that this is error prone.
[ Parent | on HN ]
Re:Recreating the US/* time zone situation by yencabulator on Sunday September 14, 2025 @07:31PM (#45244384)
Large stable projects are very much wary of wide-scale changes their codebase. What they have is tested working by decades in production. Especially with C where tooling is brittle.

Let me put this way: If you submit a code prettifying patch to the Linux kernel, it will not be accepted. The risks aren't worth it.

The only real way forward is full migration away from C, for which a better scope is a separate project.

[ Parent | on HN ]
Re:Recreating the US/* time zone situation by machinate on Sunday September 14, 2025 @06:28PM (#45243917)
What issue are you taking with the code? Line breaks in the condition?

Presumably the last if statement in the diff.

[ Parent | on HN ]
Re:Recreating the US/* time zone situation by azinman2 on Sunday September 14, 2025 @07:12PM (#45244257)
There aren’t {} brackets after the if
[ Parent | on HN ]
Re:Recreating the US/* time zone situation by machinate on Sunday September 14, 2025 @07:47PM (#45244514)
Are you saying they should always be present? Or only when the condition takes multiple lines; i.e. do you take issue with the ifs in zone_name_pref too?

Personally I think the indentation does a good enough job here.

[ Parent | on HN ]
Re:Recreating the US/* time zone situation by azinman2 on Monday September 15, 2025 @10:23AM (#45250112)
Yes I’m saying they should always be present. It is known to otherwise be error prone, which is why new c-like languages do not permit this (eg go) nor do many style guides (https://google.github.io/styleguide/cppguide.html#Formatting...)
[ Parent | on HN ]
Re:Recreating the US/* time zone situation by fweimer on Monday September 15, 2025 @04:29AM (#45247405)
These days, there are compiler diagnostics for that. There's also a pgindent tool, which will align the visual presentation of the code with its syntactic structure.
[ Parent | on HN ]