Skip to content

Fundamental Type Support#45

Open
Insoft-UK wants to merge 8 commits into
tchapi:masterfrom
Insoft-UK:insoft
Open

Fundamental Type Support#45
Insoft-UK wants to merge 8 commits into
tchapi:masterfrom
Insoft-UK:insoft

Conversation

@Insoft-UK

Copy link
Copy Markdown

Since unsigned char can be used interchangeably with uint8_t, I’ve updated the code to first replace all instances of unsigned char with uint8_t within the extractFont function. This ensures compatibility with both types.

Since unsigned char is a fundamental type and tends to integrate more smoothly with legacy code, I’ve chosen to use unsigned char instead of uint8_t in the Process and Create File section.

@tchapi

tchapi commented Apr 19, 2025

Copy link
Copy Markdown
Owner

Hi @Insoft-UK

I understand the idea, but technically, unsigned char is not guaranteed to be an 8-bit type, while uint8_t is (if available), right? So I'd be inclined to use uint8_t for exporting (what is done already); what legacy code did you encounter where this was posing a problem?

@tchapi tchapi self-assigned this Apr 19, 2025
@Insoft-UK

Copy link
Copy Markdown
Author

I’ve come across some cases where unsigned char is used instead of uint8_t, which is why I included support for it. I understand that char isn’t guaranteed to be exactly one byte, even though it almost always is in practice. That said, I figured you might choose not to include it, since most of the existing .h files already use uint8_t consistently.

@tchapi

tchapi commented Apr 21, 2025

Copy link
Copy Markdown
Owner

Thanks for the context. I'd leave the export with uint8_t for now, but I'm all in favour of the first replace(), if you want to amend the PR 🙏🏼

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants