David Brown <david.brown@hesbynett.no> wrote:
> So extensions to C are undefined behaviour in respect to the C standard,
> but defined behaviour in respect to the implementation. As far as the
> standard is concerned, and therefore for the C language in general,
> signed integer overflow is undefined behaviour. However, if you are
> coding for "gcc -fwrapv", then the behaviour is fully defined by the
> implementation.

Right, and that is precisely what I did not realize before. My
simplistic "understanding" was that UB is always something that
will produce results that are, well, not guaranteed to be one
way or the other.

Relaying on Implementation Defined behaviour can of course
be perfectly acceptable as long as you do it consciously and
document it somehow.

br,
KK

David Brown <david.brown@hesbynett.no> writes:
>On 14/07/2023 23:35, Kalevi Kolttonen wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>> If you don't qualify "portable" somehow, like by listing the kinds
>>> of platforms supported, then it means maximally portable.
>>
>> I see. Is the meaning more formally defined somewhere in an
>> exact way? Or is it just common knowledge?
>>
>> My programming skills are so poor that I am 100% convinced I
>> could not write maximally portable C code. I have too many
>> incorrect assumptions and would be sure to rely on e.g. some
>> Implementation Defined behavior. This is no joke but that's
>> just the way it is. I do not blame C for this - it is entirely
>> my fault.
>>
>>> You open yourself to being roasted for the code assuming ASCII,
>>> 8 bit chars, pointers being all equal sized and all that.
>
>These things should not be a problem. Keep your pointers as pointers of
>compatible type - there is rarely a good reason for wanting to convert a
>pointer-to-int to a pointer-to-float, and certainly not for mixing data
>pointers and function pointers. Think about what your pointers are
>pointing at, and use that as the basis for types. And if you ever think
>you need to mess with pointer types, you are probably better using
>memcpy/memmove.
>
>Use "char" to hold characters, and never use it for anything else, then
>its size doesn't matter, nor does the character encoding.

The one gotcha in that is that getch() et al return an int, so they
can represent EOF.

On 15/07/2023 14:29, Kalevi Kolttonen wrote:
> Paul N <gw7rib@aol.com> wrote:
>> I think you could get such a bug if you assume that
>> the letters of the alphabet all have consecutive values.
>> It's true of many computers today, but was not true of
>> the mainframe when I was at university, which used
>> EBCDIC instead of ASCII. As I understand it, this is
>> not "Implementation Defined behaviour" because there is
>> no requirement to say what values the letters have.
>
> I see, thanks. That would satisfy the requirements I gave.
>
> However, saying "just like other bugs" somehow seems to
> give the impression that there would be many bugs that
> could satisfy the requirements.
>
> Finding a single example is a very good thing, but it
> would be more convincing if there were more examples.
>

A "bug" is just code not doing what you want it to do. Some kinds of
bugs have classifications like "integer overflow" that are clearly
"undefined behaviour" in C standard terms. They may or may not be
undefined behaviour for a given C implementation, and can behave
differently between implementations. Some are coding bugs that are not
C UB - maybe you have a pointer to an int, but sometimes it points to
the wrong int. And some are specification bugs.

So if you have a specification that says "make the file path by
concatenating the directory name and file name with a backslash
character", you have a specification bug that affects *nix systems but
not Windows systems - and no C language UB in sight.

Or to give you a different example, one embedded development tool I used
(long ago) worked fine on my older computers, then crashed on newer
ones. It turned out that a timing loop overflowed (or had a divide by
zero - I forget which) on processors faster than about 200 MHz. There
was no UB in the code when running on older systems, but it failed on
newer ones.

Any time you have UB in your code - general UB, meaning the behaviour is
not defined anywhere - you don't know what will happen. The C standard
did attempt to distinguish between "bounded undefined behaviour" and
"critical undefined behaviour", but since "bounded undefined behaviour"
can have knock-on effects leading to "critical undefined behaviour", the
distinction is moot. The result could be all kinds of odd things - and
one of the possibilities is always "it works as expected".

The software world is full of examples of "it worked when /I/ tested it"
bugs. Some of these will be caused by C standard UB bugs, but others
are bugs that do not have any UB at the C level.

How you pick your examples of bugs that are not "UB" will depend on
exactly what you are meaning by "UB" at the time - IMHO, the most
general definition of "UB" is synonymous with a "bug" because the code
is doing something other than what was defined in the specification for
the code.

On 15/07/2023 14:55, Kalevi Kolttonen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> So extensions to C are undefined behaviour in respect to the C standard,
>> but defined behaviour in respect to the implementation. As far as the
>> standard is concerned, and therefore for the C language in general,
>> signed integer overflow is undefined behaviour. However, if you are
>> coding for "gcc -fwrapv", then the behaviour is fully defined by the
>> implementation.
>
> Right, and that is precisely what I did not realize before. My
> simplistic "understanding" was that UB is always something that
> will produce results that are, well, not guaranteed to be one
> way or the other.

That definition is correct. The only question is about where the
guarantees come from. The C standard may not guarantee what happens if
you try to dereference a null pointer, but perhaps the OS you are
running on does - then it is UB as far as the C standard is concerned,
but not UB for your target platform. (A compiler for that OS may still
view it as UB for error checking and/or optimisation purposes even if
the OS defines the behaviour.)

>
> Relaying on Implementation Defined behaviour can of course
> be perfectly acceptable as long as you do it consciously and
> document it somehow.
>

Yes.

Often the requirement documentation can be implicit, if it is reasonable
enough. For example, if you want to have an 8-bit unsigned integer,
just use the type "uint8_t" - the code will fail to compile if used on
an implementation that does not have 8-bit types. But if you have some
needs that are less common, make them explicit - and, if possible, have
compile-time checks (static assertions or pre-processor checks).

David Brown <david.brown@hesbynett.no> wrote:
> On 15/07/2023 14:55, Kalevi Kolttonen wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> So extensions to C are undefined behaviour in respect to the C standard,
>>> but defined behaviour in respect to the implementation. As far as the
>>> standard is concerned, and therefore for the C language in general,
>>> signed integer overflow is undefined behaviour. However, if you are
>>> coding for "gcc -fwrapv", then the behaviour is fully defined by the
>>> implementation.
>>
>> Right, and that is precisely what I did not realize before. My
>> simplistic "understanding" was that UB is always something that
>> will produce results that are, well, not guaranteed to be one
>> way or the other.
>
> That definition is correct. The only question is about where the
> guarantees come from. The C standard may not guarantee what happens if
> you try to dereference a null pointer, but perhaps the OS you are
> running on does - then it is UB as far as the C standard is concerned,
> but not UB for your target platform. (A compiler for that OS may still
> view it as UB for error checking and/or optimisation purposes even if
> the OS defines the behaviour.)

