Thursday, February 11, 2021

Digest for comp.lang.c++@googlegroups.com - 25 updates in 8 topics

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 04 02:34PM -0500

On Thu, 4 Feb 2021 18:13:22 +0000
> Your Christian-centric bigotry is racist, homophobic and misogynist
> and hurts people of colour, the LGBTQ+ community and women.
 
Let's examine this.
 
> Your Christian-centric bigotry
 
There is no bigotry. Christians reach out to all people in love. Even
homosexuals from Great Britain. What we teach is what God has told us
about what HE WILL JUDGE one day. The Christian reaches out to prevent
people from being judged. We want everyone to come to repentance, ask
forgiveness, and enter into eternity alive.
 
That is love applied to life, even in the face of such hatred as that
which comes you and others, Leigh.
 
> is racist
 
There is no racism. Jesus opens His arms upon that cross to receive
everybody. What Christians do is congregate together with people who
have common viewpoints founded in Biblical Christianity.
 
Why? Because God's Holy Spirit is real, and so is the anti-Christ
spirit that's running loose in the world everywhere leading people
astray by its false teachings. Christians are instructed to separate
ourselves from the world, and that necessarily means teaching others
why because it's obvious aspect of our lives.
 
We do not do it for racist reasons. We do it for spiritual ones.
 
> homophobic
 
How many times have I reached out to you in friendship, Leigh. I've
told you I like you, that I think we're actually much more alike than
we are unlike fundamentally, and that the issue between is solely one
of the heart.
 
> misogynist
 
Absolute insanity. Did you know that God Himself exalted women when He
let His own begotten Son be born through an earthly woman, a lowly
little probably 13-yr old girl. She was honored to fulfill this role,
and gave her approval of it after being visited by the angel.
 
What is misogynist in our society is this "woman's rights" movement.
It removes women form their exalted place of homemaker, mother,
caregiver, the emotional foundation of the home, and places her out
there among the wolves on a daily basis. She learns to drink and smoke
and cuss and be just as vial as wicked men are.
 
"My body, my choice!" What kind of ridiculousness is that!? This is
the worldly-based God-hating idea of feminism wrapped into the murder
of the most precious thing God's ever given us: new life born through
us, and for us, and for Him.
 
This world is completely anti-woman. Destroying her place of honor
given to her by God so that she was separated from man. Men used to
write poetry about women, longing to be with them for even moments, let
alone the honor of a marriage and a lifetime with kids and all that
entails.
 
God is fully pro-woman. He does separate salvation between men and
women. He also saves everyone alike. And His heart instructs men to
honor their wives, to recognize them as the weaker vessel (on average
more emotional, physically weaker in general, and handicapped by their
cycle -- an ongoing continuous reminder, by the way, of our original
sin from Eve to Adam, and the price of blood paid by Christ at the
cross).
 
You've got it completely backwards, Leigh. Absolute blindness.
 
> hurts people of colour
 
Insanity. God is color blind. He calls out to everyone in this world.
He calls out to the downtrodden and broken, as well as to the rich and
successful.
 
Ignorant Leigh, what you identify as a problem with Christianity is not
a problem with Christianity. It's a problem with SINFUL MAN. PEOPLE
who do not follow the prescripts of God correctly, but instead listen
to that same anti-Christ spirit you're listening to, but in you it
applies toward homosexuality and rebellion and profanity and whatever
else, but with them it takes hold of their interest (a relationship
with Jesus Christ) and perverts it to be something unpalatable,
undesirable by people, something DESIGNED BY THAT EVIL SPIRIT to PUT
PEOPLE OFF to Christianity. And that enemy is very good at what he
does, which is why it takes a very strong Christian to be able to rise
up in this world and overcome that enemy properly.
 
I was taken down by that spirit in the late 2000s after having been
saved in 2004. I was a sincerely devout Christian through May of 2007,
when my family began an unprecedented attack. It hammered us daily
through the end of 2007 into 2008, and I was not strong enough to
prevent the downfall. I got involved in something that I thought at
the time was a good idea, but quickly realized it wasn't. The damage
was done to my family and we're still suffering from the side-effects
and ramifications of that decision now 12+ years later.
 
