float.sizeof should be 4

[Jonathan M Davis]

On Tuesday, September 24, 2024 4:49:45 AM MDT Dom DiSc via Digitalmars-d 
wrote:
> On Tuesday, 24 September 2024 at 03:23:31 UTC, Jonathan M Davis
>
> wrote:
> > So, the issue really isn't the value itself. That will convert
> > to other sizes just fine, particularly since it's known at
> > compile time. Rather, what matters is what you get when you do
> > math on it
>
> Doing math most of the time involves at least two values, in this
> case sizeof (of type size_t) and 4 (a nibble).
> It should be clearly defined in what type such an operation
> should result.

As long as sizeof is size_t, then math will give you ulong on 64-bit systems
and uint on 32-bit systems. The main problem with it not being a size_t is
if you're on a 64-bit system and you do math with a 32-bit value. For
instance, it's quite common for folks to just use int by default with many
numbers, but the result of multiplying such a value against a sizeof really
needs to be size_t if you don't want potential overflow issues. If sizeof
defaulted to ubyte just because it's a value that can fit in a ubyte, then
multiplying it against an int would give you an int when what you really
need if you want to avoid bugs is a ulong / size_t, because that's what's
needed to represent larger memory sizes. There would quite easily be
problems with large arrays if the type being used weren't size_t.

And yes, having sizeof be treated as size_t does sometimes get annoying when
you don't actually need the larger values, and you want to do something
other than get a value to use for something other than memory manipulation,
but it means that you get the correct result by default, because you're
guaranteed to be dealing with the correct type for memory sizes. If you then
actually need a smaller type, you can cast to a smaller type. And since
sizeof typically gives a value that fits in a ubyte (and definitely does
with float), and the value is known at compile-time, you can always do
something like

ubyte v = float.sizeof;

if you want to be dealing with a ubyte. D defaults to the size that is the
least likely to result in silent bugs and then allows you to convert to
smaller types if you want to for your particular application.

The entire reason that Steven is running into issues here is because he's
deciding for whatever reason when dealing with raylib to use int for memory
sizes when it's usually the case that the correct thing to do is to use
size_t in order to ensure that you can correctly handle large arrays (and
that can easily come up with stuff like manipulating files given how large
they can get these days).

- Jonathan M Davis