Re: Suggested method for returning a string from a C program?

On 2025-03-20, bart <bc@freeuk.com> wrote:

On 20/03/2025 18:46, Michael S wrote:

On Thu, 20 Mar 2025 15:40:20 +0000
bart <bc@freeuk.com> wrote:
 

>
Pretty much every other open source project I look likes to define
their own types!
>
So I have to ask, why do think they do that?
>

 
Most likely mindless parroting of 40 y.o. examples.
 

>
I don't think so. Where such sets of types exist, they tend to be
defined on top of long long too, or even on top of stdint.h types.
>
Look at this one for example:
>
  typedef uint8_t byte;                    // from arduino.h
>
I can only one of reason this exists, which is that 'byte' is a far
nicer denotation.

That's actually a bad way to define byte. You want

  typedef unsigned char byte;

That's because "unsigned char" is blessed by the language spec with
certain properties that it behooves you to confer onto your "byte".

You can alias an object with an arrays of unsigned char, and
certain things hold, which do not hold if you use uint8_t.
uint8_t is subject to strict aliasing rules.

(Under the hood, an implementation may just have uint8_t as a typedef
for unsigned char, but that's not required.)

You might also consider why such examples existed even 40 years ago.

Mostly it's poor programmers who can't wrap their head around using
a type whose exact size is not known.

If you're not programming hardware or conforming to external storage
or packet formats, you don't need crap like int32 or uint64.

It's an embarrassing blemish on Rust that they made their principal
integer types like this; it makes all Rust code look idiotically
hardware dependent.  You can't code an abstract algorithm out of
Sedgewick, Knuth or Cormen in Rust without peppering the code with
distracting 32's and 64's.



--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca