Fix signal handler

[elfring]

The function “longjmp” does not belong to the list of async-signal-safe functions.
I guess that a different program design will be needed for your function “fpe_trap”.

[n-t-roff]

For new source code this is correct. But this is *very * old code which I'd like to change with good reason only. The sendmail issue does not apply here. Do you see an actual security issue? Anyway quality pull requests would be wellcome.

[elfring]

Would you like to consider other software design options?

• sigwaitinfo()
• Self-pipe trick
• Signal-safe locks

[Arumes]

@n-t-roff do you think these (this one and #4) 6 year old issues should remain open? You asked for actual security issues which (as far as I can tell) the OP failed to provide. Do we need to implement more of the suggested changes?

[elfring]

💭 Would you become interested to use a development tool like “clang-tidy” for corresponding source code adjustments?

[Arumes]

💭 Would you become interested to use a development tool like “clang-tidy” for corresponding source code adjustments?

What triggered you to drop another link minutes after my post, after 6 years of silence? It almost seems like bot behaviour.

What is your actual purpose here beside link drops?

[elfring]

What is your actual purpose here beside link drops?

🔮 I hope that referenced information sources can influence development interests in desirable directions.
Can design options be better clarified accordingly?

[Arumes]

Desirable by who? There's tons and tons of webpages with programming tutorials, standards and best practices. Does dropping those (potentially thousands of) links around really help the users or developers of a project? Of this particular project?

[elfring]

Desirable by who?

Software users tend to prefer programs with less programming mistakes, don't they? 🤔

Does dropping those (potentially thousands of) links around really help the users or developers of a project?

🔮 There are chances that corresponding advices can trigger further improvements.

[Arumes]

Desirable by who?

Software users tend to prefer programs with less programming mistakes, don't they? 🤔

Sure, we all want A Better World™. But that's not what I asked. Non-compliance is not always a mistake. You talk about "desirable directions." When the longjmp() in this particular code causes no issues*, then who are you to judge if it's a mistake? How does a rewrite of fpe_trap actually help the software users you're so concerned with if the current version doesn't cause any issues? If a rewrite doesn't change their experience one bit, then why bother? So who are the people that actually desire the direction you're advising this project to go?

*Remember n-t-roff asked you specifically if you saw an actual security issue, and you didn't even bother to reply. Except with another link drop. Even a "no, I don't see one" would be more helpful (and a lot friendlier!) than simply ignoring the question.

Does dropping those (potentially thousands of) links around really help the users or developers of a project?

🔮 There are chances that corresponding advices can trigger further improvements.

And there are chances, as you can see, that your endless link drops cause irritation and adversity. And when you finally do have something interesting to contribute, somthing that really improves the user experience, nobody listens anymore. (Ofcourse I'm exaggerating here, I haven't reached that point at all yet).

[elfring]

When the longjmp() in this particular code causes no issues*,

Please reconsider such a view a bit more.

then who are you to judge if it's a mistake?

I dare to point remaining open issues out as an experienced developer and software reviewer.
👀 Several analysis tools can present corresponding improvement opportunities in similar ways.

How does a rewrite of fpe_trap actually help the software users you're so concerned with if the current version doesn't cause any issues?

Undesirable risks can be avoided also according to undefined behaviour.

And there are chances, as you can see, that your endless link drops cause irritation and adversity.

Do you try to overlook available information anyhow?

[Arumes]

When the longjmp() in this particular code causes no issues*,

Please reconsider such a view a bit more.

Again, you're not helping with such a text in any way. Note the asterisk pointing to a text explaining that you had your chance to provide a single, actual issue with longjmp() in this project, and that you failed.

then who are you to judge if it's a mistake?

I dare to point remaining open issues out as an experienced developer and software reviewer. 👀
Several analysis tools can present corresponding improvement opportunities in similar ways.

"Dare"? Is there any bravery involved then? Pointing out "mistakes" by others is the easiest part in any profession. That's why static analysis tools have been around for about 50 years now and are so widespread nowadays. You're doing the easy part, and when questions are asked you stay quiet.

How does a rewrite of fpe_trap actually help the software users you're so concerned with if the current version doesn't cause any issues?

Undesirable risks can be avoided also according to undefined behaviour.

A general answer to a specific question. Where does the undefined behaviour pose a risk in this project? You got asked that same question 6 years ago, and haven't answered it yet. This is not software development in general. It's not a modern project that needs to comply with modern standards. This is sc. A 40 year old spreadsheet kept in the air by maintainers who are themselves not intimate with the code and who are chronically short on time. For such an old and sparsely used piece of software, it's more curating than developing. It's more like maintaining a classic car than designing a new one.

So again, your link drops are not helpful. Even with my limited C knowledge I am capable of googling standards and SA tools, and dropping links here. But I don't. As long as sc works, it's fine. There's no use in putting more work on the maintainer's plate, unless it's something like the well-spotted #21 which causes real issues for users now.

Where will it end anyway? Nowadays writing user applications in C is considered an unneccessary risk in general. Instead of pointing out every hypothetical mistake, you might just advise the maintainer to rewrite sc in a higher level language and move on.

And there are chances, as you can see, that your endless link drops cause irritation and adversity.

Do you try to overlook available information anyhow?

Yes, I actively try to overlook as much available information as possible. Except for RFC 1855, but you're not making it easy for me to comply with it.

[elfring]

…, and that you failed.

💭 It seems that provided information does not fit to your temporary change interests so far.

You're doing the easy part,

Maybe.

and when questions are asked you stay quiet.

🔮 It might take another while until the running clarification will trigger more adjustments.

Where does the undefined behaviour pose a risk in this project?

👀 Improvable signal handling (as reported).

[n-t-roff]

@Arumes I had problems to lock in after GitHub changed to 2FA. You are completely right. It looks like a bot and this issue should be closed. Thank you.

[elfring]

It looks like a bot …

🔮 Views can become more constructive with the help of additional communication tools, can't they?