On 10/13/23 18:02, Blue-Maned_Hawk wrote:
> James Kuyper wrote:
>
>> On 10/12/23 09:42, Blue-Maned_Hawk wrote:
>>> Keith Thompson wrote:
>>>
>>>> A solution that depends on a header that's introduced in C23, a
>>>> standard that hasn't been published yet, is hardly portable.
>>>
>>> Well, it will be in 2024.
>>
>> You expect the new standard to be widely adopted so much quicker than
>> any previous version? Why?
>
> What?

The first version of the C standard was the one adopted most quickly. It
became standard in 1990, but code relying upon that standard did not
qualify as "portable" until at least a decade later. Adoption of the
1999 version of the standard was much slower. There's still a fair
number of people who refuse to use any version of C later than C90.
Subsequent versions of C haven't been adopted any faster than that one.
Yet, you expect code relying upon features that are new in C2023 to
become fully portable in only a year?

Keith Thompson wrote:

> I don't know what was unclear. You seem to expect universal adoption of
> the C23 standard by 2024. Given the adoption speed of previous editions
> of the C standard, that's completely unrealistic.

I can't see why an implementation wouldn't adopt C23 if it didn't want to
be considered obsolete.

--
Uh. There was supposed to be a signature here, but it seems to have
disappeared.

James Kuyper wrote:

> The first version of the C standard was the one adopted most quickly. It
> became standard in 1990, but code relying upon that standard did not
> qualify as "portable" until at least a decade later. Adoption of the
> 1999 version of the standard was much slower. There's still a fair
> number of people who refuse to use any version of C later than C90.
> Subsequent versions of C haven't been adopted any faster than that one.
> Yet, you expect code relying upon features that are new in C2023 to
> become fully portable in only a year?

Portability to obsolete systems does not matter.

--
Something's wrong with my signature and i'm going to go into a test group
to figure out what it is.

On 10/13/23 22:14, Blue-Maned_Hawk wrote:
> Keith Thompson wrote:
>
>> I don't know what was unclear. You seem to expect universal adoption of
>> the C23 standard by 2024. Given the adoption speed of previous editions
>> of the C standard, that's completely unrealistic.
>
> I can't see why an implementation wouldn't adopt C23 if it didn't want to
> be considered obsolete.

That shows a lack of imagination. Many implementations have routinely
chosen to remain "obsolete" for many years after a given version of the
standard was approved. Typical reasons include a customer base that is
either not ready yet to make use of the new features, or in many cases,
are actively opposed to using them. As I pointed out earlier, there are
people who still refuse to use anything more recent than C90 - several
of them post to this newsgroup regularly. Updating the implementation to
only optionally support the new features seems an obvious solution, but
it takes time and costs money, and will be a low priority if their
customers have no particular interest in using those features.

Another common problem is implementations that have a really large
customer base, who have ambitions to acquire a large market share by
locking their customers into using proprietary extensions provided only
by their implementation. Such implementors may want to actively avoid
closely tracking the standard. They don't want people to get in the
habit of writing portable C2023; they want to people to get into the
habit of writing code that relies on version 5.1.15 of the brand X
implementation of C.

On 10/13/23 22:15, Blue-Maned_Hawk wrote:
> James Kuyper wrote:
>
>> The first version of the C standard was the one adopted most quickly. It
>> became standard in 1990, but code relying upon that standard did not
>> qualify as "portable" until at least a decade later. Adoption of the
>> 1999 version of the standard was much slower. There's still a fair
>> number of people who refuse to use any version of C later than C90.
>> Subsequent versions of C haven't been adopted any faster than that one.
>> Yet, you expect code relying upon features that are new in C2023 to
>> become fully portable in only a year?
>
> Portability to obsolete systems does not matter.

It does if those systems are widely used, despite being "obsolete", as
is very often the case. Keep in mind that many of the people using these
systems would not consider them "obsolete" until they are at least two
or more versions behind the standard.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>On 10/13/23 22:14, Blue-Maned_Hawk wrote:
>> Keith Thompson wrote:
>>
>>> I don't know what was unclear. You seem to expect universal adoption of
>>> the C23 standard by 2024. Given the adoption speed of previous editions
>>> of the C standard, that's completely unrealistic.
>>
>> I can't see why an implementation wouldn't adopt C23 if it didn't want to
>> be considered obsolete.
>
>That shows a lack of imagination. Many implementations have routinely
>chosen to remain "obsolete" for many years after a given version of the
>standard was approved. Typical reasons include a customer base that is
>either not ready yet to make use of the new features, or in many cases,
>are actively opposed to using them. As I pointed out earlier, there are
>people who still refuse to use anything more recent than C90 - several
>of them post to this newsgroup regularly. Updating the implementation to
>only optionally support the new features seems an obvious solution, but
>it takes time and costs money, and will be a low priority if their
>customers have no particular interest in using those features.
>
>Another common problem is implementations that have a really large
>customer base, who have ambitions to acquire a large market share by
>locking their customers into using proprietary extensions provided only
>by their implementation. Such implementors may want to actively avoid
>closely tracking the standard. They don't want people to get in the
>habit of writing portable C2023; they want to people to get into the
>habit of writing code that relies on version 5.1.15 of the brand X
>implementation of C.