Yes, it is correct but *only if* you limit to what the C
standard says, but like you and others have said, if the
implementation cares about the issue, and provides some
kind of defined behavior, then my previous understanding
was wrong.

In other words, I did not know that the implementations
can "override" UB (i.e. UB according to C stardard) and
turn it into Implementation Defined behavior.

That kind of ignorance is not something to be proud of.

br,
KK

On 15/07/2023 19:28, Kalevi Kolttonen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 15/07/2023 14:55, Kalevi Kolttonen wrote:
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> So extensions to C are undefined behaviour in respect to the C standard,
>>>> but defined behaviour in respect to the implementation. As far as the
>>>> standard is concerned, and therefore for the C language in general,
>>>> signed integer overflow is undefined behaviour. However, if you are
>>>> coding for "gcc -fwrapv", then the behaviour is fully defined by the
>>>> implementation.
>>>
>>> Right, and that is precisely what I did not realize before. My
>>> simplistic "understanding" was that UB is always something that
>>> will produce results that are, well, not guaranteed to be one
>>> way or the other.
>>
>> That definition is correct. The only question is about where the
>> guarantees come from. The C standard may not guarantee what happens if
>> you try to dereference a null pointer, but perhaps the OS you are
>> running on does - then it is UB as far as the C standard is concerned,
>> but not UB for your target platform. (A compiler for that OS may still
>> view it as UB for error checking and/or optimisation purposes even if
>> the OS defines the behaviour.)
>
> Yes, it is correct but *only if* you limit to what the C
> standard says,

No - you are missing the point.

If you are using "undefined behaviour" in the strict sense of the C
standards, then anything not defined by the C standards is UB, and if
you try to execute code that has UB, the standards do not give you any
guarantees about what might happen.

If you are using the term in a more general sense and considering
behaviours defined and guaranteed by the implementation, target, or
other documents, then you can safely and confidently execute code that
is defined by the implementation even if it is not defined by the C
standards. But anything whose behaviour is not defined by the
implementation and relevant documents, has no guarantee about its behaviour.

It's the same thing - it is merely a question of how specific and
detailed you want to be, and how restrictive you can be about the choice
of compiler and implementation.

> but like you and others have said, if the
> implementation cares about the issue,

(Note this is not an "issue" to care about - UB in a language is a good
thing, as long as you understand it and avoid trying to execute it.
Many languages gloss over UB and pretend they define everything, but
they don't - and often they give pointless and counter-productive
definitions to meaningless code simply so that they can claim to have no
UB. UB is really just "garbage in, garbage out".)

> and provides some
> kind of defined behavior, then my previous understanding
> was wrong.
>
> In other words, I did not know that the implementations
> can "override" UB (i.e. UB according to C stardard) and
> turn it into Implementation Defined behavior.
>

They can't turn it into "implementation-defined behaviour" - that has a
specific meaning in C terms. It means behaviour that the C standards
say can vary between implementations, but which the implementation must
document. Examples include the size of "int" and the character sets.

But anything that the C standard does not define, can be defined by an
implementation - the C standards say nothing about such things and do
not require them to be "wrong". (This is different from things like
"constraints" and syntax errors - compilers are obliged to follow these
in conforming modes. So a conforming compiler cannot have a "long long
long int" type, or implement a "%" operator on string literals. It can
do so in non-conforming modes, of course, where the compiler is free to
do anything it likes.)

> That kind of ignorance is not something to be proud of.
>

Ignorance is seldom something to be proud of - but it is not something
to be ashamed of either. You fix it by learning. And they say the
quickest way to get good answers on the internet is not to ask
questions, but to post the wrong answers - it has worked for me on many
occasions!

David Brown <david.brown@hesbynett.no> wrote:
> They can't turn it into "implementation-defined behaviour" - that has a
> specific meaning in C terms. It means behaviour that the C standards
> say can vary between implementations, but which the implementation must
> document. Examples include the size of "int" and the character sets.

Thanks, yes, I used the wrong term.

> But anything that the C standard does not define, can be defined by an
> implementation -

I guess there is no existing term for that.

> Ignorance is seldom something to be proud of - but it is not something
> to be ashamed of either. You fix it by learning. And they say the
> quickest way to get good answers on the internet is not to ask
> questions, but to post the wrong answers - it has worked for me on many
> occasions!

That is true, but it is also the responsibility of all C
programmers to know the fundamental principles governing
how to use the C language properly.

I can tell you that it is not a great feeling to realize that
you have misunderstood something pretty fundamental for several
years.

br,
KK

scott@slp53.sl.home (Scott Lurndal) writes:
> David Brown <david.brown@hesbynett.no> writes:
[...]
>>Use "char" to hold characters, and never use it for anything else, then
>>its size doesn't matter, nor does the character encoding.
>
> The one gotcha in that is that getch() et al return an int, so they
> can represent EOF.

There is no getch() in standard C. There are functions of that name in
the obsolete <conio.h> and in [n]curses. You're thinking of getc(),
fgetc(), and getchar().

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

David Brown <david.brown@hesbynett.no> writes:
> On 14/07/2023 23:35, Kalevi Kolttonen wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
[...]
>>> You open yourself to being roasted for the code assuming ASCII,
>>> 8 bit chars, pointers being all equal sized and all that.
>
> These things should not be a problem. Keep your pointers as pointers
> of compatible type - there is rarely a good reason for wanting to
> convert a pointer-to-int to a pointer-to-float, and certainly not for
> mixing data pointers and function pointers. Think about what your
> pointers are pointing at, and use that as the basis for types. And if
> you ever think you need to mess with pointer types, you are probably
> better using memcpy/memmove.

Agreed -- but you can convert pointers without assuming that they're the
same size. For example, if void* is bigger than int*, a conversion from
int* to void* will still work correctly.

