[PR #1495] [FEAT] Port all the `common_*` files, teletext and networking portions of `libccx` to rust

**Original Pull Request:** https://github.com/CCExtractor/ccextractor/pull/1495 **State:** closed **Merged:** No ---  **In raising this pull request, I confirm the following (please check boxes):** - [x] I have read and understood the [contributors guide](https://github.com/CCExtractor/ccextractor/blob/master/.github/CONTRIBUTING.md). - [x] I have checked that another pull request for this purpose does not exist. - [x] I have considered, and confirmed that this submission will be valuable to others. - [x] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [x] I give this submission freely, and claim no ownership to its content. - [ ] **I have mentioned this change in the [changelog](https://github.com/CCExtractor/ccextractor/blob/master/docs/CHANGES.TXT).** **My familiarity with the project is as follows (check one):** - [ ] I have never used CCExtractor. - [ ] I have used CCExtractor just a couple of times. - [ ] I absolutely love CCExtractor, but have not contributed previously. - [x] I am an active contributor to CCExtractor. --- This PR aims to port most of the functions in files `common_*` , `teletext.h`, `telxcc.c`, `networking.c` and certain parts of `utility.c` (such as logging) to rust. Certain parts of the codebase is left blank if they are dependant on some code which this PR has not aimed to convert. Such parts will have to be revisited once their dependencies are also converted to rust. I have placed the new rust code inside a new crate named as `lib_ccxr`, which is a normal rust library crate. This was because a static library crate does not allow doctests. This would also help in seperating ffi code to idiomatic Rust code. Since the Rust approach and C approach to solve a problem are very different, there are 3 layers of indirection I have used for porting: #### 1. The C-FFI layer This layers will have function names same as defined in C but with the prefix of `ccxr_`. These functions will handle the conversion between C-native types and Rust-native types and then pass it on to the C-like Rust layer. These are the functions defined in the `ccx_rust` crate under `libccxr_exports` module. #### 2. The C-like Rust layer This layer will have function names same as defined in C but work with Rust-native types. The code written using these functions would still be procedural but in Rust, hence the name C-like Rust. The entire task of these functions will be to translate the procedural code to idiomatic Rust code. These are the functions defined in the `c_functions.rs` file in appropriate modules inside the `lib_ccxr` crate. #### 3. The Idiomatic Rust layer This layer will be the code written as one is supposed to write in idiomatic Rust. It will have complete documentation and tests. This code will will be situated in the `lib_ccxr` crate.

claunia commented

2026-01-29 17:20:56 +00:00

Owner

Original Pull Request: https://github.com/CCExtractor/ccextractor/pull/1495

State: closed
Merged: No

In raising this pull request, I confirm the following (please check boxes):

I have read and understood the contributors guide.
I have checked that another pull request for this purpose does not exist.
I have considered, and confirmed that this submission will be valuable to others.
I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
I give this submission freely, and claim no ownership to its content.
I have mentioned this change in the changelog.

My familiarity with the project is as follows (check one):

I have never used CCExtractor.
I have used CCExtractor just a couple of times.
I absolutely love CCExtractor, but have not contributed previously.
I am an active contributor to CCExtractor.

This PR aims to port most of the functions in files common_* , teletext.h, telxcc.c, networking.c and certain parts of utility.c (such as logging) to rust. Certain parts of the codebase is left blank if they are dependant on some code which this PR has not aimed to convert. Such parts will have to be revisited once their dependencies are also converted to rust.

I have placed the new rust code inside a new crate named as lib_ccxr, which is a normal rust library crate. This was because a static library crate does not allow doctests. This would also help in seperating ffi code to idiomatic Rust code. Since the Rust approach and C approach to solve a problem are very different, there are 3 layers of indirection I have used for porting:

1. The C-FFI layer

This layers will have function names same as defined in C but with the prefix of ccxr_. These functions will handle the conversion between C-native types and Rust-native types and then pass it on to the C-like Rust layer. These are the functions defined in the ccx_rust crate under libccxr_exports module.

2. The C-like Rust layer

This layer will have function names same as defined in C but work with Rust-native types. The code written using these functions would still be procedural but in Rust, hence the name C-like Rust. The entire task of these functions will be to translate the procedural code to idiomatic Rust code. These are the functions defined in the c_functions.rs file in appropriate modules inside the lib_ccxr crate.

3. The Idiomatic Rust layer

This layer will be the code written as one is supposed to write in idiomatic Rust. It will have complete documentation and tests. This code will will be situated in the lib_ccxr crate.

claunia added the pull-request label 2026-01-29 17:20:56 +00:00

claunia closed this issue

[PR #1495] [FEAT] Port all the common_* files, teletext and networking portions of libccx to rust #2223

1. The C-FFI layer

2. The C-like Rust layer

3. The Idiomatic Rust layer

[PR #1495] [FEAT] Port all the `common_*` files, teletext and networking portions of `libccx` to rust #2223