On Monday, 17 July 2023 at 13:54:21 UTC+1, David Brown wrote:
> 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.
>
Think of it as off-label usage. C doesn't allow bitwise operations on floats.
You're forcing it to do something it doesn't really want you to do, and so
of course you have to compromise on something.
>
> > 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 what do you even mean by "create a union" ?
>
If your English language skills are that low, then I can't help you.

> 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?
>
Because you write the incorrect code in C which nevertheless matches the
assembly very closely. Whilst the correct code which does the same thing
isn't as close a match. If you don't understand why that might be an advantage,
the again I can't really help you.
>
> > 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.
>
No, the main reason is that it's an easy and convenient way to get at the sign bit
of a float. Which sometimes you might want to do.

On 17/07/2023 16:08, Malcolm McLean wrote:
> On Monday, 17 July 2023 at 13:54:21 UTC+1, David Brown wrote:
>> 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.
>>
> Think of it as off-label usage. C doesn't allow bitwise operations on floats.
> You're forcing it to do something it doesn't really want you to do, and so
> of course you have to compromise on something.

You don't have to compromise on correctness!

C doesn't allow bitwaise operations directly on floats - that much is
true. But it /does/ allow you to get the underlying representation of a
float object. It provides two ways to do this - using type-punning
unions, and using char pointers (typified by using memcpy). It is truly
mind-boggling that someone would actively prefer to use an undefined and
dangerous hack instead of the safe and well-defined methods. If you
were a self-taught beginner at C programming, it would be an excusable
mistake until you learned better. But surely you understand by now -
accessing an object through an incompatible pointer type (other than a
char pointer) is undefined behaviour. Do not do that.

>>
>>> 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 what do you even mean by "create a union" ?
>>
> If your English language skills are that low, then I can't help you.
>

My English comprehension is not the problem - your lax writing is.
"Create a union" does not make sense - do you mean declaring a union
type, or defining an instance of a union? Do you even know what you
meant when you wrote it?

>> 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?
>>
> Because you write the incorrect code in C which nevertheless matches the
> assembly very closely.

Find a blackboard, and write out 100 lines - "C is not assembly".

It does not matter how much the C code resembles assembly, Cobol, or
pink unicorns, incorrect C code is incorrect C code. It does not
magically become valid just because it looks like assembly!

> Whilst the correct code which does the same thing
> isn't as close a match. If you don't understand why that might be an advantage,
> the again I can't really help you.

I remember a kid at school who would rather leave an incorrect answer to
a maths question than rub it out and correct it, because that might
leave an ugly mark on his page. Needless to say, he failed maths.

Similarly, /you/ fail programming.

It is always good to make code clear and readable, but /correctness/
always trumps some bizarre notion of looking nice. It does not matter a
bugger if the code "looks like assembly" (not that that is remotely an
advantage - people program in C so they don't have to program in
assembly), if the code is /wrong/.

>>
>>> 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.
>>
> No, the main reason is that it's an easy and convenient way to get at the sign bit
> of a float. Which sometimes you might want to do.

When you see a fellow programmer writing incorrect code - such as trying
to access an object through an incompatible pointer - you explain the
problem to them, and help them learn how to write the code correctly.
If necessary, you show them the C standards (section 6.5p7) But when
they insist that regardless of the code being correct or not, they
prefer writing it in a way they think is nicer, you have a quiet talk
with the boss.

Ignorance is easily curable. But such a cavalier attitude to
correctness is unprofessional. It's the kind of thing that gives our
profession a bad reputation - it's people writing hacks like that which
gives C code a reputation for being dangerous and buggy.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Monday, 17 July 2023 at 13:54:21 UTC+1, David Brown wrote:

>> 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.
>>
>No, the main reason is that it's an easy and convenient way to get at the sign bit
>of a float. Which sometimes you might want to do.

#include <math.h>

if (signbit(floating-value)) {
/* sign is negative */
} else {
/* sign is positive */
}

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> 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).