And then there is inertia. A million lines of code that works with
C90, C99 or C11 isn't going to be rewritten to use C23 features for
decades, if ever.

Then there is binary compatability with third party libraries. The
synopsys libraries, for example, are generally built against earlier
versions of the compilers and thus the C23 features are completely
uninteresting to that set of compiler users.

Then there are distribution constraints - if someone is using RedHat
enterprise linux 6, 7 or 8, they're not likely to download and build
a newer compiler version; rather they're dependent on whichever
versions redhat/ibm provides that are compatable with their third-party
libraries.

It was only in the last two years that the infrastructure in the
company was ready to support using C++11 features in our products.

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>James Kuyper wrote:
>
>> The first version of the C standard was the one adopted most quickly. It
>> became standard in 1990, but code relying upon that standard did not
>> qualify as "portable" until at least a decade later. Adoption of the
>> 1999 version of the standard was much slower. There's still a fair
>> number of people who refuse to use any version of C later than C90.
>> Subsequent versions of C haven't been adopted any faster than that one.
>> Yet, you expect code relying upon features that are new in C2023 to
>> become fully portable in only a year?
>
>Portability to obsolete systems does not matter.
>

Only in blue-maned hawk fantasy land.

On 14/10/2023 04:14, Blue-Maned_Hawk wrote:
> Keith Thompson wrote:
>
>> I don't know what was unclear. You seem to expect universal adoption of
>> the C23 standard by 2024. Given the adoption speed of previous editions
>> of the C standard, that's completely unrealistic.
>
> I can't see why an implementation wouldn't adopt C23 if it didn't want to
> be considered obsolete.
>

You are mixing different things.

The two main C implementations - gcc and clang - already support a lot
of C23. Indeed, the policy of the C standards committee is to encourage
(or even require) adoption and testing in real compilers before
standardising a feature, often it only requires small changes to
implement new language or library features in at least one of these
compilers. So you can expect fairly complete C23 implementations
shortly after the official standards publication.

But the vast majority of developers don't use the latest versions of
these tools. They use versions that come with their Linux distribution,
or mingw, or their microcontroller manufacturer's development tools, or
other pre-build toolchains. And /those/ are not updated anywhere near
as quickly. In a graph of gcc version versus user count, the median
might be a 4 or 5 years old version.

