Ultimate code quality and correctness should be the one direction everyone should converge to unconditionally. 

It is hard enough to write code that works and the “automated tool” you and Mr. Luca seem to be referring to is called “the C++ compiler”, something that everyone writing code uses at some point in the development lifecycle if I’m not mistaken?

Everyone benefits from a compiler made capable of catching more mistakes and the better insights also help developers add runtime checks for conditions that aren’t readily apparent. 

Helping the compiler understand the developer’s intent beyond what can be inferred from the code cannot automated by definition and therefore implies manual annotations. 

Traditional static analyzers cannot infer intent and also don’t help the compiler emit better code. The source annotations enable the compiler to get more insight about the intent and meaning of the code as well as its dynamic behavior and this - by definition - requires more information than what is conveyed from the code alone. 

Suggesting that some traditional static analyzer is “superior without making a mess” is a disingenuous and misinformed statement.

In addition to better compile-time insights imagine for an instant what benefits could be gained from a fully annotated codebase run through AI-based threats and defect modeling from a company investing double digit billions in that technology?

Both GCC and Clang make baby steps in code annotations, so get used to the “unreadable mess” because it’s coming like it or not ;)

Anyway, I’ll leave it there. I get that this is a step of code evolution this project is not willing to make.

#

—Axel

On Oct 25, 2023, at 06:06, Arnaud Loonstra <[email protected]> wrote:



Hi Axel,

I hope you do not take it personal that the PR got rejected. It can be difficult sometimes to align all directions.

Indeed the PR made al lot of changes only to allow an automated tool to do its job. I'm not familiar with SAL myself but I agree with Luca the resulting code is not desirable. Is there anyway SAL can be included as a test without changing all headers? Did you update these headers by hand by the way or is this also automated?

Rg,

Arnaud

On 24/10/2023 19:38, Axel R. wrote:
Yep the PR is up for review. It was indeed a trivial issue, there was a file under packaging/ that needed the new file listed and the Linux builds started working.

I have one more trivial issue where a file locally formatted with clang-format -I --style=file doesn’t pass the formatting test on the online build.

For some reason the local convention appears to mandate spaces before opening parentheses as in MACRO (x) or __attribute (x) which is not aligned with most C and C++ formatting rules of the world, where a space precedes a parenthesis only after language keywords.

The existing code isn’t conforming strictly to the .clang-format file that is checked-in with the project. Some of the existing files change if I run clang-format on them with that formatting file, and spaces get added before some of the few existing parentheses that don’t have one already (e.g. __declspec(dllimport) in zmq.h)

The clang-* build targets created by CMake on Windows fail because they call chmod for some reason, so I suspect a new .clang-format file does not get created? But why is it needed to set write attributes on existing files during builds? And why any build artefact was checked-in (if that is the case that .clang-format is supposed to be generated)

There should not be so much frictions around minor formatting discrepancies. I think this nonstandard spacing policy should be abrogated. 

Put a space before an open parenthesis only in control flow statements, but not in normal function call expressions and function-like macros.” https://llvm.org/docs/CodingStandards.html

This is aligned with most formatting conventions back to the original K&R and I think this project should return to that instead of standing out in a nonstandard way, and the formatting rules file should be checked-in and not generated as it does not work on all platforms today (unless there is a compelling reason to create that file during builds?)

Thoughts?

—Axel


Sent from my iPhone

On Oct 24, 2023, at 04:05, Arnaud Loonstra <[email protected]> wrote:

Seems a trivial problem. Have you created the PR already?

On 22/10/2023 10:04, Axel R. wrote:
Hi, I'm trying to submit a PR, but the Linux builds fail. I added a new include\zmq_sal.h next to include\zmq.h and #included it as "zmq_sal.h" from zmq.h, which builds locally on Windows as well as on Github. However, the Linux builds fails ("../../src/../include/zmq.h:34:10: fatal error: zmq_sal.h: No such file or directory") I tried  #include <zmq_sal.h> to no avail. Any idea? How was zmq_utils.h included?

_______________________________________________
zeromq-dev mailing list
[email protected]
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

_______________________________________________
zeromq-dev mailing list
[email protected]
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

_______________________________________________
zeromq-dev mailing list
[email protected]
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to