Converting between int* and float*, for example tends to be for the
purpose of aliasing int and float objects, and that's rarely useful
(particularly since int and float are not guaranteed to have the same
size).

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 16/07/2023 01:02, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 14/07/2023 23:35, Kalevi Kolttonen wrote:
>>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> [...]
>>>> You open yourself to being roasted for the code assuming ASCII,
>>>> 8 bit chars, pointers being all equal sized and all that.
>>
>> These things should not be a problem. Keep your pointers as pointers
>> of compatible type - there is rarely a good reason for wanting to
>> convert a pointer-to-int to a pointer-to-float, and certainly not for
>> mixing data pointers and function pointers. Think about what your
>> pointers are pointing at, and use that as the basis for types. And if
>> you ever think you need to mess with pointer types, you are probably
>> better using memcpy/memmove.
>
> Agreed -- but you can convert pointers without assuming that they're the
> same size. For example, if void* is bigger than int*, a conversion from
> int* to void* will still work correctly.
>

Yes, you can covert any data pointer to void*. But you have to convert
it back to pointer compatible to the original data before dereferencing
it - you can't expect "int x; float f = *(float *)(void *) &x;" to do
anything sensible. And it's also important to remember that void* is
not suitable for converting function pointers.

> Converting between int* and float*, for example tends to be for the
> purpose of aliasing int and float objects, and that's rarely useful
> (particularly since int and float are not guaranteed to have the same
> size).
>

Of course - you usually want a union if you need to alias different types.

On Sunday, 16 July 2023 at 00:03:08 UTC+1, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
> > On 14/07/2023 23:35, Kalevi Kolttonen wrote:
> >> Kaz Kylheku <864-11...@kylheku.com> wrote:
> [...]
> >>> You open yourself to being roasted for the code assuming ASCII,
> >>> 8 bit chars, pointers being all equal sized and all that.
> >
> > These things should not be a problem. Keep your pointers as pointers
> > of compatible type - there is rarely a good reason for wanting to
> > convert a pointer-to-int to a pointer-to-float, and certainly not for
> > mixing data pointers and function pointers. Think about what your
> > pointers are pointing at, and use that as the basis for types. And if
> > you ever think you need to mess with pointer types, you are probably
> > better using memcpy/memmove.
> Agreed -- but you can convert pointers without assuming that they're the
> same size. For example, if void* is bigger than int*, a conversion from
> int* to void* will still work correctly.
>
> Converting between int* and float*, for example tends to be for the
> purpose of aliasing int and float objects, and that's rarely useful
> (particularly since int and float are not guaranteed to have the same
> size).
>
It's a hacky, low level thing to do. And of course it's unlikely to be portable
to platforms on which int and float are of different sizes. And probably
not portable to platforms which don't use the particular float representation,
since the likely motive is to get access to the bits of the float directly. But
part of the power of C is that you can do these things if you wish, or if there
is some actual requirement for some reason.

On 16/07/2023 01:25, Malcolm McLean wrote:
> On Sunday, 16 July 2023 at 00:03:08 UTC+1, Keith Thompson wrote:
>> David Brown <david...@hesbynett.no> writes:
>>> On 14/07/2023 23:35, Kalevi Kolttonen wrote:
>>>> Kaz Kylheku <864-11...@kylheku.com> wrote:
>> [...]
>>>>> You open yourself to being roasted for the code assuming ASCII,
>>>>> 8 bit chars, pointers being all equal sized and all that.
>>>
>>> These things should not be a problem. Keep your pointers as pointers
>>> of compatible type - there is rarely a good reason for wanting to
>>> convert a pointer-to-int to a pointer-to-float, and certainly not for
>>> mixing data pointers and function pointers. Think about what your
>>> pointers are pointing at, and use that as the basis for types. And if
>>> you ever think you need to mess with pointer types, you are probably
>>> better using memcpy/memmove.
>> Agreed -- but you can convert pointers without assuming that they're the
>> same size. For example, if void* is bigger than int*, a conversion from
>> int* to void* will still work correctly.
>>
>> Converting between int* and float*, for example tends to be for the
>> purpose of aliasing int and float objects, and that's rarely useful
>> (particularly since int and float are not guaranteed to have the same
>> size).
>>
> It's a hacky, low level thing to do. And of course it's unlikely to be portable
> to platforms on which int and float are of different sizes. And probably
> not portable to platforms which don't use the particular float representation,
> since the likely motive is to get access to the bits of the float directly. But
> part of the power of C is that you can do these things if you wish, or if there
> is some actual requirement for some reason.

No, you /can't/ do that. It is a stupid thing to do, and you do people
a disservice by suggesting it is sometimes appropriate. Of course there
can be occasions where it is useful to see "inside" a floating point
value - /someone/ has to write software floating point libraries for
processors that can't handle them in hardware. But hopefully the people
that need to do that know more about C than you do, and are do it
safely, correctly, and efficiently instead of blind dangerous hacks that
are /not/ guaranteed to work in any useful fashion, even if "float" and
"int" are the same size on the target.

C lets you do all kinds of things - including lots of non-portable
things (it is intended to be usable as a systems programming language as
well as a portable applications programming language). But if you try
to place smartarse tricks, you need to know /exactly/ what you are doing.

