Saturday, February 11, 2023

Digest for comp.lang.c++@googlegroups.com - 13 updates in 4 topics

Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Feb 10 04:06PM -0800

I've run a desktop PC program (x86_64 MS-Windows) through the 'gdb' debugger and I can clearly see that it segfaults when it reads the value of 'errno'.
 
To try understand what's going on, I wrote a minimal program:
 
#include <errno.h>
 
int main(void)
{
return errno;
}
 
and then I compiled it with "-E -P" to get the preprocessor output:
 
extern int *__errno_location (void) __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__const__));
 
int main(void)
{
return (*__errno_location ());
}
 
So, 'errno' is the dereferencing of the return_value from the invocation of a function.
 
So to get a segfault here, either '_errno_location' is a nullptr or invalid pointer, or the return value from its invocation is a nullptr or invalid pointer.
 
Anyone ever seen 'errno' cause a segfault?
gazelle@shell.xmission.com (Kenny McCormack): Feb 11 12:29AM

In article <aea44a82-92d5-4b04-a065-259babb5ea7en@googlegroups.com>,
> return errno;
>}
 
>and then I compiled it with "-E -P" to get the preprocessor output:
 
It works OK for me. I note that you posted in C++, but this looks like a
pure C issue. Just to be clear, are you implying that it is a C++only
problem?
 
Anyway, here is my test program (running on Linux, with tcc):
 
#!/usr/bin/tcc -run
 
#include <errno.h>
#include <fcntl.h>
 
int main(void)
{
/* With this line, returns 2, without it, returns 0 */
int fd = open("/tmp/golisdf",0);
return errno;
}
 
Note: I'm not saying this is conclusive; just that I could not replicate
your issue. Generally, it should work, but it may be a Windows thing, it
could be a C++ thing, it might be a (whatever compiler you used) issue. It
could be lots of things.
 
Also, we are all aware that errno got changed recently for compatibility
reasons with threads. I don't know if tcc has that change or not.
 
--
I voted for Trump because I thought he'd make pussy grabbing legal.
I honestly don't see any other way America could be made great again.
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Feb 10 05:00PM -0800

On Saturday, February 11, 2023 at 12:29:39 AM UTC, Kenny McCormack wrote:
> could be lots of things.
 
> Also, we are all aware that errno got changed recently for compatibility
> reasons with threads. I don't know if tcc has that change or not.
 
 
I found the problem. One of the header files contains:
 
#define errno (*bb_errno)
gazelle@shell.xmission.com (Kenny McCormack): Feb 11 03:26AM

In article <b46f4f9e-909d-4f7a-953e-81416131ad91n@googlegroups.com>,
>> reasons with threads. I don't know if tcc has that change or not.
 
>I found the problem. One of the header files contains:
 
> #define errno (*bb_errno)
 
So your compiler (still not specified) has a bug, right?
 
--
Trump - the President for the rest of us.
 
https://www.youtube.com/watch?v=JSkUJKgdcoE
Paavo Helde <eesnimi@osa.pri.ee>: Feb 11 10:39AM +0200

11.02.2023 02:06 Frederick Virchanza Gotham kirjutas:
> {
> return (*__errno_location ());
> }
 
All this trickery is there because errno predates threads, and needs
jumping through some hoops nowadays to get it thread-local.
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Feb 11 07:17AM -0800

On Saturday, February 11, 2023 at 3:26:53 AM UTC, Kenny McCormack wrote:
 
> >I found the problem. One of the header files contains:
 
> > #define errno (*bb_errno)
> So your compiler (still not specified) has a bug, right?
 
 
I'm combining three programs together, ssh + tun2socks + route, to create a program that can connect to an SSH server and establish a VPN connection to it, even if you don't have admin rights on the remote server. I took the code for 'route' from busybox, and it references a variable called "bb_errno" which I presume must start out as a nullptr -- I haven't checked yet.
gazelle@shell.xmission.com (Kenny McCormack): Feb 11 04:08PM

In article <79a3567f-71ae-4c7f-bd3b-8a45fb14a8dfn@googlegroups.com>,
>server. I took the code for 'route' from busybox, and it references a
>variable called "bb_errno" which I presume must start out as a nullptr
>-- I haven't checked yet.
 
Ah, yes. That makes sense. Now we know what the 'bb' stands for.
 
By the way, are these programs you are merging written in C or C++?
Just askin'...
 
--
Republican Congressman Matt Gaetz claims that only ugly women want
abortions, which they will never need since no one will impregnate them.
David Brown <david.brown@hesbynett.no>: Feb 11 05:25PM +0100

On 11/02/2023 09:39, Paavo Helde wrote:
>> }
 
> All this trickery is there because errno predates threads, and needs
> jumping through some hoops nowadays to get it thread-local.
 
It's worth noting that "errno" has always (at least since C90, I
believe) been specified as being allowed to be a macro, precisely so
that implementations can do things like make it thread-local.
scott@slp53.sl.home (Scott Lurndal): Feb 11 05:08PM