The Bible records that the enemy spirit we face is of a particular type
of genius that we can't approach him. His mind sees things on the
scale of 10s of thousands of simultaneous thoughts, whereas we can only
think our own thoughts consecutively.
 
It's why we need God to fight our battles for us, because NONE OF US
are able to fight against that enemy alone. We put our faith and trust
in Jesus Christ, and He then fights that enemy for us ... spiritually,
not physically.
 
> the LGBTQ+ community and women
 
The LGBTQ+ community is led by evil spirits. It is that very spirit
that makes people "feel gay."
 
Christians try and teach people this, but that evil spirit is present
in their physical body. It's there continuously piping thoughts,
feelings, emotions, into that physical body so that the person who is
not spiritual, is dead in sin, is only able to respond by their body's
feelings, will THINK they are having THEIR OWN thoughts, feelings, and
emotions, when in fact they're being led by the most raunchy demons out
there, as the homosexual spirit is a very very very powerful evil
spirit.
 
We try and teach people about this battle, but it's not something we
can do because unless the person is willing to seek the truth, they are
otherwise sold out to the flesh and will not hear any of it. It's like
trying to tell an addict that they need to stop taking drugs. They
might even know they need to, but they can't for the same reason, they
have an evil spirit manipulating their flesh, their thoughts, feelings,
emotions, to keep them pinned down in the destructive thing that will
lead to their soul's damnation in Hell.
 
-----
I'm sorry for whatever things have happened to you in your life, Leigh.
Mitch Alsup on the comp.arch channel was abused in church as a young
boy, and he's not in his latter years and has a hatred against
Christianity because of what that evil spirit did to him in his youth.
He cannot separate out the evil spirit attack from the true nature of
Jesus Christ, which is completely separate, entirely love, and is the
very thing which could heal all the hurt.
 
The enemy spirit dwelling within you, Leigh, is making you think all
these things falsely.
 
If you want to be set free from that falseness, ask Jesus to show you
the truth, to come to you in a way YOU can understand and believe. If
you are sincere in asking HE WILL KNOW IT and He will come to you, and
He will make the way for you to be set free. And you won't believe the
change. I speak from experience.
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Feb 05 11:28AM +0100

On 05/02/2021 04:55, Chris M. Thomasson wrote:
> and easy.
 
> calive.iso
 
> Where do I download it? Iirc, you said you would have one?
 
If you want to encourage Rick with this, please do it by email or in his
dedicated CAlive google group. (And I mean that literally - please do
support him if you think there is a future for his projects, but please
do it in appropriate ways.)
 
We've had more than enough about it here and in c.l.c., where it is
equally off-topic. And we have had more than enough of the pointless
repetitive shooting matches between Rick and Mr. Flibble. Neither of
them seems to recognize a lost cause when it is so clear to everyone else.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 04 03:01PM -0500

On Thu, 4 Feb 2021 19:58:18 +0000
> And Satan invented fossils? Yes? Bigoted spammer?
 
The reason you write "And Satan invented fossils? Yes?" is because the
evil spirit you're hosting in your physical body is separating you from
the truth that would set you free from it.
 
You're being used, Leigh. That enemy spirit owns you. Are you content
to be literally owned by something that's not you? Something that's
putting all its effort into destroying your eternal soul?
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 05 12:15AM -0500

On Thu, 4 Feb 2021 20:53:52 +0000
 
> The reason I write "And Satan invented fossils? Yes?" is because it
> is a sarcastic, satirical and rhetorical question that dismisses your
> childlike creationist beliefs with little effort on my part.
 
That is exactly what that enemy spirit wants you to believe, Leigh.
 
But here's what's really happening: Jesus is seated upon His throne.
The world really is moving according to the Biblical plan. Christians
have come to the cross and met Jesus and asked forgiveness, and they
really are passing from death to life. And the warnings they give
people like you really are warnings from God through them.
 
That is truth. That is reality.
 
What the lying anti-Christ spirit wants you to believe is that you have
a handle on things when your not only really do not, but are so far
away from the truth that, unless you come to faith in this world, one
day when you stand before God in judgment you will be in awe at how
lost in sin you were, and how twisted your thinking, feelings,
emotions, beliefs, were by the influence of that lying spirit.
 
-----
You're facing a calamity, Leigh. The way out is the very thing that
enemy spirit entices you to not only dismiss, but also attack outright.
 
I care about you, Leigh. I care about all people. It's why I teach
you the truth.
 
Now consider your sign-off to me: "Now .. off." Here's my sign-off to
you: "You are loved, Leigh. Loved by God as part of His creation.
You have sin, and Jesus came to this world to forgive YOU personally,
to take on YOUR sin and set you free from the judgment you're facing
today. God loves you enough to look past your hatred of Him for all
these years. He loves you enough to still call out to you, still
desires you to be a part of His eternal Kingdom of glory and power."
 
You are beautiful and precious, Leigh. And there's a calling to a
better way for you, your life here, and in eternity. Peace.
 
--
Rick C. Hodgin
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 06 01:17PM -0800

On 2/6/2021 5:07 AM, Öö Tiib wrote:
> I am under impression that you know that too.
> IOW your asking for ISO of CAlive feels like doing
> something that you know being fruitless and purposeless.
 
Well, I hope its not 100% vaporware, or else what the heck has he been
working on? Damn.
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Feb 04 08:53PM

On 04/02/2021 20:01, Rick C. Hodgin wrote:
 
> You're being used, Leigh. That enemy spirit owns you. Are you content
> to be literally owned by something that's not you? Something that's
> putting all its effort into destroying your eternal soul?
 
The reason I write "And Satan invented fossils? Yes?" is because it is a sarcastic, satirical and rhetorical question that dismisses your childlike creationist beliefs with little effort on my part. Now fuck off.
 
/Flibble
 
--
😎
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Feb 05 03:24PM

On 05/02/2021 05:15, Rick C. Hodgin wrote:
> really are passing from death to life. And the warnings they give
> people like you really are warnings from God through them.
 
> That is truth. That is reality.
 
And Satan invented fossils, yes? Spammer?
 
/Flibble
 
--
😎
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 04 02:53PM -0500

On Thu, 4 Feb 2021 19:46:28 +0000
> > that makes people "feel gay."
 
> Bigot.
 
> [snip - tl;dr]
 
 
The truth speaks with one voice, Leigh. It doesn't have sides or
angles or scenarios where it's true. It's always true from every
examination.
 
The reason you write "[snip - tl;dr]" is because the evil spirit you're
hosting in your physical body is separating you from the truth that
would set you free from it.
 
You're being used, Leigh.
 
--
Rick C. Hodgin
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 04 07:55PM -0800

On 2/4/2021 8:41 AM, Rick C. Hodgin wrote:
>>> vast. I map out very large and complex projects that I can envision
>>> and see all of the parts for, but I am able to do them in terms of
>>> labor hours due to life things.
[...]
 
Put your CAlive on a bootable CD/DVD, provide an iso... Therefore,
people can install your OS, tools, and everything. all in one go! Nice
and easy.
 
calive.iso
 
Where do I download it? Iirc, you said you would have one?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 05 02:33PM -0800

On 2/5/2021 11:52 AM, Chris M. Thomasson wrote:
>> happens to many of them at the same instruction at the same time.
 
> You just might like this:
 
> https://youtu.be/DZJPqTTt7MA
[...]
 
Basically, calling a blocking operation while holding a mutex is bad!
Blocking while inside a RCU region is bad!
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 06 01:14PM -0800

On 2/6/2021 8:31 AM, Marcel Mueller wrote:
> can enforce this. At user level it is almost impossible to avoid
> blocking completely. Preemptive multi tasking and page faults are the
> most common reasons.
 
Fwiw, I am almost finished wrt showing a use case for my proxy gc. The
new thread will be called "The Poor Mans RCU...".
 
Basically, this one use case out of many will allow a lock-free list to
be mutated while readers are going full speed ahead wrt iterating the
whole list, while writers are pushing, popping, and deleting nodes.
 
It can be useful.
Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 05 07:43AM +0100

Am 05.02.21 um 05:22 schrieb Chris M. Thomasson:
 
> function instead of skimming. That's where a lot of the "magic" happens.
> If I am reading this correctly, there is a place where you need strong
> CAS. Wrt C++ and its weak and strong CAS variants:
 
I never heard about a weak CAS primitive before. But yes the code relies
on strong CAS. This is essential to be loop free.
 
And you should know that the code was exclusively intended for the x86
platform. x86 has very little (or no?) ability of memory reordering. So
there are no further memory barriers required when doing simple atomic
reads and writes. std::atomic should be more sophisticated.
 
 
> Afaict, this will not work with weak CAS. Need to dig into it because
> its interesting. Fwiw, in my experimental proxy collector, I was very
> happy that I eliminated the need for any CAS.
 
CAS is not bad unless it is a CAS /loop/.
Of course, if read-modify-write memory cycles of the hardware can be
used this is even better.
 
> Basically, the inner count needs to be somehow transferred to the outer
> count. Using a loopless wait-free method tends to perform better than a
> CAS.
 
It is a long time ago since I wrote this code, but AFAIR it is loopless.
The number of atomic operations per access was limited to exactly 3.
Other approaches may need only 2, but this will not work with only 2
stolen bits.
 
 
[strong thread safety]
> Well, its basically required for a thread/process to be able to take a
> reference to something that it did not previously have a reference to.
 
And this is likely to happen almost every time when you deal with an
atomic instance of some referencing object.
 
 
> Have you ever messed around with RCU? Pretty damn nice.
 
I shortly heard the first time of RCU and only read a few articles.
AFAICS it just delays deletions a bit to keep memory access valid. This
sound a bit like Thread.Sleep or setTimeout solutions. From my
experience this kind of solutions mainly move the bug from the developer
to the customer.
 
Grace periods are always too short to prevent corruption under some
special cases with extreme load peaks, e.g. with swapping and I/O delays
involved or maybe some DDOS attack (or just children trying to connect
to their school :-)
Well, at some point we need to note that computers also just happen to
work from the quantum mechanics point of view. So probability /is/ a
valid approach. But probabilities of concurrency issues mainly scale
with the number of coincidences required to trigger them not with the
time taken for the step. A single thread may always block for an unknown
reason at any point. But it is rather unlikely that this happens to many
of them at the same instruction at the same time.
 
If you reduce RCU by just versioning then I have probably used it for
decades. Atomic pointer updates and immutable data structures were the
core of the in memory database application I mentioned. But I did not
use any grace period.
The PM123 application where the code link came from also uses this
pattern for all internal strings. They are immutable and deduplicated.
 
> collector can provide a sort of "poor mans" rcu. A proxy collector can
> be created from any strong-thread safe method. Ideally lockfree, even
> better when its loopless, and waitfree.
 
I think I did not really catch the intended use case of your proxy
collector for now.
 
 
Marcel
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 05 11:52AM -0800

On 2/4/2021 10:43 PM, Marcel Mueller wrote:
>> need strong CAS. Wrt C++ and its weak and strong CAS variants:
 
> I never heard about a weak CAS primitive before. But yes the code relies
> on strong CAS. This is essential to be loop free.
 
Indeed. The "problem" we both have with loopfree is an architecture that
uses LL/SC. x86 has pessimistic atomic RMW's where a CAS failure,
actually means that it failed because the destination was not equal to
the comparand. So one can use a CAS for loopfree algorithms. However...
On a system with optimistic RMW's means that a compare_exchange_weak can
spuriously fail. This also means that compare_exchange_strong is going
to use a loop, internally. It's simply not our fault. :^)
 
 
> platform. x86 has very little (or no?) ability of memory reordering. So
> there are no further memory barriers required when doing simple atomic
> reads and writes. std::atomic should be more sophisticated.
 
Completely understood. Well, actually... x86 does require an explicit
membar in the form of MFENCE or a LOCK'ed RMW to implement certain
algorithms. One example is the hazard pointer algorihtm. It depends on a
store followed by a load to another location. This can be reordered on
an x86. Are you familiar with hazard pointers?
 
 
 