On Sunday, 16 July 2023 at 10:07:56 UTC+1, David Brown wrote:
> On 16/07/2023 01:25, Malcolm McLean wrote:
> > On Sunday, 16 July 2023 at 00:03:08 UTC+1, Keith Thompson wrote:
> >> David Brown <david...@hesbynett.no> writes:
> >>> On 14/07/2023 23:35, Kalevi Kolttonen wrote:
> >>>> Kaz Kylheku <864-11...@kylheku.com> wrote:
> >> [...]
> >>>>> You open yourself to being roasted for the code assuming ASCII,
> >>>>> 8 bit chars, pointers being all equal sized and all that.
> >>>
> >>> These things should not be a problem. Keep your pointers as pointers
> >>> of compatible type - there is rarely a good reason for wanting to
> >>> convert a pointer-to-int to a pointer-to-float, and certainly not for
> >>> mixing data pointers and function pointers. Think about what your
> >>> pointers are pointing at, and use that as the basis for types. And if
> >>> you ever think you need to mess with pointer types, you are probably
> >>> better using memcpy/memmove.
> >> Agreed -- but you can convert pointers without assuming that they're the
> >> same size. For example, if void* is bigger than int*, a conversion from
> >> int* to void* will still work correctly.
> >>
> >> Converting between int* and float*, for example tends to be for the
> >> purpose of aliasing int and float objects, and that's rarely useful
> >> (particularly since int and float are not guaranteed to have the same
> >> size).
> >>
> > It's a hacky, low level thing to do. And of course it's unlikely to be portable
> > to platforms on which int and float are of different sizes. And probably
> > not portable to platforms which don't use the particular float representation,
> > since the likely motive is to get access to the bits of the float directly. But
> > part of the power of C is that you can do these things if you wish, or if there
> > is some actual requirement for some reason.
> No, you /can't/ do that. It is a stupid thing to do, and you do people
> a disservice by suggesting it is sometimes appropriate. Of course there
> can be occasions where it is useful to see "inside" a floating point
> value - /someone/ has to write software floating point libraries for
> processors that can't handle them in hardware. But hopefully the people
> that need to do that know more about C than you do, and are do it
> safely, correctly, and efficiently instead of blind dangerous hacks that
> are /not/ guaranteed to work in any useful fashion, even if "float" and
> "int" are the same size on the target.
>
> C lets you do all kinds of things - including lots of non-portable
> things (it is intended to be usable as a systems programming language as
> well as a portable applications programming language). But if you try
> to place smartarse tricks, you need to know /exactly/ what you are doing.
>
No. C doesn't provide facilities for what you are suggesting. That doesn't mean that
you can't write bitwise operations on floats in C, without resorting to assembler.
But you can't do so "safely, correctly, efficiently" instead of "blind dangerous hacks".
And of course I do know how floating point arithmetic works and what I am doing.

On 16/07/2023 14:42, Malcolm McLean wrote:
> On Sunday, 16 July 2023 at 10:07:56 UTC+1, David Brown wrote:
>> On 16/07/2023 01:25, Malcolm McLean wrote:
>>> On Sunday, 16 July 2023 at 00:03:08 UTC+1, Keith Thompson wrote:
>>>> David Brown <david...@hesbynett.no> writes:
>>>>> On 14/07/2023 23:35, Kalevi Kolttonen wrote:
>>>>>> Kaz Kylheku <864-11...@kylheku.com> wrote:
>>>> [...]
>>>>>>> You open yourself to being roasted for the code assuming ASCII,
>>>>>>> 8 bit chars, pointers being all equal sized and all that.
>>>>>
>>>>> These things should not be a problem. Keep your pointers as pointers
>>>>> of compatible type - there is rarely a good reason for wanting to
>>>>> convert a pointer-to-int to a pointer-to-float, and certainly not for
>>>>> mixing data pointers and function pointers. Think about what your
>>>>> pointers are pointing at, and use that as the basis for types. And if
>>>>> you ever think you need to mess with pointer types, you are probably
>>>>> better using memcpy/memmove.
>>>> Agreed -- but you can convert pointers without assuming that they're the
>>>> same size. For example, if void* is bigger than int*, a conversion from
>>>> int* to void* will still work correctly.
>>>>
>>>> Converting between int* and float*, for example tends to be for the
>>>> purpose of aliasing int and float objects, and that's rarely useful
>>>> (particularly since int and float are not guaranteed to have the same
>>>> size).
>>>>
>>> It's a hacky, low level thing to do. And of course it's unlikely to be portable
>>> to platforms on which int and float are of different sizes. And probably
>>> not portable to platforms which don't use the particular float representation,
>>> since the likely motive is to get access to the bits of the float directly. But
>>> part of the power of C is that you can do these things if you wish, or if there
>>> is some actual requirement for some reason.
>> No, you /can't/ do that. It is a stupid thing to do, and you do people
>> a disservice by suggesting it is sometimes appropriate. Of course there
>> can be occasions where it is useful to see "inside" a floating point
>> value - /someone/ has to write software floating point libraries for
>> processors that can't handle them in hardware. But hopefully the people
>> that need to do that know more about C than you do, and are do it
>> safely, correctly, and efficiently instead of blind dangerous hacks that
>> are /not/ guaranteed to work in any useful fashion, even if "float" and
>> "int" are the same size on the target.
>>
>> C lets you do all kinds of things - including lots of non-portable
>> things (it is intended to be usable as a systems programming language as
>> well as a portable applications programming language). But if you try
>> to place smartarse tricks, you need to know /exactly/ what you are doing.
>>
> No. C doesn't provide facilities for what you are suggesting. That doesn't mean that
> you can't write bitwise operations on floats in C, without resorting to assembler.
> But you can't do so "safely, correctly, efficiently" instead of "blind dangerous hacks".
> And of course I do know how floating point arithmetic works and what I am doing.

Look, it is /very/ simple.

Let's assume that "float" is 32-bit. You are not going to be doing any
kind of low-level bitwise operations on float unless it is a known
format, so I think this is a fine assumption. (I've made other obvious
non-portable assumptions too.) Maybe you are wanting to look at the
highest significant bit as a way of identifying the sign of the number.

/Your/ suggestion is that you might do something like:

inline bool sign_bit(float f) {
int * p = &f;
int i = *p;
return i & 0x80000000;
}

That is just /wrong/. It is wildly unsafe, and many compilers will give
you unexpected results in practice, when the code is inlined and
optimised. The C language makes it perfectly clear that trying to use
an int* to access a float object is undefined behaviour, and compilers
will assume that you would never do such a stupid thing, or if you did,
you don't care what happens.

Getting it /right/ is very simple. Two examples are :

inline bool sign_bit(float f) {
uint32_t u;
memcpy(&u, &f, 4);
return u & 0x80000000;
}

and

inline bool sign_bit(float f) {
union {
uint32_t u;
float f;
} u;
u.f = f;
return u.u & 0x80000000;
}

Both of these are valid C (the second one is undefined behaviour in C++,
if that matters to you) and both have fully defined behaviour.

Any compiler for which it makes sense to talk about generating efficient
code, can handle such code optimally.

There really is no excuse for messing around with accessing data through
incompatible lvalues like you suggest - correct, safe and reliable
methods are simple and efficient.