> return (*__errno_location ());
>}
 
>So, 'errno' is the dereferencing of the return_value from the invocation of a function.
 
In a multithreaded application errno must refer to thread-private
data, so that each thread has its own copy of errno (which is a global
variable). To support that, errno is a macro that expands to a
function that returns the address of the thread-specific version of
errno.
 
If it's invalid, it likely means your application did not correctly
call the functionality to initialize the C or Thread library state;
this normally happens during the C runtime (CRT) support that runs
before the function main in the application is invoked.
Paavo Helde <eesnimi@osa.pri.ee>: Feb 11 10:14PM +0200

11.02.2023 17:17 Frederick Virchanza Gotham kirjutas:
 
>>> #define errno (*bb_errno)
>> So your compiler (still not specified) has a bug, right?
 
> I'm combining three programs together, ssh + tun2socks + route, to create a program that can connect to an SSH server and establish a VPN connection to it, even if you don't have admin rights on the remote server. I took the code for 'route' from busybox, and it references a variable called "bb_errno" which I presume must start out as a nullptr -- I haven't checked yet.
 
The busybox header which redefines errno contains these claims:
 
/* Busybox does not use threads [...]
[...] no multithreading in busybox :) */
 
 
So good luck with getting it run as a thread in your proposed
multithreaded composite application! The bb_errno trick seems to be just
one of their unneeded premature optimizations, so you should feel at home!
Andrey Tarasevich <andreytarasevich@hotmail.com>: Feb 10 08:53PM -0800

On 02/07/23 11:00 AM, Manu Raju wrote:
> Some of you might be interested in this paper by Amazon Engineer:
 
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p0342r1.pdf>
 
We have already seen issues of that same general nature previously with
thread synchronization primitives. Before the proper memory fencing was
introduced into the language there was no guarantee that
 
mutex.lock();
<access to the resource>
mutex.unlock();
 
would not get reordered into
 
<access to the resource>
mutex.lock();
mutex.unlock();
 
thus defeating the synchronization. Back in C++98 times volatile access
was used as a workaround to introduce observable behavior and force the
desired sequencing.
 
Apparently, a more general mechanism is needed for sequence fencing not
tied to memory access.
 
--
Best regards,
Andrey
Richard Damon <Richard@Damon-Family.org>: Feb 10 08:02PM -0500

On 2/10/23 12:02 PM, Scott Lurndal wrote:
> program that Frederick is proposing, which may require that he
> rethink the application and perhaps disaggregate the worker
> parts of the application from the display management elements.
 
I would think the simple answer is make the GUI process as bullet proof
as possible and not need to do things that need these Mutexes, but spin
up killable processes to do the work which sends answers back on
something like a pipe to the GUI.
 
If a computation process hangs, you can then just kill it and restart,
maybe letting the user know things are running slow.
Andrey Tarasevich <andreytarasevich@hotmail.com>: Feb 10 04:19PM -0800

> Can anyone explain the "official" explanation from whichever standard as to
> why the first assignment only compiles in C++ but not C:
 
Because C is not C++, and C++ is not C.
 
This is one of the fundamental core differences between the languages,
which is present in all potentially applicable contexts. You just
stumbled upon one of them - the `?`: operator. There are others:
 
* Assignment (and compound assignment) in C++ preserves lvalue-ness of
the result
 
int a, b = 1;
(a = b) = 2;
// Invalid in C, valid in C++
// (and starting from C++11 the behavior is well-defined)
 
* Prefix increment and decrement in C++ preserves lvalue-ness of the result
 
int i = 0;
++(++i);
// Invalid in C, valid in C++
// (and starting from C++11 the behavior is well-defined)
 
C language from the very beginning never cared about preserving the
lvalue-ness of expression results. In C dereference operator (unary `*`)
and its direct derivatives (e.g. `[]` and `->`) are the only operators
that produce lvalue results. Everything else produces rvalues.
 
C++ completely abandoned and reworked that approach. C++ does the
opposite: it goes to great lengths in order to preserve lvalue-ness of
the result whenever possible. You can see it especially well with `?:`
operator where lvalue-preservation is obviously tricky, since the types
(and value categories) of the second and third operands might not match.
The behavior of `?:` in C++ is defined by a long set of rather
convoluted rules, which depend on how well the types and categories of
the second and third operands match. This illustrates how much effort
C++ is willing to spend on preserving something that C just discarded
nonchalantly.
 
On can possibly argue that the rationale behind this is introduction of
reference types in C++ (and I'd say that references is just small part
of the story), but the bottom line here is that C and C++ are languages
that adhere to diametrically opposite philosophies wrt that core issue.
These are two completely different languages. The matter can only seem
surprising to those who believe in silly myths, like "C is subset of
C++" and such.
 
--
Best regards,
Andrey
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)