Sunday, August 28, 2022

Digest for comp.lang.c++@googlegroups.com - 15 updates in 5 topics

olcott <NoOne@NoWhere.com>: Aug 28 02:47PM -0500

Since Turing machines are mathematical objects that only exist in the
mind people can have contradictory thus incoherent ideas about these
abstract mathematical objects and never realize that their ideas are
incoherent.
 
When we study the theory of computation using physically existing
machines such as the x86 architecture then the incoherent abstract ideas
are shown to be incoherent in that they cannot be physically implemented.
 
void Px(ptr x)
{
H(x, x);
return;
}
 
int main()
{
Output("Input_Halts = ", H(Px, Px));
}
 
If a decider must always return a value whenever it is called this
requires H to return a value to Px even though H is called in infinite
recursion.
 
This even requires that the function call from Px to H(Px,Px) must
return a value to Px even if this function call to H is not even
executed. In the physical model of computation it is an axiom the
programs that are not executed never return values because it is
physically impossible.
 
When simulating halt decider H sees that Px is about to call H(Px,Px) in
infinite recursion H aborts its simulation of Px before this call is
executed.
 
*Clearly computer science is incorrect on this point*
Computer science says that H must still return a value to Px even though
the call to H is not even executed because all deciders must ALWAYS
return to their caller.
 
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Marcel Mueller <news.5.maazl@spamgourmet.org>: Aug 28 06:58PM +0200

Is there *any* scenario how this error can happen without any
constructor or destructor in the call stack?
 
 
Marcel
Richard Damon <Richard@Damon-Family.org>: Aug 28 01:12PM -0400

On 8/28/22 12:58 PM, Marcel Mueller wrote:
> Is there *any* scenario how this error can happen without any
> constructor or destructor in the call stack?
 
> Marcel
 
I can see it happening with threads (the constructor/destructor is in a
different Thread).
 
Not sure if there is any way to create or slice an object to result in
an "abstract" object.
Paavo Helde <eesnimi@osa.pri.ee>: Aug 28 08:37PM +0300

28.08.2022 19:58 Marcel Mueller kirjutas:
> Is there *any* scenario how this error can happen without any
> constructor or destructor in the call stack?
 
Sure, when you call via an invalid pointer where the object has been
already destroyed.
Lynn McGuire <lynnmcguire5@gmail.com>: Aug 27 10:40PM -0500

On 8/27/2022 5:24 PM, Thomas Koenig wrote:
>> subtracted from first: x--; *(x+i);.
 
> That's an f2c idiom, which is not valid C, AFAIK, because
> the pointer would point before the actual array.
 
While the second pointer is a bad pointer, it is not a illegal pointer.
Variables can point to anywhere, they are not illegal until referenced.
Otherwise, code would be crashing all over the place. If I malloc'd
some space, then free'd the space, and did not NULL the pointer, that
dangling pointer would crash if ever referenced (hopefully) but not if
it just hangs around.
 
I wish that C/C++ would provide some sort of pointer validation but it
does not. I keep track of my pointers for that reason and validate them
before using when I have some error prone code. In 850,000 lines of F77
and 30,000 lines of C/C++ code, I have suspicious pointers in several
areas due to programmers suballocating malloc'd space and forgetting to
nullify those suballocated pointers after freeing the allocated space.
Old code, you gotta love it.
 
Lynn
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 27 10:07PM -0700

> I malloc'd some space, then free'd the space, and did not NULL the
> pointer, that dangling pointer would crash if ever referenced
> (hopefully) but not if it just hangs around.
 
Computing a pointer before the beginning of an array causes undefined
behavior in C and C++, even if you never dereference it.
 
[...]
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
Thomas Koenig <tkoenig@netcologne.de>: Aug 28 07:50AM

>> the pointer would point before the actual array.
 
> While the second pointer is a bad pointer, it is not a illegal pointer.
> Variables can point to anywhere, they are not illegal until referenced.
 
Unfortunately not.
 
Looking at n2596.pdf, one finds under J.2, "Undefined behavior",
 
— Addition or subtraction of a pointer into, or just beyond,
an array object and an integer type produces a result that does
not point into, or just beyond, the same array object (6.5.6).
 
> Otherwise, code would be crashing all over the place.
 
Undefined behavior does not mean that the code will reliably crash.
It just says that the C standard gives no guarantee about what will
happen, and, even if it works right now, such code is at the mercy
of future compiler revisions, cosmic rays, and other forseen and
unforseen circumstances.
"Fred. Zwarts" <F.Zwarts@KVI.nl>: Aug 28 10:01AM +0200

Op 27.aug..2022 om 22:01 schreef Lynn McGuire:
 
> Yup.  So Fortran x(i) is equivalent to *(x+i-1).  Or, the x is
> subtracted from first: x--; *(x+i);.
 
> Lynn
 
I don't understand the idea of x--. Why modifying x? What happens if x
is indexed later again?
Thomas Koenig <tkoenig@netcologne.de>: Aug 28 08:14AM


>> Lynn
 
> I don't understand the idea of x--. Why modifying x? What happens if x
> is indexed later again?
 
The idea is to use this modified pointer for one-based array
accesses, so that it would be possible to translate Fortran's A(1)
into a[1] on the C side, or A(N) into a[n].
 