This is not very clear. Do you object to the declaration of an object
with a union type (as in DB's code) or the use of an anonymous object of
union type in my code? Your reference to local and global scope
suggests that you might be objecting to the former. Do you object to
the anonymous object as well?

Anyway, I can only answer your question for my suggestion -- if I had a
number of these functions I'd use anonymous objects of just the right
union type for each function, just as you would, presumably, prefer to
use undefined cast expressions of the just the right type for each
function.

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

That's an odd way of putting it. The C you prefer is undefined, so you
are making some big assumptions about what the assembler is likely to
be! But, even so, why is this matching an advantage? And why do you
think my version does not result in a similar "close match"?

I can't see anything that would make me prefer an undefined construct.

> 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.

What are you thinking about here? If you have a more realistic example,
that might be worth discussing.

The example was, I suspect, picked on a whim. If you want the sign bit
of a float in C you'd use the signbit macro, but surely we can discuss
the defined/undefined situation even though the example is not realistic?

> 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.

Has the article quoting been messed up or are you referring to yourself
in the third person?

--
Ben.

Kalevi Kolttonen:

> Many years ago, K&R book said that C is a small language
> and it is best served by a small book.

I am interested in equally small and consice programming
languages without C's worst drawbacks and counter-
intuitiveness. How's about Hare:

https://harelang.org/
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On Monday, 17 July 2023 at 16:15:27 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > 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).
> This is not very clear. Do you object to the declaration of an object
> with a union type (as in DB's code) or the use of an anonymous object of
> union type in my code? Your reference to local and global scope
> suggests that you might be objecting to the former. Do you object to
> the anonymous object as well?
>
You created an anonymous union, which of course had local scope. One
drawback to that is that if we have several functions all accessing the bits
of a float, then we'll want the unions to be declared in the same way, so that
they match. But you can't enforce that. People might use different identifiers
to "u" and "f" for the members, for example.
>
> Anyway, I can only answer your question for my suggestion -- if I had a
> number of these functions I'd use anonymous objects of just the right
> union type for each function, just as you would, presumably, prefer to
> use undefined cast expressions of the just the right type for each
> function.
>
The undefined cast expressions are less likely to fail to match, though of
course it's possible because there are several type aliases.
> > And the C is likely a very
> > close match for the assembler.
>
> That's an odd way of putting it. The C you prefer is undefined, so you
> are making some big assumptions about what the assembler is likely to
> be! But, even so, why is this matching an advantage? And why do you
> think my version does not result in a similar "close match"?
>
In assember we will certainly have a way of saying "take the memory at
location f and interpret it as a 32 bit integer". It's less clear how we should
write access to another member of a union in assembler.
>
> I can't see anything that would make me prefer an undefined construct.
>
Writing to one member of a union and reading another is also undefined
behaviour, though that rule is more honoured in the breach than the observance.
>
> > 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.
>
> What are you thinking about here? If you have a more realistic example,
> that might be worth discussing.
>
Here's a real bit of code
double addwave(double a, double b) {
if (std::signbit(a) == std::signbit(b)) {
if (std::signbit(a) == 0)
return a + b - a * b;
else
return a + b + a * b;
}
else
return a + b;
}

This is very likely to be a rate limiting step, because it's got to be called for every
sample of a wave. So it's the sort of thing which might be a candidate
for assembly. If we're going to do that, it can help to write out the C so that each
line of C corresponds to one assembly instruction.
>
> The example was, I suspect, picked on a whim. If you want the sign bit
> of a float in C you'd use the signbit macro, but surely we can discuss
> the defined/undefined situation even though the example is not realistic?
>
One problem with C is that older versions of the standard don't have isnan(),
and some compilers complain about comparing a variable to itself (by the rules
of flating point arithmetic, this returns false if the value is NaN so it's a way to
write isnan()). I can see someone resorting to examining the bits. That might be
a more realisitc example.

> > 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.
> Has the article quoting been messed up or are you referring to yourself
> in the third person?
>
I'm quoting DB.

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

> ... But surely you understand by now - accessing an object
> through an incompatible pointer type (other than a char pointer) is
> undefined behaviour. Do not do that.

This is an aside, but since there may be people reading this getting
nervous, I thought it worth explaining that you are using a short hand
here. After all, there are lots of people who share Malcolm, Bart and
fir's assumption that *(int *)&f must "do what it says" and they might
want some more detail about what it actually permitted.

First, it's not really the type of the pointer that matters. What
matters is what is called the lvalue expression used to access an
object, which, when using a pointer p, will be something like *p or
p[n]. For example, given

float f, *fp = &f, *const fcp = &f;

fp and fcp are pointers with incompatible types, but f can be accessed
through both because the lvalue expressions *fp and *fcp have the exact
same type as the object, f, being accessed i.e. float.

Now, C's definition of compatible types is very strict. To a first
approximation, two type are only compatible if they are essentially the
same (there are exceptions but I won't go into all the gory details
here). This is way too strict to be useful for defining things like
assignment and other accesses which have more lax rules. Unfortunately
these other relationships don't have names, so people use "compatible"
as a shorthand.

The basic rule being discussed in this thread is that a value stored in
an object can only be accessed by an lvalue expression that has one of a
number of types closely related to what is called the effective type of
the object. The effective type is whole other topic, but for the
purposes of the this discussion, the effective type of an object is it's
declared type.

So, at last, the rules say that you can access the value in f with an
lvalue expression with a type that is

- float
- a qualified version of float
- a character type
- an array, struct or union type that includes (possibly recursively)
a member with one of these types

(There are other permited types for object that can have signed or
unsigned versions of the effective type, but floating types don't have
signed or unsigned variants.)

Since the type of *(int *)&f is int, and int is not on this list,
accessing f using the expression *(int *)&f is not permitted.

Note, however, that both *(char *)&f and ((char *)&f)[sizeof f - 1] are
permitted and give access either end of the float (though char could be
the same size as float in some odd architectures).

There should be a name for this relationship between types, like
"effectively compatible", but there isn't one in the language standard,
and I don't think there is on that is widely used. Maybe we could use
"effectively compatible"...

Similarly, you will see people talk about two types being "assignment
compatible" in order to refer to the related (but different) rules
covering assignment and argument passing. The standard itself even
refers to these rules in a number of places, but without a name for
them, it must reference "the constraints of 6.5.16.1" instead!

--
Ben.

On 17/07/2023 15:43, David Brown wrote:
> On 17/07/2023 16:08, Malcolm McLean wrote:
>> Think of it as off-label usage. C doesn't allow bitwise operations on
>> floats.
>> You're forcing it to do something it doesn't really want you to do,
>> and so
>> of course you have to compromise on something.
>
> You don't have to compromise on correctness!
>
> C doesn't allow bitwaise operations directly on floats - that much is
> true. But it /does/ allow you to get the underlying representation of a
> float object. It provides two ways to do this - using type-punning
> unions,

That doesn't help when the object you want to alias exists elsewhere. It
means pointless copying to a specially created union object.

(In C, if the value being aliased is a transient value anyway, not
stored in memory, then such copying is necessary. My language allows
type-punning of such values without using memory, but may involve
copying from one kind of register to another.)

> and using char pointers (typified by using memcpy). It is truly
> mind-boggling that someone would actively prefer to use an undefined and
> dangerous hack

Undefined and dangerous where, on some of your whacky hardware? Or is it
only undefined and dangerous because your favourite compiler has seized
on that UB label to do who knows what?

>> No, the main reason is that it's an easy and convenient way to get at
>> the sign bit
>> of a float. Which sometimes you might want to do.
>
> When you see a fellow programmer writing incorrect code - such as trying
> to access an object through an incompatible pointer

You mean trying to access the same 4 bytes of memory through both a u32*
pointer and an f32* pointer?

Forgive me for not seeing the issue doing that on any machine I can buy
today to try it out on.

But how does memcpy manage it, just by converting the pointers to void*?

Anyone directly accessing bit 31 of a float /by any means/, in the hope
that it is the sign bit, is already writing non-portable code.

> Ignorance is easily curable. But such a cavalier attitude to
> correctness is unprofessional. It's the kind of thing that gives our
> profession a bad reputation - it's people writing hacks like that which
> gives C code a reputation for being dangerous and buggy.

It doesn't need any help with that. Some things you can do are
jaw-droppingly unsafe, but still valid C.

Like taking a sequence of deref and index operations in an expression,
and mixing them up. It's now completely wrong, but it still compiles.

Because any T* object can be indexed, whether it points to an array-like
sequence of elements or not. This is not just an ordinary out-of-bounds
arrays; there /are/ no bounds because there is no array!

Am 13.07.2023 um 07:37 schrieb Blue-Maned_Hawk:
>
> ​Ain't nothing gonna dethrone C until a total revolution of the modern
> computing ecosystem; in other words, replacing C would require replacing
> everything else all at once.

C has already been dethroned many times. But C is easy to learn
so people stick with that, ignoring that there are a lot of much
more comfortable alternatives, C++ is just an example which I
would pefer always any time. But if you want to learn C++ from
ground up to a decent level you would need to read 2.000 to 3.000
book pages.

On Monday, 17 July 2023 at 17:21:28 UTC+1, Bart wrote:
> On 17/07/2023 15:43, David Brown wrote:
> > On 17/07/2023 16:08, Malcolm McLean wrote:
>
> Anyone directly accessing bit 31 of a float /by any means/, in the hope
> that it is the sign bit, is already writing non-portable code.
>
We're slightly cleverer than that. Were testing the leftmost bit of an
integer, when the floating bits are reinterpreted as an integer. That's
very likely to be the sign bit, because it means that floating point values
can be compared using the same circuitry as integer values. (Except they
can't because of NaN, but that's another story).

Bonita Montero <Bonita.Montero@gmail.com> wrote:
> But if you want to learn C++ from ground up to a
> decent level you would need to read 2.000 to 3.000
> book pages.

It is a daunting task.

Python O'Reilly book (5th edition) can be found here:

https://www.oreilly.com/search/?q=python&type=*&rows=10

It also absolutely enormous: 1600 pages.

My Python skills are pretty basic and I really do not
claim to have mastered that book. I don't even own it.

br,
KK

Am 17.07.2023 um 19:00 schrieb Kalevi Kolttonen:
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> But if you want to learn C++ from ground up to a
>> decent level you would need to read 2.000 to 3.000
>> book pages.
>
> It is a daunting task.
> Python O'Reilly book (5th edition) can be found here:
> https://www.oreilly.com/search/?q=python&type=*&rows=10
> It also absolutely enormous: 1600 pages.
> My Python skills are pretty basic and I really do not
> claim to have mastered that book. I don't even own it.

Python is totally different and for sure not designed
for the same purposes.
I don't have any probems with such languages since
the complexity mostly compensates complexity on your
own code.

On 7/17/2023 10:00 AM, Kalevi Kolttonen wrote:
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> But if you want to learn C++ from ground up to a
>> decent level you would need to read 2.000 to 3.000
>> book pages.
>
> It is a daunting task.
>
> Python O'Reilly book (5th edition) can be found here:
>
> https://www.oreilly.com/search/?q=python&type=*&rows=10
>
> It also absolutely enormous: 1600 pages.
>
> My Python skills are pretty basic and I really do not
> claim to have mastered that book. I don't even own it.

Fwiw, here is an older python 3 based plotter, it uses PIL for creating
the renderings:

https://pastebin.com/raw/x7BtH8sG

Can you get it to work? It should generate a file called output.bmp

On 2023-07-17, David Brown <david.brown@hesbynett.no> wrote:
> On 17/07/2023 12:16, Malcolm McLean wrote:
>> On Monday, 17 July 2023 at 02:43:50 UTC+1, Ben Bacarisse wrote:
>> 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.

But does it have to be verbose? Maybe we could use macros to shorten it.

We had this bit of code upthread:

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

The kernel here is that a union is declared with two members, of
different types. It is initialized with one, and accessed with the other.

With C99 syntax, we can do that as one expression:

#include <stdio.h>

#define union_cast(to_type, from_type, value) \
((union { to_type to; from_type from; }){ .from = (value) }.to)

int main(void)
{ float x = 4.2;
unsigned y = union_cast(unsigned, float, x);
printf("%x\n", y);
return 0;
}

Output produced:

40866666

We could have a static assertion in there that to_type and from_type
are of the same size and whatnot.

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

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> Fwiw, here is an older python 3 based plotter, it uses PIL for creating
> the renderings:
>
> https://pastebin.com/raw/x7BtH8sG
>
> Can you get it to work? It should generate a file called output.bmp

It did not work and I am not interested in trying to figure out why.

br,
KK

On 7/17/2023 12:18 PM, Kalevi Kolttonen wrote:
> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> Fwiw, here is an older python 3 based plotter, it uses PIL for creating
>> the renderings:
>>
>> https://pastebin.com/raw/x7BtH8sG
>>
>> Can you get it to work? It should generate a file called output.bmp
>
> It did not work and I am not interested in trying to figure out why.

Do you have PIL installed?

On 17/07/2023 18:21, Bart wrote:
> On 17/07/2023 15:43, David Brown wrote:
> > On 17/07/2023 16:08, Malcolm McLean wrote:
> >> Think of it as off-label usage. C doesn't allow bitwise operations on
> >> floats.
> >> You're forcing it to do something it doesn't really want you to do,
> >> and so
> >> of course you have to compromise on something.
> >
> > You don't have to compromise on correctness!
> >
> > C doesn't allow bitwaise operations directly on floats - that much is
> > true.  But it /does/ allow you to get the underlying representation of a
> > float object.  It provides two ways to do this - using type-punning
> > unions,
>
> That doesn't help when the object you want to alias exists elsewhere. It
> means pointless copying to a specially created union object.
>

It's okay to say you think C /should/ allow access to data through
incompatible pointers (see Ben's post for the full story - I will
continue to use the short form for convenience), or to say that you feel
it would be useful in your coding.

What is /wrong/, is Malcolm's attitude of thinking that he'd /like/ such
pointer cast accesses to work, so he will just use them (and recommend
them) and pretend that makes it all okay.

I can agree that occasionally it can be nice to be able to access memory
in a different way, and memcpy() is a bit ugly (though usually it has
zero run-time cost in such situations). But being a nice idea is not
enough - the code needs to be correct. For my own use, if such a use
turns up (and I can't remember when that might last have been - it's
very rare), there are gcc extensions that handle it safely. For non-gcc
(or non-gcc compatible) tools, I'd use memcpy() or a char pointer -
correct code beats neat code every time.

>
> > and using char pointers (typified by using memcpy).  It is truly
> > mind-boggling that someone would actively prefer to use an undefined and
> > dangerous hack
>
> Undefined and dangerous where, on some of your whacky hardware? Or is it
> only undefined and dangerous because your favourite compiler has seized
> on that UB label to do who knows what?
>

It is undefined because the C language standards don't define it - they
say specifically that you should not do it. I don't know of any
compiler that documents that they allow it as an extension, except
specifically the "-fno-strict-aliasing" flag in gcc. As a serious
programmer interested in writing correct and reliable code, I would
never (never knowingly - I have accidental bugs like everyone else) use
such undefined behaviour in code unless I had a clear guarantee that it
would work.

And yes, several real optimising compilers take advantage of type-based
alias analysis in their optimisation. Like most optimisation
techniques, it only rarely makes a difference - optimisation is the sum
of dozens of small improvements. So that means your bad code might work
in 99% of use-cases, and fail in 1% - a much worse situation than a
clear and outright failure.

The solution, of course, is to avoid writing such bad code. (And enable
warnings so that your compiler will tell you when you get it wrong.)

> >> No, the main reason is that it's an easy and convenient way to get at
> >> the sign bit
> >> of a float. Which sometimes you might want to do.
> >
> > When you see a fellow programmer writing incorrect code - such as trying
> > to access an object through an incompatible pointer
>
> You mean trying to access the same 4 bytes of memory through both a u32*
> pointer and an f32* pointer?
>

Yes.

> Forgive me for not seeing the issue doing that on any machine I can buy
> today to try it out on.
>

You are either a complete idiot, or you are trolling. And I know you
are a very smart guy. Maybe there's a third option, and you are just
pretending to be an idiot.

Please read the paragraph in the C standards (6.5p7), or Ben's rather
nice post. Or re-read one of the hundreds or thousands of discussions
on the topic that you have been involved in over the years in c.l.c.

> But how does memcpy manage it, just by converting the pointers to void*?
>

You can always access the data through char pointers. You know this.

> Anyone directly accessing bit 31 of a float /by any means/, in the hope
> that it is the sign bit, is already writing non-portable code.

This is not about portability.

>
> > Ignorance is easily curable.  But such a cavalier attitude to
> > correctness is unprofessional.  It's the kind of thing that gives our
> > profession a bad reputation - it's people writing hacks like that which
> > gives C code a reputation for being dangerous and buggy.
>
> It doesn't need any help with that. Some things you can do are
> jaw-droppingly unsafe, but still valid C.
>

You mistake "syntactically valid" for "correct".

> Like taking a sequence of deref and index operations in an expression,
> and mixing them up. It's now completely wrong, but it still compiles.
>
> Because any T* object can be indexed, whether it points to an array-like
> sequence of elements or not. This is not just an ordinary out-of-bounds
> arrays; there /are/ no bounds because there is no array!
>
>
>

On 17/07/2023 20:46, Kaz Kylheku wrote:
> On 2023-07-17, David Brown <david.brown@hesbynett.no> wrote:
>> On 17/07/2023 12:16, Malcolm McLean wrote:
>>> On Monday, 17 July 2023 at 02:43:50 UTC+1, Ben Bacarisse wrote:
>>> 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.
>
> But does it have to be verbose? Maybe we could use macros to shorten it.

Sure, it can be shorted in several ways - Ben gave an example using
compound literals.

>
> We had this bit of code upthread:
>
> inline bool sign_bit(float f)
> {
> union {
> uint32_t u;
> float f;
> } u;
> u.f = f;
> return u.u & 0x80000000;
> }
>
>
> The kernel here is that a union is declared with two members, of
> different types. It is initialized with one, and accessed with the other.
>
> With C99 syntax, we can do that as one expression:
>
> #include <stdio.h>
>
> #define union_cast(to_type, from_type, value) \
> ((union { to_type to; from_type from; }){ .from = (value) }.to)
>
>
> int main(void)
> {
> float x = 4.2;
> unsigned y = union_cast(unsigned, float, x);
> printf("%x\n", y);
> return 0;
> }
>
> Output produced:
>
> 40866666
>
> We could have a static assertion in there that to_type and from_type
> are of the same size and whatnot.
>

You could certainly do that. I'd rather not - I think it hides too
much, and it would be tempting to use that macro in too many other
situations where it is not really the right choice. (As has been
pointed out, this example was just an example - a better solution in
real code would use the "sign_bit" macro, or simply a comparison to 0.0.)

On 17/07/2023 18:17, Malcolm McLean wrote:
> On Monday, 17 July 2023 at 16:15:27 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> 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).
>> This is not very clear. Do you object to the declaration of an object
>> with a union type (as in DB's code) or the use of an anonymous object of
>> union type in my code? Your reference to local and global scope
>> suggests that you might be objecting to the former. Do you object to
>> the anonymous object as well?
>>
> You created an anonymous union, which of course had local scope.

Please stop writing "creating a union" without saying what you actually
mean - the type or an instance.

> One
> drawback to that is that if we have several functions all accessing the bits
> of a float, then we'll want the unions to be declared in the same way, so that
> they match. But you can't enforce that. People might use different identifiers
> to "u" and "f" for the members, for example.

Both the type and the instance are local to the function - it is
completely irrelevant what identifiers they use, or whether the unions
are declared the same way in every use. There is no connection between
local types or variables declared in different functions.

>>
>> Anyway, I can only answer your question for my suggestion -- if I had a
>> number of these functions I'd use anonymous objects of just the right
>> union type for each function, just as you would, presumably, prefer to
>> use undefined cast expressions of the just the right type for each
>> function.
>>
> The undefined cast expressions are less likely to fail to match, though of
> course it's possible because there are several type aliases.

"Less likely to fail" is not a criteria for writing good code. Unions
(or memcpy) are guaranteed to work, hacky casts are merely "might work
as long as you stay lucky". There is no contest.

>>> And the C is likely a very
>>> close match for the assembler.
>>
>> That's an odd way of putting it. The C you prefer is undefined, so you
>> are making some big assumptions about what the assembler is likely to
>> be! But, even so, why is this matching an advantage? And why do you
>> think my version does not result in a similar "close match"?
>>
> In assember we will certainly have a way of saying "take the memory at
> location f and interpret it as a 32 bit integer". It's less clear how we should
> write access to another member of a union in assembler.

No one is writing assembly here, so it is as irrelevant as how the code
would look in Haskell or Forth.

>>
>> I can't see anything that would make me prefer an undefined construct.
>>
> Writing to one member of a union and reading another is also undefined
> behaviour, though that rule is more honoured in the breach than the observance.
>>

No, it is fully /defined/ behaviour. See 6.5.2.3p3, especially the
footnote.

(It is undefined behaviour in C++ - there you would use the memcpy()
version, or std::bit_cast<> in C++20.)

>>> 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.
>>
>> What are you thinking about here? If you have a more realistic example,
>> that might be worth discussing.
>>
> Here's a real bit of code
> double addwave(double a, double b) {
> if (std::signbit(a) == std::signbit(b)) {
> if (std::signbit(a) == 0)
> return a + b - a * b;
> else
> return a + b + a * b;
> }
> else
> return a + b;
> }
>
> This is very likely to be a rate limiting step, because it's got to be called for every
> sample of a wave. So it's the sort of thing which might be a candidate
> for assembly. If we're going to do that, it can help to write out the C so that each
> line of C corresponds to one assembly instruction.

Fast is not a substitute for correct.

And the compiler will do a better job than almost all programmers could
do in assembly - particularly if the C programmer does /not/ play
smart-arse and try to manually "optimise" the code with hacks and tricks.

>>
>> The example was, I suspect, picked on a whim. If you want the sign bit
>> of a float in C you'd use the signbit macro, but surely we can discuss
>> the defined/undefined situation even though the example is not realistic?
>>
> One problem with C is that older versions of the standard don't have isnan(),
> and some compilers complain about comparing a variable to itself (by the rules
> of flating point arithmetic, this returns false if the value is NaN so it's a way to
> write isnan()). I can see someone resorting to examining the bits. That might be
> a more realisitc example.
>
> > > 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.
>> Has the article quoting been messed up or are you referring to yourself
>> in the third person?
>>
> I'm quoting DB.

It was not a quotation from me. Maybe you meant you were paraphrasing me?

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

> Kalevi Kolttonen:
>
>> Many years ago, K&R book said that C is a small language
>> and it is best served by a small book.
>
> I am interested in equally small and consice programming
> languages without C's worst drawbacks and counter-
> intuitiveness. How's about Hare:
>
> https://harelang.org/

Another one! The trouble with all these languages is that what matters
most is the social and economic context, not the technical merits (or
demerits) of the language. A language must have some technical merit,
but that's of not use on it's own.

C succeeded because is was the language for Unix systems. Universities
used Unix and students graduated knowing C. Small systems (PCs and
workstations) needing something better than BASIC and assembler came
along at exactly the right time when those graduates were starting to
get jobs.

--
Ben.

On 17/07/2023 20:47, Ben Bacarisse wrote:
> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>
>> Kalevi Kolttonen:
>>
>>> Many years ago, K&R book said that C is a small language
>>> and it is best served by a small book.
>>
>> I am interested in equally small and consice programming
>> languages without C's worst drawbacks and counter-
>> intuitiveness. How's about Hare:
>>
>> https://harelang.org/
>
> Another one! The trouble with all these languages is that what matters
> most is the social and economic context, not the technical merits (or
> demerits) of the language. A language must have some technical merit,
> but that's of not use on it's own.

> C succeeded because is was the language for Unix systems. Universities
> used Unix and students graduated knowing C. Small systems (PCs and
> workstations) needing something better than BASIC and assembler came
> along at exactly the right time when those graduates were starting to
> get jobs.

My college didn't use C; instead there was Algol60 followed by Pascal,
and on my placements we used Fortran. But then none of the OSes used
were Unix either.

Maybe I was lucky in that regard.

As for jobs, I worked with microprocessors. I developed a small language
exactly suited for helping me with the myriad small coding tasks (I
still use a version today).

Unlike C, it was designed to work on the hardware at hand, which I knew
intimately (I designed most of it!). There was very little UB.

C was impractical for a number of reasons. First, I didn't know it but
had heard of it. I bought a book K&R1, but I decided I didn't care for
it (to either use it or implement it), and sold the book to a more
enthusiastic colleague.

Second, getting an actual C compiler was not easy: they were not cheap
then (and I was not a programmer, but an engineer; nobody was going to
pay for one) and on 8-bit machines each using their own disk formats,
physically getting into the machine required some ingenuity.

But lastly, according to Byte magazine reviews of C compilers for
floppy-disk-based Z80 and PC compilers at that time, they were all dead
slow, taking minutes for the simplest benchmark. (Turbo C came along a
bit later.)

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> Do you have PIL installed?

[root@hostname ~]# rpm -qa|grep -i python|grep -i pil
python3-pillow-9.4.0-2.fc38.x86_64

The result of googling:

"What is PIL/Pillow? PIL (Python Imaging Library) adds
many image processing features to Python. Pillow is a
fork of PIL that adds some user-friendly features."

It seems to me that Fedora 38 ships with Pillow but
not PIL.

Anyway, your code worked after inserting a shebang line:

#!/usr/bin/python3

br,
KK

Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Python is totally different and for sure not designed
> for the same purposes.

Both are suitable for some application programming,
so there is some overlap between their usage
cases.

One case in point: GNU groff is written in C++ but
I don't see why it could not be Python instead.

br,
KK

Bart <bc@freeuk.com> writes:

> On 17/07/2023 20:47, Ben Bacarisse wrote:
>> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>>
>>> Kalevi Kolttonen:
>>>
>>>> Many years ago, K&R book said that C is a small language
>>>> and it is best served by a small book.
>>>
>>> I am interested in equally small and consice programming
>>> languages without C's worst drawbacks and counter-
>>> intuitiveness. How's about Hare:
>>>
>>> https://harelang.org/
>>
>> Another one! The trouble with all these languages is that what matters
>> most is the social and economic context, not the technical merits (or
>> demerits) of the language. A language must have some technical merit,
>> but that's of not use on it's own.
>
>> C succeeded because is was the language for Unix systems. Universities
>> used Unix and students graduated knowing C. Small systems (PCs and
>> workstations) needing something better than BASIC and assembler came
>> along at exactly the right time when those graduates were starting to
>> get jobs.
>
> My college didn't use C;

Nor mine. I was not suggesting universal use of Unix.

> instead there was Algol60 followed by Pascal, and
> on my placements we used Fortran. But then none of the OSes used were Unix
> either.
>
> Maybe I was lucky in that regard.

I think you are missing the point. Fortran was very successful. Was it
a technically superiour language? Nope. Algol 60 was a failure (except
as an inspiration to many other languages). Why? The reasons are not
technical there either.

--
Ben.

poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
> C is a high level language.

i propose to say c is mid-level language.. i would say its closer to low-lewel than high-level becouse c needs/expect consciousnes on low-level things, thats for sure..but is not so much good to name id low-lewel probably as some of c virtue (if i remember the meaning of this word as im not sure) is to span low level with high-level abstractions - but id dont reach too high to lost contact with low lewel reality - so the conclusion is c may be named mid-level (od low-to-mid-high-level)