> CAS is not bad unless it is a CAS /loop/.
> Of course, if read-modify-write memory cycles of the hardware can be
> used this is even better.
 
Yup. I have wrote about this in the past about how loopless algorithms
can tend to lose their "luster" when implemented on an arch that uses
optimistic RMW's, like when CAS is implemented in terms of LL/SC.
 
 
> The number of atomic operations per access was limited to exactly 3.
> Other approaches may need only 2, but this will not work with only 2
> stolen bits.
 
Your algorihtm is loopless on x86, and SPARC, and on some others.
However, on a system with LL/SC, not so much. This is just the way it
is. Shit happens.
 
 
>> reference to something that it did not previously have a reference to.
 
> And this is likely to happen almost every time when you deal with an
> atomic instance of some referencing object.
 
It basically depends on the program, and how it accesses things. Some
programs simply do not require strong thread safety.
 
 
> sound a bit like Thread.Sleep or setTimeout solutions. From my
> experience this kind of solutions mainly move the bug from the developer
> to the customer.
 
What bug? RCU uses nothing like a sleep or timeout.
 
 
> special cases with extreme load peaks, e.g. with swapping and I/O delays
> involved or maybe some DDOS attack (or just children trying to connect
> to their school :-)
 
RCU's not really "ideal" for data-structures with high amounts of
updates. However, its not going to break because of them.
 
 
> time taken for the step. A single thread may always block for an unknown
> reason at any point. But it is rather unlikely that this happens to many
> of them at the same instruction at the same time.
 
You just might like this:
 
https://youtu.be/DZJPqTTt7MA
 
 
>> lockfree, even better when its loopless, and waitfree.
 
 
> I think I did not really catch the intended use case of your proxy
> collector for now.
 
My proxy collector use case is basically the same use case as RCU.
Readers can read, while writers are mutating the data structure, even
deleting things. Actually, it might be better than RCU in high writer
use cases. Humm...
Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 06 05:20PM +0100

Am 05.02.21 um 22:00 schrieb Chris M. Thomasson:
 
>     return;
> }
> _______________________________
 
People called this cooperative multi-tasking in the past. ;-)
 
 
Marcel
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 04 08:22PM -0800

On 2/3/2021 12:00 AM, Marcel Mueller wrote:
 
> I am not 100% sure about the UB. std::atomic<uintptr_t> might solve the
> UB problem with stolen bits. I did not test this, because with a defined
> set of target platforms there was no UB.
 
std::atomic<uintptr_t> just might do it, and also allow me to give it a
go in Relacy. I should have some free time in a day or two. I need to
_really_ dig into your:
 
/// Strongly thread safe read
T* acquire() volatile const;
 
function instead of skimming. That's where a lot of the "magic" happens.
If I am reading this correctly, there is a place where you need strong
CAS. Wrt C++ and its weak and strong CAS variants:
 
InterlockedCxc in line 281:
 
if (InterlockedCxc((volatile unsigned*)&Data, old_outer, new_outer) !=
old_outer && new_outer)
// Someone else does the job already => undo.
InterlockedAdd(&((T*)new_outer)->access_counter(), outer_count);
// The global count cannot return to zero here, because we have an
active reference.
 
 
Afaict, this will not work with weak CAS. Need to dig into it because
its interesting. Fwiw, in my experimental proxy collector, I was very
happy that I eliminated the need for any CAS.
 
https://pastebin.com/raw/p1E9WN5i
 
 
>>> boost::intrusive_ptr prevented strong thread safety. A reference
>>> counter need to be exposed as atomic<some_integer> somehow for strong
>>> thread safety.
 
Basically, the inner count needs to be somehow transferred to the outer
count. Using a loopless wait-free method tends to perform better than a CAS.
 
 
> programming significantly. Less race conditions, no deadlocks, no
> priority inversion. Basically it is required for anything pointer like
> object to fit into a std:atomic<T>.
 
Well, its basically required for a thread/process to be able to take a
reference to something that it did not previously have a reference to.
 
 
> the more effectively deduplication compresses it.
> Without strong safety any read access needs to be protected by a lock.
> This is almost impossible without introducing a bottleneck.
 