The correct way to do this according to the C standard would be to
translate A(N) into a[n-1] on the C side. There are several reasons
why this might not have been done: Readability of the generated
code (although f2c code is already hard to read), because it made
the code slower with compilers of the day, and probably because it
"just worked" with the compilers.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 28 11:07AM +0200

Am 26.08.2022 um 22:49 schrieb Lynn McGuire:
 
> My Fortran starts at one.  My C++ starts at zero.  This has made my life
> hell.
 
> Lynn
 
On the CPU-level you heave the least number of calculations to
determine an address of an indexed entity if the index starts
at zero.
David Brown <david.brown@hesbynett.no>: Aug 28 11:52AM +0200

On 28/08/2022 09:50, Thomas Koenig wrote:
> happen, and, even if it works right now, such code is at the mercy
> of future compiler revisions, cosmic rays, and other forseen and
> unforseen circumstances.
 
Indeed.
 
C was designed to have as few restrictions on the hardware as it could,
while still having a minimum feature set. If you have a segmented
memory architecture (such as x86), then addresses might have a form
"segment:offset". If an array starts at offset 0, what does it mean to
have an address one before that? It might make no sense, or have
different meanings in different contexts, or require inefficient extra
instructions to get right. Some architectures pre-load information
about memory pages or segments when a pointer register is loaded,
causing trouble if it does not actually point to valid memory. Leaving
this all undefined is much simpler for everyone.
 
(The other end, one past the end of the array, is too useful in common C
idioms to leave undefined - even if it might mean that an implementation
can't use the last address in memory.)
Paavo Helde <eesnimi@osa.pri.ee>: Aug 28 07:43PM +0300

28.08.2022 06:40 Lynn McGuire kirjutas:
 
>> That's an f2c idiom, which is not valid C, AFAIK, because
>> the pointer would point before the actual array.
 
> While the second pointer is a bad pointer, it is not a illegal pointer.
 
The C++ standard (n4861) calls this "an invalid pointer value".
 
For pointers which continue to point to freed objects, it says "A
pointer value becomes invalid when the storage it denotes reaches the
end of its storage duration".
 
About invalid pointers it says:
"Indirection through an invalid pointer value and passing an invalid
pointer value to a deallocation function have undefined behavior. Any
other use of an invalid pointer value has implementation-defined behavior."
 
There is also a footnote:
"Some implementations might define that copying an invalid pointer value
causes a system-generated runtime fault."
 
So, while technically one might get away with the "x--" trick most of
the time with the linear memory addressing used by mainstream
implementations nowadays, still various diagnostic tools would mark
these as invalid pointers, causing an avalanche of errors whenever you
want to solve your actual memory access problems.
 
I guess it might also subvert automatic garbage collection which is
sometimes used with C++. There is a special case of "safely-derived"
pointer values which I suspect is made exactly for making GC possible,
and changing the pointer value to x-1 would apparently ruin this.
 
And with segmented memory, like with 16-bit x86, it might cause all kind
of surprises.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 28 11:49AM +0200

template<std::input_iterator CharInputIt, typename Callback>
requires std::is_integral_v<std::iter_value_t<CharInputIt>>
&& requires( Callback callback, CharInputIt cri ) { { callback( cri,
cri ) }; }
void linify( CharInputIt begin, CharInputIt end, Callback callback )
{
CharInputIt
scn = begin,
lineBegin;
if( scn == end ) [[unlikely]]
return;
auto checkedCallback = [&]() { if( lineBegin != scn ) callback(
lineBegin, scn ); };
for( ; ; )
for( lineBegin = scn; ; ++scn )
if( *scn == '\n' ) [[unlikely]]
{
checkedCallback();
if( ++scn == end )
return;
break;
}
else if( *scn == '\r' ) [[unlikely]]
{
checkedCallback();
if( ++scn == end || *scn == '\n' && ++scn == end )
return;
break;
}
}
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 27 11:15PM -0700

On 8/8/2022 9:43 AM, Alan Beck wrote:
 
> Shouod I be learing C,C++ or Arduino "sketch" language.
 
> I have books for all three.l
 
> Thand beforo hand
 
To C or not to C... Well, actually, I just might have to design a plugin
interface and I would want C bindings. An end user can program a plugin
in C, C++, C#, ect... I just need to design the C API and
data-structures. So, I choose to use C for the raw plugin logic API.
David Brown <david.brown@hesbynett.no>: Aug 28 11:30AM +0200

On 27/08/2022 18:44, Manfred wrote:
> within the company you work for, and your career information, which is
> often public if you are employed in a public institution, like a
> university.
 
People working at public institutions such as universities also often do
work for commercial companies. Some aspects of that are often made
public, such as which companies and universities are working together,
while many details are generally kept private.
 
So you would expect to see information that Google has been working with
Monster University on harnessing the power of laughter. You would /not/
expect to see that Professor Plum wrote the pun generator library for
the joke engine.
 
And if neither contributing organisation is a public entity, you would
not expect to see any information at all about collaborating companies,
much less the contributions of individuals, unless both companies felt
there was significant marketing or publicity gains to be had, and both
companies agreed on it - then you'd see the information in press
releases, not developers biographies.
 
There are exceptions, of course, but that is common practice. The whole
point is that the fact that Malcolm failed to find information about
commercial software written by Jens Gustedt tells us absolutely
/nothing/ about how much commercial software he has worked on.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)