Then there are the developers themselves - they take time to change,
even when their tools support newer standards. This is particularly
true for C - perhaps the biggest single selling point of the language is
its long-term stability, and users are often conservative about new
standards. (Compare that to C++, where new standards are used much
sooner.) I believe that the solid majority of people who actively
consider and choose which C standard to use (as distinct from "whatever
the compiler gives me") use C99 or even C90, rather than C11 or C17.

I would expect C23 adoption to be a little faster than C11 and C17,
since it has a good deal more new to offer (even if people don't use all
the new features). But real-world use of C23 will definitely lag
cutting-edge compiler implementation of the standard by a long way.

On Saturday, October 14, 2023 at 2:34:26 AM UTC+3, James Kuyper wrote:
> On 10/13/23 18:02, Blue-Maned_Hawk wrote:
> > James Kuyper wrote:
> >
> >> On 10/12/23 09:42, Blue-Maned_Hawk wrote:
> >>> Keith Thompson wrote:
> >>>
> >>>> A solution that depends on a header that's introduced in C23, a
> >>>> standard that hasn't been published yet, is hardly portable.
> >>>
> >>> Well, it will be in 2024.
> >>
> >> You expect the new standard to be widely adopted so much quicker than
> >> any previous version? Why?
> >
> > What?
> The first version of the C standard was the one adopted most quickly. It
> became standard in 1990, but code relying upon that standard did not
> qualify as "portable" until at least a decade later. Adoption of the
> 1999 version of the standard was much slower. There's still a fair
> number of people who refuse to use any version of C later than C90.
> Subsequent versions of C haven't been adopted any faster than that one.
> Yet, you expect code relying upon features that are new in C2023 to
> become fully portable in only a year?

I got an impression that by now C11 is adapted wider than C99.
But I have no proof.

On 10/14/2023 7:49 AM, Scott Lurndal wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 10/13/23 22:14, Blue-Maned_Hawk wrote:
>>> Keith Thompson wrote:
>>>
>>>> I don't know what was unclear. You seem to expect universal adoption of
>>>> the C23 standard by 2024. Given the adoption speed of previous editions
>>>> of the C standard, that's completely unrealistic.
>>>
>>> I can't see why an implementation wouldn't adopt C23 if it didn't want to
>>> be considered obsolete.
>>
>> That shows a lack of imagination. Many implementations have routinely
>> chosen to remain "obsolete" for many years after a given version of the
>> standard was approved. Typical reasons include a customer base that is
>> either not ready yet to make use of the new features, or in many cases,
>> are actively opposed to using them. As I pointed out earlier, there are
>> people who still refuse to use anything more recent than C90 - several
>> of them post to this newsgroup regularly. Updating the implementation to
>> only optionally support the new features seems an obvious solution, but
>> it takes time and costs money, and will be a low priority if their
>> customers have no particular interest in using those features.
>>
>> Another common problem is implementations that have a really large
>> customer base, who have ambitions to acquire a large market share by
>> locking their customers into using proprietary extensions provided only
>> by their implementation. Such implementors may want to actively avoid
>> closely tracking the standard. They don't want people to get in the
>> habit of writing portable C2023; they want to people to get into the
>> habit of writing code that relies on version 5.1.15 of the brand X
>> implementation of C.
>
> And then there is inertia. A million lines of code that works with
> C90, C99 or C11 isn't going to be rewritten to use C23 features for
> decades, if ever.

A bit of sarcastic comic relief. Tell chatgpt to rewrite the the
codebase to use C23 features and produce the same results. Cross your
fingers, then jump off a bridge. Yikes!

>
> Then there is binary compatability with third party libraries. The
> synopsys libraries, for example, are generally built against earlier
> versions of the compilers and thus the C23 features are completely
> uninteresting to that set of compiler users.
>
> Then there are distribution constraints - if someone is using RedHat
> enterprise linux 6, 7 or 8, they're not likely to download and build
> a newer compiler version; rather they're dependent on whichever
> versions redhat/ibm provides that are compatable with their third-party
> libraries.
>
> It was only in the last two years that the infrastructure in the
> company was ready to support using C++11 features in our products.

On 10/14/2023 7:50 AM, Scott Lurndal wrote:
> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>> James Kuyper wrote:
>>
>>> The first version of the C standard was the one adopted most quickly. It
>>> became standard in 1990, but code relying upon that standard did not
>>> qualify as "portable" until at least a decade later. Adoption of the
>>> 1999 version of the standard was much slower. There's still a fair
>>> number of people who refuse to use any version of C later than C90.
>>> Subsequent versions of C haven't been adopted any faster than that one.
>>> Yet, you expect code relying upon features that are new in C2023 to
>>> become fully portable in only a year?
>>
>> Portability to obsolete systems does not matter.
>>
>
> Only in blue-maned hawk fantasy land.

Humm... For some god damn reason Blue-Maned_Hawk is giving me visions of
Bonita. Strange.

Chris M. Thomasson wrote:

> Humm... For some god damn reason Blue-Maned_Hawk is giving me visions of
> Bonita. Strange.

Wasn't Bonita the CXX proselytizer? Don't compare me with them.

--

James Kuyper wrote:

> On 10/13/23 22:15, Blue-Maned_Hawk wrote:
>>
>> <snip/>
>>
>> Portability to obsolete systems does not matter.
>
> It does if those systems are widely used, despite being "obsolete", as
> is very often the case. Keep in mind that many of the people using these
> systems would not consider them "obsolete" until they are at least two
> or more versions behind the standard.

Then it sounds like their definitions of obsoletion are pointless.

--

On 10/14/2023 11:45 AM, Blue-Maned_Hawk wrote:
> Chris M. Thomasson wrote:
>
>> Humm... For some god damn reason Blue-Maned_Hawk is giving me visions of
>> Bonita. Strange.
>
> Wasn't Bonita the CXX proselytizer? Don't compare me with them.

Sorry about that. I did not mean to be so mean to you. Bonita is a,
well... For some reason, when I think about Bonita I can hear toilets
flushing in the background... Toilets flushing all the way down, down,
down....

David Brown wrote:

>
> <snip/>
>
> The two main C implementations - gcc and clang - already support a lot
> of C23. Indeed, the policy of the C standards committee is to encourage
> (or even require) adoption and testing in real compilers before
> standardising a feature, often it only requires small changes to
> implement new language or library features in at least one of these
> compilers. So you can expect fairly complete C23 implementations
> shortly after the official standards publication.
>
> But the vast majority of developers don't use the latest versions of
> these tools. They use versions that come with their Linux distribution,
> or mingw, or their microcontroller manufacturer's development tools, or
> other pre-build toolchains.

Then that sounds like a problem with those toolchains.

--

James Kuyper wrote:

> Many implementations have routinely chosen to remain "obsolete" for many
> years after a given version of the standard was approved.

That sounds like their problem.

--

On 10/14/23 14:53, Blue-Maned_Hawk wrote:
> James Kuyper wrote:
>
>> Many implementations have routinely chosen to remain "obsolete" for many
>> years after a given version of the standard was approved.
>
> That sounds like their problem.

Code which requires support for more recent features of the C standard
isn't portable to those implementations, but that's not a problem for
them, because their customers don't feel a need to use those features.
It is, however, a problem for any claim that code using those features
is widely portable.

On 10/14/23 14:53, Blue-Maned_Hawk wrote:
> David Brown wrote:
....
>> But the vast majority of developers don't use the latest versions of
>> these tools. They use versions that come with their Linux distribution,
>> or mingw, or their microcontroller manufacturer's development tools, or
>> other pre-build toolchains.
>
> Then that sounds like a problem with those toolchains.

If the users of those toolchains aren't interested in using newer
versions, how is that a problem? Believe me, if a significant fraction
of their users do want support for a newer version of the standard, it
will be provided.

On 10/14/23 14:46, Blue-Maned_Hawk wrote:
> James Kuyper wrote:
....
>> It does if those systems are widely used, despite being "obsolete", as
>> is very often the case. Keep in mind that many of the people using these
>> systems would not consider them "obsolete" until they are at least two
>> or more versions behind the standard.
>
> Then it sounds like their definitions of obsoletion are pointless.

No, their definitions are tuned to their needs, which do not include
always using the latest version of the standard. They consider a version
of the standard obsolete only when it lacks a feature that's important
to them which was introduced in a newer version.

candycanearter07 <no@thanks.net> writes:

> On 10/11/23 02:27, Anton Shepelev wrote:
>
>> candycanearter07:
>>
>>> What is the best/most portable way to get the highest bit
>>> set?
>>>
>>> ie. 011010001
>>> to 010000000
>>
>> What is your best attempt, even if unsuccessful?
>
> int out;
> for(out = 0x100000000; out; out >> 1)
> if(out & input) break;
>
> I'm trying to find something size independent, though.
> Or at least able to be swapped out with a #define

There have been several serious solutions posted
by now. Have you seen one that meets your needs?

jak <nospam@please.ty> writes:

> unsigned long h_bit(unsigned long val)
> {
> int i;
> for(i = 0; val > 1; val /= 2, i++);
> return val << i;
> }

A nice compact solution. I like the way it
naturally deals with the case when val is zero.

Anton Shepelev <anton.txt@gmail.moc> writes:

> Tim Rentsch:
>
>> Before giving any comment on the algorithm, I'd like to
>> ask a question about layout style. Your code follows the
>> unusual practice of starting controlled blocks with an
>> open brace at the start (possibly indented) of a line, and
>> the first code line of the block on the same line as the
>> open brace. Is this practice something you started by
>> yourself, or did you see it and adopt it from somewhere
>> else? What kinds of reasons persuaded you to follow it?
>
> I was bothered by the unaligned braces in K&R and by the
> too-sparse look of the opening brace on a line of its own.
> When a friend of mine was working on a coding style
> guide[1], he researched exising indentaion styles and told
> me about them, including Horstmann:
>
> <https://en.wikipedia.org/wiki/Indentation_style#Horstmann_style>
>
> whence I took the main idea of placing braces.

Thank you for the explanation. I myself would never
use this layout style but I try to understand why
other people makes the choices they do.

I should be responding again, hopefully soonish, to your post
upthread to say something about that code.

Anton Shepelev <anton.txt@gmail.moc> writes:

> Tim Rentsch about my code:
>
>> I'm at a loss for words.
>
> What, no one did worse?

It was just too much work to figure out something
useful to say. So all I could think of was to
say I'm at a loss as to how to respond.

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:

> James Kuyper wrote:
>
>> On 10/13/23 22:15, Blue-Maned_Hawk wrote:
>>
>>> <snip/>
>>>
>>> Portability to obsolete systems does not matter.
>>
>> It does if those systems are widely used, despite being "obsolete",
>> as is very often the case. Keep in mind that many of the people
>> using these systems would not consider them "obsolete" until they
>> are at least two or more versions behind the standard.
>
> Then it sounds like their definitions of obsoletion are pointless.

The word obsolete means no longer used or no longer useful. If
someone is still using it then by definition it is not obsolete.

Tim Rentsch ha scritto:
> jak <nospam@please.ty> writes:
>
>> unsigned long h_bit(unsigned long val)
>> {
>> int i;
>> for(i = 0; val > 1; val /= 2, i++);
>> return val << i;
>> }
>
> A nice compact solution. I like the way it
> naturally deals with the case when val is zero.
>

This is not true because if Val is 0 also the bit shifted to left is,
so also its result is 0. This one of the reason why the exit from the
loop is greater than 1.