Have you ever messed around with RCU? Pretty damn nice. A proxy
collector can provide a sort of "poor mans" rcu. A proxy collector can
be created from any strong-thread safe method. Ideally lockfree, even
better when its loopless, and waitfree.
 
 
> with an in memory DB anyway.)
> The efficiency was so high that we decided to keep the full change
> history of ten years. It just takes only little additional resources.
 
Excellent!
 
 
 
> :-)
 
> More likely they simply discard google groups in the future. There is no
> profit in this service.
 
Iirc, that the reason why they totally murdered Google+. Damn.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 04 09:09PM -0800

On 2/3/2021 12:00 AM, Marcel Mueller wrote:
>>> performs even better on 64 bit because you can safely use 3 bits. I
>>> am unsure if it can be implemented without introducing UB - although
>>> it is likely to work on any real hardware.
[...]
 
Humm... I did a another proxy collector, old and nowhere on the net now
since Comcast killed their webhosting, that used stolen bits for the
collectors. Was worried about overflowing them. Wrt, Line 273 in your code:
 
const unsigned old_outer = InterlockedXad((volatile unsigned*)&Data, 1) + 1;
const unsigned outer_count = old_outer & INT_PTR_COUNTER_MASK;
ASSERT((old_outer & INT_PTR_COUNTER_MASK) != 0); // overflow condition
 
The assert is here for that right? What am I missing?
 
The fun part about a proxy collector is that it is not a general purpose
smart pointer. Instead its more of a poor mans rcu where we can steal a
lot of bits by aligning a collector on a large boundary.
 
If the number of threads that take concurrent access to a strong
reference exceeds the stolen bits at any one time, then overflow can and
will occur. This condition will intrude on the actual pointer part,
corrupting things. Well, that's the way it was with my old code using
stolen bits as a reference count.
 
Please correct me if I am missing something from your acquire function.
Thanks.
Melzzzzz <Melzzzzz@zzzzz.com>: Feb 11 08:50AM

This morning I had ghost bug as simply assignment of variable
to structure member caused access violation without obvious
reason.
Name of structure is Data. That name. Same name Microsoft
has in stdafx header, and they don't use namespaces.
That will teach me that I should use anonimous namespaces.
I hadn't got single warning about this, and puzzlingly
there is another Data in another cpp file which didn't
caused problem. Sheesh 5 hours of debugging...
 
--
current job title: senior software engineer
skills: x86 aasembler,c++,c,rust,go,nim,haskell...
 
press any key to continue or any other to quit...
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 11 12:34AM -0800

https://paulmck.livejournal.com
 
He is hyper smart... Big time.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 11 12:36AM -0800

On 2/11/2021 12:34 AM, Chris M. Thomasson wrote:
> https://paulmck.livejournal.com
 
> He is hyper smart... Big time.
 
My Poor Mans RCU example is showing how to basically torture RCU in a
horrible way by flooding it with writes... rcutorture...
Manfred <noname@add.invalid>: Feb 08 01:39PM +0100

On 2/8/2021 1:50 AM, Richard Damon wrote:
>> the data types also? I've not run into any problems with it the
>> way it is, but don't have a lot of external users:
 
> The primary effect of the extern "C" is on function definitions.
 
s/definitions/declarations/
 
It
 
> I would need to study things more carefully to be sure that a C++
> implantation couldn't make it cause a difference, but I suspect most
> platform ABIs define things well enough to not allow it either.
 
One example that comes to mind is function pointers as struct members.
Since the entire header, including functions and types, constitutes the
interface to the module, I'd say that it's probably a good idea to
handle both as part of one entity and 'extern "C"' all of it.
 
An additional issue is that, unless all structs have their members
carefully ordered by decreasing size, some provision to enforce their
proper member alignment would be in order.
Manfred <noname@invalid.add>: Feb 07 09:04PM +0100

On 2/7/21 7:57 PM, Anton Shepelev wrote:
> kept thinking of .c and .h files as the interface and
> implentation parts of a Modula module, which they are not.
> Thanks for the suggestion.
 
While you're at it, you may want to bracket the C declarations in the
header file with
 
#ifdef __cplusplus
extern "C" {
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)