niedziela, 16 lipca 2023 o 16:17:47 UTC+2 David Brown napisał(a):
> On 16/07/2023 14:42, Malcolm McLean wrote:
> > On Sunday, 16 July 2023 at 10:07:56 UTC+1, David Brown wrote:
> >> On 16/07/2023 01:25, Malcolm McLean wrote:
> >>> On Sunday, 16 July 2023 at 00:03:08 UTC+1, Keith Thompson wrote:
> >>>> David Brown <david...@hesbynett.no> writes:
> >>>>> On 14/07/2023 23:35, Kalevi Kolttonen wrote:
> >>>>>> Kaz Kylheku <864-11...@kylheku.com> wrote:
> >>>> [...]
> >>>>>>> You open yourself to being roasted for the code assuming ASCII,
> >>>>>>> 8 bit chars, pointers being all equal sized and all that.
> >>>>>
> >>>>> These things should not be a problem. Keep your pointers as pointers
> >>>>> of compatible type - there is rarely a good reason for wanting to
> >>>>> convert a pointer-to-int to a pointer-to-float, and certainly not for
> >>>>> mixing data pointers and function pointers. Think about what your
> >>>>> pointers are pointing at, and use that as the basis for types. And if
> >>>>> you ever think you need to mess with pointer types, you are probably
> >>>>> better using memcpy/memmove.
> >>>> Agreed -- but you can convert pointers without assuming that they're the
> >>>> same size. For example, if void* is bigger than int*, a conversion from
> >>>> int* to void* will still work correctly.
> >>>>
> >>>> Converting between int* and float*, for example tends to be for the
> >>>> purpose of aliasing int and float objects, and that's rarely useful
> >>>> (particularly since int and float are not guaranteed to have the same
> >>>> size).
> >>>>
> >>> It's a hacky, low level thing to do. And of course it's unlikely to be portable
> >>> to platforms on which int and float are of different sizes. And probably
> >>> not portable to platforms which don't use the particular float representation,
> >>> since the likely motive is to get access to the bits of the float directly. But
> >>> part of the power of C is that you can do these things if you wish, or if there
> >>> is some actual requirement for some reason.
> >> No, you /can't/ do that. It is a stupid thing to do, and you do people
> >> a disservice by suggesting it is sometimes appropriate. Of course there
> >> can be occasions where it is useful to see "inside" a floating point
> >> value - /someone/ has to write software floating point libraries for
> >> processors that can't handle them in hardware. But hopefully the people
> >> that need to do that know more about C than you do, and are do it
> >> safely, correctly, and efficiently instead of blind dangerous hacks that
> >> are /not/ guaranteed to work in any useful fashion, even if "float" and
> >> "int" are the same size on the target.
> >>
> >> C lets you do all kinds of things - including lots of non-portable
> >> things (it is intended to be usable as a systems programming language as
> >> well as a portable applications programming language). But if you try
> >> to place smartarse tricks, you need to know /exactly/ what you are doing.
> >>
> > No. C doesn't provide facilities for what you are suggesting. That doesn't mean that
> > you can't write bitwise operations on floats in C, without resorting to assembler.
> > But you can't do so "safely, correctly, efficiently" instead of "blind dangerous hacks".
> > And of course I do know how floating point arithmetic works and what I am doing.
> Look, it is /very/ simple.
>
> Let's assume that "float" is 32-bit. You are not going to be doing any
> kind of low-level bitwise operations on float unless it is a known
> format, so I think this is a fine assumption. (I've made other obvious
> non-portable assumptions too.) Maybe you are wanting to look at the
> highest significant bit as a way of identifying the sign of the number.
>
> /Your/ suggestion is that you might do something like:
>
> inline bool sign_bit(float f) {
> int * p = &f;
> int i = *p;
> return i & 0x80000000;
> }
>
> That is just /wrong/. It is wildly unsafe, and many compilers will give
> you unexpected results in practice, when the code is inlined and
> optimised.

i dont know for sure but i somewhat doubt it
such things as far as i was learned what c is are legal and defined behavoiur
&f is an adress, p holds ann adres, *p gives memory piece from that adres as if some int is there..it shouldnt break

> The C language makes it perfectly clear that trying to use
> an int* to access a float object is undefined behaviour, and compilers
> will assume that you would never do such a stupid thing, or if you did,
> you don't care what happens.
>
> Getting it /right/ is very simple. Two examples are :
>
> inline bool sign_bit(float f) {
> uint32_t u;
> memcpy(&u, &f, 4);
> return u & 0x80000000;
> }
>
> and
>
> inline bool sign_bit(float f) {
> union {
> uint32_t u;
> float f;
> } u;
> u.f = f;
> return u.u & 0x80000000;
> }
>
> Both of these are valid C (the second one is undefined behaviour in C++,
> if that matters to you) and both have fully defined behaviour.
>
> Any compiler for which it makes sense to talk about generating efficient
> code, can handle such code optimally.
>
> There really is no excuse for messing around with accessing data through
> incompatible lvalues like you suggest - correct, safe and reliable
> methods are simple and efficient.

niedziela, 16 lipca 2023 o 16:17:47 UTC+2 David Brown napisał(a):
> /Your/ suggestion is that you might do something like:
>
> inline bool sign_bit(float f) {
> int * p = &f;
> int i = *p;
> return i & 0x80000000;
> }
>
this one above is ok (imo)

>
> inline bool sign_bit(float f) {
> uint32_t u;
> memcpy(&u, &f, 4);
> return u & 0x80000000;
> }
>
>
this one above is stupid

> inline bool sign_bit(float f) {
> union {
> uint32_t u;
> float f;
> } u;
> u.f = f;
> return u.u & 0x80000000;
> }
>
this is the best imo (unions are very good invention )

overally i think you dont say the truth when you say compiler can optimize things to the extent it will damege the first piece

niedziela, 16 lipca 2023 o 18:58:04 UTC+2 fir napisał(a):
> niedziela, 16 lipca 2023 o 16:17:47 UTC+2 David Brown napisał(a):
> > /Your/ suggestion is that you might do something like:
> >
> > inline bool sign_bit(float f) {
> > int * p = &f;
> > int i = *p;
> > return i & 0x80000000;
> > }
> >
> this one above is ok (imo)
> >
> > inline bool sign_bit(float f) {
> > uint32_t u;
> > memcpy(&u, &f, 4);
> > return u & 0x80000000;
> > }
> >
> >
> this one above is stupid
> > inline bool sign_bit(float f) {
> > union {
> > uint32_t u;
> > float f;
> > } u;
> > u.f = f;
> > return u.u & 0x80000000;
> > }
> >
> this is the best imo (unions are very good invention )
>
> overally i think you dont say the truth when you say compiler can optimize things to the extent it will damege the first piece

