Skip to content

Conversation

@Insoft-UK
Copy link

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
Copy link
Owner

tchapi commented Apr 19, 2025

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
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
Copy link
Owner

tchapi commented Apr 21, 2025

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