On Sat, Sep 13, 2025 at 06:53:54PM +0200, Felix Winkelmann wrote:
> On Sat Sep 13, 2025 at 6:32 PM CEST, Diogo wrote:
> > > CRUNCH's "char" is not a byte, it must hold UNICODE code points, which
> > > may be unexpected. Using typename is the proper way to handle this, but
> > > perhaps we should add a new type ("byte") or make "char" 8 bits and
> > > add "wchar_t"? I'm open to suggestions.
> >
> > Ah yes, that makes a lot of sense. Personally, now that I know, I'd be fine
> > with adding byte for 8bits and keeping char as it is.
>
> Ok, I think I'll do that.
Having byte as "native" type would also allow us to use the byte as a normal
integer in procedures/functions:
- in arithmetic and comparisons (+ b 1), (zero? b), (= b1 b2)
- and as index in things like (bytevector-set! V b b)
I tried these usecases with a self-defined byte type via
(define-type byte (typename uint8_t))
and the compiler wasn't happy.
If I am understanding this correctly, at the moment, I'd have to define
a bunch of c-lambdas to manipulate and cast my byte type to integers.
-d