overally its weird (or worse their weird) to write on architecture some dont know, or on two importanly different architectures at once... imu such writing could be rather understood as ugly trick/hack
so ask yourself if knowing your types and asuming them is more trick than writing on two or more at once in semi generalized way (imo the other is more trick genarally..though situations are different and sometimes its ok to use soem tricks probably)

besides compatibility should work on binary level often - my programs for windows works for example on unix even though i write totali specificaly for windows and core winapi only - and thats fine level of compatibility

niedziela, 16 lipca 2023 o 19:34:35 UTC+2 fir napisał(a):
>
> besides compatibility should work on binary level often - my programs for windows works for example on unix even though i write totali specificaly for windows and core winapi only - and thats fine level of compatibility

i mean linux..but im fan of binary compatibility - i think even apis for some task should be standarized, not liek today you got variety of libraries with variety of interfaces and thats a mess - that creates chaos in a societu of programmers and that chaos has imo mostly downsides..its liek this so caled babel tower

David Brown <david.brown@hesbynett.no> writes:

> Let's assume that "float" is 32-bit. You are not going to be doing any
> kind of low-level bitwise operations on float unless it is a known format,
> so I think this is a fine assumption. (I've made other obvious
> non-portable assumptions too.) Maybe you are wanting to look at the
> highest significant bit as a way of identifying the sign of the number.
>
> /Your/ suggestion is that you might do something like:
>
> inline bool sign_bit(float f) {
> int * p = &f;
> int i = *p;
> return i & 0x80000000;
> }
>
> That is just /wrong/. It is wildly unsafe, and many compilers will give
> you unexpected results in practice, when the code is inlined and optimised.
> The C language makes it perfectly clear that trying to use an int* to
> access a float object is undefined behaviour, and compilers will assume
> that you would never do such a stupid thing, or if you did, you don't care
> what happens.
>
> Getting it /right/ is very simple. Two examples are :
>
> inline bool sign_bit(float f) {
> uint32_t u;
> memcpy(&u, &f, 4);
> return u & 0x80000000;
> }
>
> and
>
> inline bool sign_bit(float f) {
> union {
> uint32_t u;
> float f;
> } u;
> u.f = f;
> return u.u & 0x80000000;
> }

Very a tangent, but I like the fact that compound literals and
designated initialisers let one write

return (union { uint32_t u; float f; }){ .f = f }.u & 0x80000000;

--
Ben.

On 16/07/2023 20:55, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:

>> Getting it /right/ is very simple. Two examples are :
>>
>> inline bool sign_bit(float f) {
>> uint32_t u;
>> memcpy(&u, &f, 4);
>> return u & 0x80000000;
>> }
>>
>> and
>>
>> inline bool sign_bit(float f) {
>> union {
>> uint32_t u;
>> float f;
>> } u;
>> u.f = f;
>> return u.u & 0x80000000;
>> }
>
> Very a tangent, but I like the fact that compound literals and
> designated initialisers let one write
>
> return (union { uint32_t u; float f; }){ .f = f }.u & 0x80000000;

I'm struggling to see the appeal of being able to do this!

Also, consider that the function result is a bool, which means probably
having to turn 0 or 0x80000000 into 0 or 1.

A lot of things going on just to access bit 31 of the parameter. Why the
need to go around the houses so much?

My language makes it easier, but it requires a type-punning cast to get
to an int value, so I spent a few minutes to make that automatic. Now it
is just:

f.[31] # when f has f32 type
f.[63] # f has f64 type (also f.msbit)
f.[52..62] # exponent field of f64 type

