use sighandler_t to declare signal handler func pts#13
Conversation
jaltman
force-pushed
the
jaltman/__sighandler_t
branch
from
f988b07 to
5d6ac04
Compare
|
@davidrg Please test this stack on OS2 and NT. There were some conflicting type declarations for OS2. The question is what does the OS2 compiler believe the type of sig_t is. Does the function pointer need to be volatile or not. |
|
This series builds "make macos" without warnings on arm64-apple-darwin24.6.0 with clang 1700.4.4.1. This series builds "make linux" without warnings on Fedora 42 x86_64-redhat-linux-gnu clang 20.1.8-4.fc42 and gcc 15.2.1-3 |
davidrg
left a comment
davidrg
left a comment
There was a problem hiding this comment.
Aside from the OS/2 issue in ckcdeb.h it all looks good. No problems building for windows, and I gave it a 'quick' test on SPARC Solaris 2.3 which is the oldest vintage unix I have handy and it seesms fine there too.
| #ifdef NT | ||
| typedef SIGTYP (*sig_t)(int); | ||
| #else /* !NT */ | ||
| typedef SIGTYP (volatile *sig_t)(int); |
There was a problem hiding this comment.
Open Watcom didn't like this line. Other declarations elsewhere used the form below which Watcom is fine with and I assume work
| typedef SIGTYP (volatile *sig_t)(int); | |
| typedef SIGTYP (* volatile sig_t)(int); |
There was a problem hiding this comment.
Is the use of volatile required? Does it compile on OS2 without warnings if the volatile is removed?
There was a problem hiding this comment.
I don't know if its required or not, only that it was added some time after C-Kermit 5A(190), the last version for which source is available. The same appears in two other places in K95 - one in ckotio.c, and twice in ckuus4.c (one here).
Removing volatile doesn't seem to bother Open Watcom - it builds it without warnings. I'll try to give it a quick test tonight to see if there are any obvious issues with the resulting executable.
|
Debian Trixie doesn't require this change because it ships gcc (Debian 14.2.0-19) 14.2.0 |
|
FYI - Debian builds OK on sid (gcc 15.2.0) also, but only with The origin of that was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1096438 and the build log at http://qa-logs.debian.net/2025/02/16/amd64exp/ckermit_414~beta11-3_unstable_gccexp.log.gz . This is similar to the errors you saw and looks to be part of the C23 compatibility issue. |
Fedora is already shipping gcc 15.2.0 but it does not default to C23. |
|
Sorry, I was saying that CK10 Beta.12 builds on sid but only with -std=gnu17. |
C-Kermit 10 Beta.12 restored the generation of ckcpro.c from ckcpro.w using wermit. As such ckcpro.c should not be committed to the repo and must be included in the .gitignore file.
ckcftp.h was introduced by C-Kermit 10.0 Beta.07 but is not included anywhere and is therefore unnecessary.
This commit is the set of changes which Visual Studio Code applies to each file when it is modified. They are entirely whitespace and conversion to UTF-8 from ISO Latin-1.
'sigtype' is only an alias for SIGTYP. Replace all use of 'sigtype' with 'SIGTYP'.
sig_t should be available wherever signal() is, but there is no harm in redefining a type if the definition has not changed. This change relocates the sig_t typedef to ckcdeb.h from ckcftp.c so it can be used in all C-Kermit source files.
During the development cycle leading up to the C-Kermit 6.0 release the signal handler function pointers were designated 'volatile'. There is no obvious reason for the use of 'volatile' for function pointers which are not shared by multiple threads. One possibility is that the Visual Age compiler used at the time declared signal handler pointer types to be volatile. This is not true for the Open Watcom compiler used to build C-Kermit for OS/2 today. This change removes the 'volatile' designation as a precursor to subsequent change which will consolidate signal handler function pointer type declarations.
If there is a platform for which 'sig_t' is an undeclared type,
then C-Kermit should declare 'sig_t' for that platform.
Declaring stack variables as
SIGTYP (*var)();
is incorrect for a CK_ANSIC build. Replacing all definitions with
#ifdef CK_ANSIC
SIGTYP (*var)(int);
#else
SIGTYP (*var)();
#endif
would work but should be unnecessary when sig_t if available. sig_t
is available anywhere ckcftp.c is built. See discussion regarding
my_sig_t in that source file.
There are several locations where OS2 && !NT assumes that sig_t is a volatile pointer. This change consoliates that assumption into the ckcdeb.h declaration of sig_t. sig_t can then be used to declare all variables used to store signal handler function pointers.
There are no platforms which have support for telnet encryption which have compilers which only support K&R C. This change converts all functions to ANSIC which previously used K&R C. It also removes all 'register' parameter designations because the compilers are better suited to decide how registers should be assigned on modern systems than developers from 30 years ago.
jaltman
force-pushed
the
jaltman/__sighandler_t
branch
from
5d6ac04 to
cefaca0
Compare
|
@jgoerzen Please provide a build log from sid for the current version of this PR. @davidrg I removed 'volatile' as its own change. I also cleaned up the non-ANSIC declarations in ck_crp.c which is built as part of "linux+ssl". The remaining warnings from "linux+ssl" builds on Fedora 42 are deprecation warnings due to use of the old OpenSSL API. |
|
This PR builds "make linux+ssl" on Debian Sid with gcc (Debian 15.2.0-8) 15.2.0 and Debian clang version 19.1.7 (10.1). The only warnings are the OpenSSL 3.0 deprecated-declarations due to use of RSA_new(), RSA_generate_key_ex(), RSA_free(), DH_new(), DH_free(), DH_set0_pqg(), etc. "--std=gnu17" was not used. There are no C23 issues reported. |
OpenSSL 3.0.0 and later offer a different ABI guarantee than prior releases. The ABI guarantees for OpenSSL 3.0 are as follows: * API/ABI Compatibility: API/ABI compatibility is guaranteed for the same MAJOR version number. This means that if an application was built with OpenSSL 3.0.1, it should be able to run with OpenSSL 3.1.0 without modifications, provided that the MAJOR version number remains the same. * Minor Version Changes: A minor version change can introduce new features while preserving the API and ABI. This means that an application built with OpenSSL 3.0.1 can run with OpenSSL 3.1.0 but may not take advantage of new features without modification. * Opaque Structures: Structures that are made opaque in a minor release will require the addition of new accessor macros or functions in a feature release of the extant LTS release and all supported intermediate successor releases. This change defines the COMPAT_VERSION_MASK to be 0xF000000F where the octets are MNNffppS (Major, miNor, fix, patch, Status). The Status octet distinguishes between pre-release and released versions of OpenSSL.
When the NO_OPENSSL_VERSION_CHECK preprocessor symbol is defined the COMPAT_VERSION_MASK is defined as zero which disables the OpenSSL ABI compatibility check.
David Goodwin introduced a comment questioning the rationale for implementing the OPENSSL_VERSION_TEXT comparison check for Kermit 95. This change responds with an explanation of the reasosns why an explicit OpenSSL build was required for Kermit 95.
In the commercial days of Kermit 95, the OS/2 build was staticly linked against the OpenSSL libraries. As such, there could be no version mismatch and hence there was no benefit to performing a run-time check of OpenSSL ABI compatibility. Now that Kermit 95 can be built by anyone and it can be built against a dynamically linked set of libraries, the version check is applicable.
- Replace deprecated X.509 helper usage with safe helpers
- Add `x509_name_oneline_alloc()` and `x509_name_oneline_buf()` to
replace deprecated `X509_NAME_oneline()` by using a memory BIO +
`X509_NAME_print_ex()`.
- Modernize RSA temporary key generation
- `tmp_rsa_cb()` now uses `EVP_PKEY` key generation
(EVP_PKEY_CTX + EVP_PKEY_keygen) when available, falling back to
`RSA_new()`/`RSA_generate_key_ex()` for older OpenSSL versions.
- The one-time 512-bit temporary RSA generation in `ssl_tn_init`
likewise prefers EVP keygen and falls back to legacy RSA APIs.
- For OpenSSL 3+, tmp-RSA callback and raw RSA assignment are
disabled (return NULL / skip installing legacy callbacks) so
providers supply ephemeral keys.
- Add provider-based DH parameter construction for OpenSSL 3
- Implement `dh_from_pg()` using `EVP_PKEY_fromdata()` +
`OSSL_PARAM_construct_octet_string()` for `OSSL_PKEY_PARAM_FFC_P`
and `OSSL_PKEY_PARAM_FFC_G`.
- Extract a `DH *` from the produced `EVP_PKEY` (up-ref) for
compatibility with existing callers.
- Keep legacy `DH_new` / `BN_bin2bn` / `DH_set0_pqg` path for
OpenSSL < 3.0 as a fallback.
- Guard deprecated APIs behind version checks
- All legacy `RSA_*`/`DH_*` usages and tmp-RSA/tmp-DH callbacks
are conditionally compiled so OpenSSL 3 builds avoid deprecated
symbols while older builds retain behavior.
- Small pragmas added to locally suppress deprecation warnings
where extracting `DH*` from an `EVP_PKEY` is necessary for
compatibility.
- Backward-compatible behavior preserved on older OpenSSL versions;
OpenSSL 3 builds use provider-friendly code paths and no longer
compile the deprecated legacy APIs.
This change replaces legacy OpenSSL APIs (deprecated by 3.0) in
`ck_ssl.c` with modern EVP/provider-based approaches where appropriate
and centralize the remaining small compatibility adapters. Legacy
fallbacks are maintained using preprocessor guards so the code remains
buildable with older OpenSSL (1.x) while eliminating direct use of
deprecated accessor/up-ref functions when compiling for OpenSSL 3.x.
- Key changes:
- Refactor: Prefer `EVP_PKEY` for RSA generation and DH parameter
handling.
- Adapters: Added/standardized adapter functions:
- `evp_generate_rsa_key(int bits)` — generate RSA as an
`EVP_PKEY`.
- `evp_pkey_from_dh_bytes(...)` — construct `EVP_PKEY` DH params
(OpenSSL 3 provider path) or wrap legacy `DH`.
- `evp_pkey_get1_rsa(EVP_PKEY *)` / `evp_pkey_get1_dh(EVP_PKEY *)`;
— centralized extraction wrappers; they return owned raw pointers
only for OpenSSL < 3.0, and return NULL on OpenSSL >= 3.0 to avoid
deprecated accessors.
- Removed deprecated calls:
- Eliminated use of `EVP_PKEY_CTX_set_rsa_keygen_pubexp` (rely on
provider default).
- Removed the OpenSSL-3 path that extracted raw `DH*`/`RSA*` from
provider `EVP_PKEY`—adapters return NULL and callers rely on
EVP/provider behavior or legacy guarded paths.
- Guarding:
- All legacy `RSA_*` / `DH_*` usage remains strictly behind
`#if OPENSSL_VERSION_NUMBER < 0x30000000L` guards so OpenSSL 3
builds do not compile deprecated accessors.
- New Headers:
- Add required OpenSSL 3+ headers to ck_ssl.h with appropriate
guard.
With this change the "linux+ssl" build completes and links successfully
when using OpenSSL pre-1.1, 1.1+, and 3.0+ without deprecated-declarations
warnings. Behavior on existing deployments using older OpenSSL remains
unchanged. On OpenSSL 3+, ephemeral keys and provider behavior will be
used rather than legacy temporary-key callbacks.
|
Confirming this build works fine in sid with the patch series ending in df70bf0. Nice! |
|
I've refreshed the jaltman/__sighandler_t branch to include the proposed changes to the OpenSSL Version Check as well as to provide an OpenSSL implementation that doesn't use deprecated functions for 3.0+. This series builds fine for Fedora, Debian sid, and RHEL7. I have tested outgoing connections to https services. I have not tested incoming connections such as those which would be accepted by an IKSD service configured to secure the session using TELNET START_TLS. |
recent gentoo distributions removed functionality from libncurses and moved it to the new libtinfo. This change links wermit to -ltinfo if it can be found. fixes: gh-12
4 participants
Required for both