[PR #1185] [IMPROVEMENT] Improve and simplify dprintf implementation #1977

New Issue

claunia · 2026-01-29T17:19:33Z

claunia commented

2026-01-29 17:19:33 +00:00

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

State: closed
Merged: Yes

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.

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

I have used CCExtractor just a couple of times.

It now returns a value like the rest of the printf family. It doesn't
brute force the amount of memory that needs to be allocated.

It also removes a warning.

0a1
> Scanning dependencies of target ccx
60,63d60
< /home/nils/Documents/codein2019/ccextractor/src/lib_ccx/ccx_common_common.c: In function ‘fdprintf’:
< /home/nils/Documents/codein2019/ccextractor/src/lib_ccx/ccx_common_common.c:27:4: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
<    27 |    write(fd, p, n);
<       |    ^~~~~~~~~~~~~~~
69c66
<     inlined from ‘add_cc_sub_text’ at /home/nils/Documents/codein2019/ccextractor/src/lib_ccx/ccx_common_common.c:95:3:
---
>     inlined from ‘add_cc_sub_text’ at /home/nils/Documents/codein2019/ccextractor/src/lib_ccx/ccx_common_common.c:73:3:

I do not believe there should be any performance concerns with this
implementation as it is what glibc does (if anything it probably improves performance by a lot):

https://code.woboq.org/userspace/glibc/libio/iovdprintf.c.html

**Original Pull Request:** https://github.com/CCExtractor/ccextractor/pull/1185 **State:** closed **Merged:** Yes --- **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. **My familiarity with the project is as follows (check one):** - [X] I have used CCExtractor just a couple of times. --- It now returns a value like the rest of the printf family. It doesn't brute force the amount of memory that needs to be allocated. It also removes a warning. ```patch 0a1 > Scanning dependencies of target ccx 60,63d60 < /home/nils/Documents/codein2019/ccextractor/src/lib_ccx/ccx_common_common.c: In function ‘fdprintf’: < /home/nils/Documents/codein2019/ccextractor/src/lib_ccx/ccx_common_common.c:27:4: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] < 27 | write(fd, p, n); < | ^~~~~~~~~~~~~~~ 69c66 < inlined from ‘add_cc_sub_text’ at /home/nils/Documents/codein2019/ccextractor/src/lib_ccx/ccx_common_common.c:95:3: --- > inlined from ‘add_cc_sub_text’ at /home/nils/Documents/codein2019/ccextractor/src/lib_ccx/ccx_common_common.c:73:3: ``` I do not believe there should be any performance concerns with this implementation as it is what `glibc` does (if anything it probably improves performance by a lot): https://code.woboq.org/userspace/glibc/libio/iovdprintf.c.html

claunia added the pull-request label 2026-01-29 17:19:33 +00:00

claunia closed this issue

2026-01-29 17:19:33 +00:00

claunia referenced this issue

2026-01-29 17:23:51 +00:00

[PR #1978] [MERGED] Add support for raw CDP (Caption Distribution Packet) files #2778

claunia referenced this issue

2026-01-29 17:23:52 +00:00

[PR #1977] [MERGED] Fix MXF files containing CEA-708 captions not being detected/extracted #2782

claunia referenced this issue

2026-01-29 17:23:53 +00:00

[PR #1977] Fix MXF files containing CEA-708 captions not being detected/extracted #2786