f can be any rvalue expression. (Clearly my idea of a systems language
has diverged considerably from C's.)

Sticking to C, however, I would just do:

(*(u32*)&f) & 0x80000000 # get 0x00000000 or 0x80000000

With >> or !! or (bool) used to obtain 0 or 1. Here `f` is a simple
variable and `u32` is a typedef.

If f is not a suitable l-value, it will need copying into a temp, or
wrapping the above into a function.

It just needs stipulating that it only works on the dozen or three
target platforms of interest.

Bart <bc@freeuk.com> writes:

> On 16/07/2023 20:55, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>
>>> Getting it /right/ is very simple. Two examples are :
>>>
>>> inline bool sign_bit(float f) {
>>> uint32_t u;
>>> memcpy(&u, &f, 4);
>>> return u & 0x80000000;
>>> }
>>>
>>> and
>>>
>>> inline bool sign_bit(float f) {
>>> union {
>>> uint32_t u;
>>> float f;
>>> } u;
>>> u.f = f;
>>> return u.u & 0x80000000;
>>> }
>>
>> Very a tangent, but I like the fact that compound literals and
>> designated initialisers let one write
>>
>> return (union { uint32_t u; float f; }){ .f = f }.u & 0x80000000;
>
> I'm struggling to see the appeal of being able to do this!

It's not clear to what your "this" refers: the contraction into one
expression, the use of a union or something else?

> Also, consider that the function result is a bool, which means probably
> having to turn 0 or 0x80000000 into 0 or 1.

You can use

return (union { uint32_t u; float f; }){ .f = f }.u >> 31;

if you prefer. I kept the & 0x80000000 to minimise the changes. By
putting the float first, I could also have eliminated the designated
initialiser:

return (union { float _; uint32_t u; }){ f }.u >> 31;

> A lot of things going on just to access bit 31 of the parameter. Why the
> need to go around the houses so much?

Because C has not way to get at bit 31 of a float. Anyway, I don't
think there are really many houses being gone round here.

> Sticking to C, however, I would just do:
>
> (*(u32*)&f) & 0x80000000 # get 0x00000000 or 0x80000000

Why? It seems odd to prefer an expression with no defined meaning.

> It just needs stipulating that it only works on the dozen or three target
> platforms of interest.

But you could use an expression that has no such restrictions. (It
still has restrictions, of course, just not those specific stipulated
ones.)

If you are writing code for yourself, it's you that takes any hit, but I
started my programming life at a time when there were lots of different
kinds of hardware and no standard for C. I spent a lot of time
wrestling with code that was "just fine" on the few machines it had been
tried on. I saw the 1989 C standard as a huge step forward. It did not
stop people writing code the "just worked" on the three targets they
cared about, but it did let some people chose to write more portable
code if they wanted to.

--
Ben.

On 17/07/2023 02:54, Bart wrote:
>
> On 16/07/2023 20:55, Ben Bacarisse wrote:
> > David Brown <david.brown@hesbynett.no> writes:
>
> >> Getting it /right/ is very simple.  Two examples are :
> >>
> >>     inline bool sign_bit(float f) {
> >>         uint32_t u;
> >>         memcpy(&u, &f, 4);
> >>         return u & 0x80000000;
> >>     }
> >>
> >> and
> >>
> >>     inline bool sign_bit(float f) {
> >>         union {
> >>             uint32_t u;
> >>             float f;
> >>         } u;
> >>         u.f = f;
> >>         return u.u & 0x80000000;
> >>     }
> >
> > Very a tangent, but I like the fact that compound literals and
> > designated initialisers let one write
> >
> >    return (union { uint32_t u; float f; }){ .f = f }.u & 0x80000000;
>

Yes, compound literals and designated initialisers can let you write
things a little neater, but in examples like these I prefer to be more
step-by-step to show what is going on. And not everyone is familiar
with the syntax here - whether for good reasons or bad reasons, neither
compound literals nor designated initialisers are very common in practice.

> I'm struggling to see the appeal of being able to do this!
>
> Also, consider that the function result is a bool, which means probably
> having to turn 0 or 0x80000000 into 0 or 1.
>

Yes.

Of course, I would expect a function like this to be optimised inline by
the compiler (the "inline" function qualifier is a hint to this). The
whole thing would cook down to a single bit test in the float, and the
compiler would use it for a conditional, or do a 31-bit shift-right, or
whatever is most efficient at the time.

Good programming is about writing clear and correct source code, and
letting the compiler do the job of the efficiency details. If
converting back or forth between a bool is an efficiency problem, you
should get a better compiler.

> A lot of things going on just to access bit 31 of the parameter. Why the
> need to go around the houses so much?
>

The code is quite simple. But it is not negligible code, because C is a
high level language. It is not assembly. A "float" is a floating point
object, not a collection of bits - you need source code to tell the
compiler that you want to view it as bits. The compiler will not
generate any unnecessary code.

>
> Sticking to C, however, I would just do:
>
>     (*(u32*)&f) & 0x80000000         # get 0x00000000 or 0x80000000
>

Yes, some people would do that - including Malcolm. That was why I made
the post, because such code is /wrong/ in C.

/Your/ own personal C compiler might have semantics to say that this is
valid and defined behaviour - that's fine. "gcc -fno-strict-aliasing"
also does. I don't know off-hand of any other compiler that supports
it, by which I mean /documents/ it as an extension to the C language.
(MSVC mentions something about it in a blog somewhere, but I don't see
that as proper documentation. However, I haven't read all of MSVC's
official documentation.)

The C standards specifically say that accessing an object through an
incompatible lvalue is undefined behaviour. The code might work by
chance, for a while, but it's a trap waiting to catch the unwary. So
why would anyone write such risky code?

We are talking about an unusual situation - it is very rare that you
ever need bit-level access to objects. (And I work at the lowest level
in coding.) It's okay that something rare takes a few lines of source
code. It's not difficult code, and it does not have run-time overhead.
So there is no excuse for not writing it /correctly/ and /safely/.

> With >> or !! or (bool) used to obtain 0 or 1. Here `f` is a simple
> variable and `u32` is a typedef.
>
> If f is not a suitable l-value, it will need copying into a temp, or
> wrapping the above into a function.

"f" is not a suitable lvalue for access by a "uint32 *" pointer.

>
> It just needs stipulating that it only works on the dozen or three
> target platforms of interest.
>

It doesn't work on gcc, clang, icc, or many other compilers. It might
work by luck on some others, and possibly it will work by design with
your own C compiler (only you can answer that).

By "work", I mean /always/ work - guaranteed by design - rather than
just look okay on a brief test but possibly fail in real use in the future.

On 7/14/23 09:16, Kalevi Kolttonen wrote:
.....
> You could well be right. But invoking UB is something so evil that no
> C or C++ program must ever do it, meaning that the
> programmers must know enough to avoid it.

I've unfortunately had no time to post a response since shortly before
you sent that message. In the time since then, you've been fully
informed about what's wrong with that statement, and acknowledged it.
Despite that fact, I'd still like to post my own response.

The standard defines the term "undefined behavior" as "behavior, upon
use of a nonportable or erroneous program construct or of erroneous
data, for which this document imposes no requirements". That definition
contains two important phrases that are often misunderstood. The most
important is "no requirements" - many people seem to think that UB means
that the program must fail immediately and catastrophically. In reality,
one of the most dangerous ways UB manifests is as your program doing
precisely what you incorrectly assumed it was required to do. What makes
this possibility dangerous is that you don't find out, not even by
careful testing, that your code is incorrect. You won't find out until
you port your code to a different system where the actual behavior is
different.

Another very common form of UB is to do something subtly different from
what you intended it to do, so subtly that you won't notice that it is
different unless you do very careful testing. You won't find out until
you need to make a major presentation to a client.

You don't seem to be suffering from that misconception, you seem
properly scared of UB.

The other tricky phrase is "this document". That's referring to the C
standard. Other documents might impose requirements, but as far as the C
standard is concerned, the code has undefined behavior. That was the
thing you apparently didn't realize, but I gather you're fully aware of
that now.

Something that I don't think has been properly discussed is the
connection between UB and conforming extensions to C. A fully conforming
implementation of C can provide extensions, either conforming or
non-conforming, that generally add features to the C language. A
conforming implementation can add features that radically change the
behavior of your code, so long as those features necessarily involve
code that renders the behavior undefined. The fact that the behavior is
undefined allows the implementation to define the behavior to be
whatever it wants, in order to implement the extension. The most common
way to do this is to make the feature depend upon the use of a keyword
whose name makes it a reserved identifier. For instance, any identifier
that starts with "_" followed by a capital letter is reserved, so for
example, a _OnesComplement keyword could be used to define an integer
type that uses one's complement representation. Until quite recently, it
was allowed for an implementation to specify that a particular type used
that representation, but standard C has never provided a way of
specifying that this be the case.

On Monday, 17 July 2023 at 02:43:50 UTC+1, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
>
> > On 16/07/2023 20:55, Ben Bacarisse wrote:
> >> David Brown <david...@hesbynett.no> writes:
> >
> >>> Getting it /right/ is very simple. Two examples are :
> >>>
> >>> inline bool sign_bit(float f) {
> >>> uint32_t u;
> >>> memcpy(&u, &f, 4);
> >>> return u & 0x80000000;
> >>> }
> >>>
> >>> and
> >>>
> >>> inline bool sign_bit(float f) {
> >>> union {
> >>> uint32_t u;
> >>> float f;
> >>> } u;
> >>> u.f = f;
> >>> return u.u & 0x80000000;
> >>> }
> >>
> >> Very a tangent, but I like the fact that compound literals and
> >> designated initialisers let one write
> >>
> >> return (union { uint32_t u; float f; }){ .f = f }.u & 0x80000000;
> >
> > I'm struggling to see the appeal of being able to do this!
> It's not clear to what your "this" refers: the contraction into one
> expression, the use of a union or something else?
> > Also, consider that the function result is a bool, which means probably
> > having to turn 0 or 0x80000000 into 0 or 1.
> You can use
>
> return (union { uint32_t u; float f; }){ .f = f }.u >> 31;
>
> if you prefer. I kept the & 0x80000000 to minimise the changes. By
> putting the float first, I could also have eliminated the designated
> initialiser:
>
> return (union { float _; uint32_t u; }){ f }.u >> 31;
> > A lot of things going on just to access bit 31 of the parameter. Why the
> > need to go around the houses so much?
> Because C has not way to get at bit 31 of a float. Anyway, I don't
> think there are really many houses being gone round here.
> > Sticking to C, however, I would just do:
> >
> > (*(u32*)&f) & 0x80000000 # get 0x00000000 or 0x80000000
>
> Why? It seems odd to prefer an expression with no defined meaning.
>
It's got two main advantages. You don't need to create a union, which is a bit
messy (if you've several similar functions, do you create the same union everywhere
in local scope, as you did, or do you create one in global scope - neither answer
is ideal). And the C is likely a very close match for the assembler. If you've got
to use bitwise operations instead of comparing to zero with a relational operator
to get the sign, then it's quite likely you'll end up going to assembly at some
point.

This doesn't mean incidentally that casting a pointer is the way Malcolm
would do it, as some people seem to think. Just that there might be reasons
for choosing that option.

On 17/07/2023 12:16, Malcolm McLean wrote:
> On Monday, 17 July 2023 at 02:43:50 UTC+1, Ben Bacarisse wrote:
>> Bart <b...@freeuk.com> writes:
>>
>>> On 16/07/2023 20:55, Ben Bacarisse wrote:
>>>> David Brown <david...@hesbynett.no> writes:
>>>
>>>>> Getting it /right/ is very simple. Two examples are :
>>>>>
>>>>> inline bool sign_bit(float f) {
>>>>> uint32_t u;
>>>>> memcpy(&u, &f, 4);
>>>>> return u & 0x80000000;
>>>>> }
>>>>>
>>>>> and
>>>>>
>>>>> inline bool sign_bit(float f) {
>>>>> union {
>>>>> uint32_t u;
>>>>> float f;
>>>>> } u;
>>>>> u.f = f;
>>>>> return u.u & 0x80000000;
>>>>> }
>>>>
>>>> Very a tangent, but I like the fact that compound literals and
>>>> designated initialisers let one write
>>>>
>>>> return (union { uint32_t u; float f; }){ .f = f }.u & 0x80000000;
>>>
>>> I'm struggling to see the appeal of being able to do this!
>> It's not clear to what your "this" refers: the contraction into one
>> expression, the use of a union or something else?
>>> Also, consider that the function result is a bool, which means probably
>>> having to turn 0 or 0x80000000 into 0 or 1.
>> You can use
>>
>> return (union { uint32_t u; float f; }){ .f = f }.u >> 31;
>>
>> if you prefer. I kept the & 0x80000000 to minimise the changes. By
>> putting the float first, I could also have eliminated the designated
>> initialiser:
>>
>> return (union { float _; uint32_t u; }){ f }.u >> 31;
>>> A lot of things going on just to access bit 31 of the parameter. Why the
>>> need to go around the houses so much?
>> Because C has not way to get at bit 31 of a float. Anyway, I don't
>> think there are really many houses being gone round here.
>>> Sticking to C, however, I would just do:
>>>
>>> (*(u32*)&f) & 0x80000000 # get 0x00000000 or 0x80000000
>>
>> Why? It seems odd to prefer an expression with no defined meaning.
>>
> It's got two main advantages.

It doesn't matter if it has a hundred advantages - your code has no
defined meaning, so it is wrong. That overrides all your (imagined)
advantages.

> You don't need to create a union, which is a bit
> messy (if you've several similar functions, do you create the same union everywhere
> in local scope, as you did, or do you create one in global scope - neither answer
> is ideal).

Your code is messy too. It's okay for something as rarely needed as
this to be a bit verbose.

And what do you even mean by "create a union" ? Do you mean declaring a
union type? That has no runtime cost, and microscopic compile time
cost, so it is irrelevant. Do you mean creating an object of union type
at runtime? You should be able to figure out how often that is done by
Ben's code - it's basic C. I find it hard to see your complaint as
having any meaning, never mind any merit.

> And the C is likely a very close match for the assembler.

That myth was dispelled fifty years ago. C is not an assembler.

> If you've got
> to use bitwise operations instead of comparing to zero with a relational operator
> to get the sign, then it's quite likely you'll end up going to assembly at some
> point.

Complete and utter bollocks.

And even if it were true, why would "you might use assembly at some
point" have any bearing on the fact that it is a bad idea to write
incorrect code in C?

>
> This doesn't mean incidentally that casting a pointer is the way Malcolm
> would do it, as some people seem to think. Just that there might be reasons
> for choosing that option.
>

The main reason people continue to write code like this is because
people like you continue to tell them it's a good idea. Please stop
doing so.