Just to keep us all up to date, none of the responses (*) so far have been
either useful or on-topic. This is not to disparage the writers of those
responses, but rather to advise other possible responders that the status
of the question is still: Open. And that any useful and topical response
from them would still be welcome and greatly appreciated.

Note that I have no interest in debating any of the topics raised by those
responders, but those posters should feel free to start threads of their
own in which these topics can be discussed, if they are so inclined.

(*) On the TIOCSTI thread.

--
Note that Oprah actually is all the things that The Donald only wishes he were.
For one thing, she actually *is* a billionaire. She's also actually self-made,
came from nothing, knows how to run businesses, never went bankrupt, is smart
and is mentally stable.

On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> (*) On the TIOCSTI thread.

TIOCSTI is a gaping, ancient security hole.

OpenBSD has removed it.

Linux merged a commit which allows TIOCSTI to be disabled.
This has discussion in the commit message.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.6&id=83efeeeb3d04b22aaed1df99bc70a48fe9d22c4d

I can easily see the default changing to disabled by default in the
future, and the thing completely disappearing.

That's all there is to it.

Don't write new code which uses this; it's not guaranteed to be there.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

In article <20231101180448.335@kylheku.com>,
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> (*) On the TIOCSTI thread.
>
>TIOCSTI is a gaping, ancient security hole.

More off-topic text. But, as noted, feel free to start a new thread to
talk all you want about it. Or anything else that happens to be on your
mind.

--
What are your thoughts on Alabama politicians declaring Donald Trump one
of the greatest presidents ever?

Alabama is ranked #47 in education out of 50 states. Now we know why.

On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <20231101180448.335@kylheku.com>,
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>> (*) On the TIOCSTI thread.
>>
>>TIOCSTI is a gaping, ancient security hole.
>
> More off-topic text. But, as noted, feel free to start a new thread to
> talk all you want about it. Or anything else that happens to be on your
> mind.

The issue is that who owns /dev/pts/N (as in the ownership and
permissions you see if you run "ls -l /dev/pts/N" don't determine
every aspect of what you can do with the TTY device.

Once open, TTY descriptor can be shared by multiple processes
which run in different security domains; it would be a bad idea
to be able to stuff input into them.

(There are other ways to stuff input, via external loopback.
That's what security holes in terminal emulators are about:
situations whereby a terminal will echo back a string sent to it.)

One kernel version (that I happen to work with) routes that ioctl
to this function:

static int tiocsti(struct tty_struct *tty, char __user *p)
{ char ch, mbz = 0;
struct tty_ldisc *ld;

if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
return -EPERM;
if (get_user(ch, p))
return -EFAULT;
tty_audit_tiocsti(tty, ch);
ld = tty_ldisc_ref_wait(tty);
if (!ld)
return -EIO;
if (ld->ops->receive_buf)
ld->ops->receive_buf(tty, &ch, &mbz, 1);
tty_ldisc_deref(ld);
return 0;
}

So the check you have discovered is done upfront before anything. If this is
not your controlling tty, and you don't have admin caps, then EPERM.

The code is the code; the reason you see the behavior is that the code is what
it is, and that is the way it is due to the security aspect of TIOCSTI.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 11/1/23 21:24, Kaz Kylheku wrote:
> On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <20231101180448.335@kylheku.com>,
>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>> On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>>> (*) On the TIOCSTI thread.
>>>
>>> TIOCSTI is a gaping, ancient security hole.
>>
>> More off-topic text. But, as noted, feel free to start a new thread to
>> talk all you want about it. Or anything else that happens to be on your
>> mind.
>
> The issue is that who owns /dev/pts/N (as in the ownership and
> permissions you see if you run "ls -l /dev/pts/N" don't determine
> every aspect of what you can do with the TTY device.
>
> Once open, TTY descriptor can be shared by multiple processes
> which run in different security domains; it would be a bad idea
> to be able to stuff input into them.
>
> (There are other ways to stuff input, via external loopback.
> That's what security holes in terminal emulators are about:
> situations whereby a terminal will echo back a string sent to it.)
>
> One kernel version (that I happen to work with) routes that ioctl
> to this function:
>
> static int tiocsti(struct tty_struct *tty, char __user *p)
> {
> char ch, mbz = 0;
> struct tty_ldisc *ld;
>
> if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
> return -EPERM;
> if (get_user(ch, p))
> return -EFAULT;
> tty_audit_tiocsti(tty, ch);
> ld = tty_ldisc_ref_wait(tty);
> if (!ld)
> return -EIO;
> if (ld->ops->receive_buf)
> ld->ops->receive_buf(tty, &ch, &mbz, 1);
> tty_ldisc_deref(ld);
> return 0;
> }
>
> So the check you have discovered is done upfront before anything. If this is
> not your controlling tty, and you don't have admin caps, then EPERM.
>
> The code is the code; the reason you see the behavior is that the code is what
> it is, and that is the way it is due to the security aspect of TIOCSTI.
>

Why does it return negative error codes?
--
user <candycane> is generated from /dev/urandom

In article <uhvfe9$1pbr3$5@dont-email.me>,
candycanearter07 <no@thanks.net> wrote:
....
>Why does it return negative error codes?

I don't know. Why don't you start a new thread where you and he can
discuss this to your mutual heart's content?

--
If your answer to the question below is any number other than 1, then you're an atheist.

Q: How many religions are worthy of respect? (i.e., how many religions are valid?)

On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
>> static int tiocsti(struct tty_struct *tty, char __user *p)
>> {
>> char ch, mbz = 0;
>> struct tty_ldisc *ld;
>>
>> if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
>> return -EPERM;
>
> Why does it return negative error codes?

That's how it works in the Linux kernel. That -EPERM will turn,
at the system call interface in the C library, into a -1 return
value from ioctl, and a positive EPERM value in errno.

The kernel cannot set errno; that's purely a user space gadget
(embroiled in threads: each thread has it own errno location).

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <uhvfe9$1pbr3$5@dont-email.me>,
> candycanearter07 <no@thanks.net> wrote:
> ...
>>Why does it return negative error codes?
>
> I don't know. Why don't you start a new thread where you and he can
> discuss this to your mutual heart's content?

The most probable answer to that that candycanearter07 already started a
subthread for that purpose, as is the long-standing prevalent practice.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 11/2/23 10:50, Kaz Kylheku wrote:
> On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <uhvfe9$1pbr3$5@dont-email.me>,
>> candycanearter07 <no@thanks.net> wrote:
>> ...
>>> Why does it return negative error codes?
>>
>> I don't know. Why don't you start a new thread where you and he can
>> discuss this to your mutual heart's content?
>
> The most probable answer to that that candycanearter07 already started a
> subthread for that purpose, as is the long-standing prevalent practice.
>

Wait, are you supposed to create a new thread or a sub thread? How do
you create a new thread replying to a message?
--
user <candycane> is generated from /dev/urandom

On 11/2/23 10:43, Kaz Kylheku wrote:
> On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
>>> static int tiocsti(struct tty_struct *tty, char __user *p)
>>> {
>>> char ch, mbz = 0;
>>> struct tty_ldisc *ld;
>>>
>>> if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
>>> return -EPERM;
>>
>> Why does it return negative error codes?
>
> That's how it works in the Linux kernel. That -EPERM will turn,
> at the system call interface in the C library, into a -1 return
> value from ioctl, and a positive EPERM value in errno.
>
> The kernel cannot set errno; that's purely a user space gadget
> (embroiled in threads: each thread has it own errno location).
>

Oh cool, is that why so many C calls return -1 on error? I always
wondered about that..
--
user <candycane> is generated from /dev/urandom

candycanearter07 , dans le message <ui0qn8$29jdn$2@dont-email.me>, a
écrit :
> Wait, are you supposed to create a new thread or a sub thread? How do
> you create a new thread replying to a message?

You reply, and the reply itself is a one-message sub-thread. Then if people
reply to the reply, it becomes the start of a non-trivial sub-thread.

candycanearter07 <no@thanks.net> writes:
>On 11/2/23 10:43, Kaz Kylheku wrote:
>> On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
>>>> static int tiocsti(struct tty_struct *tty, char __user *p)
>>>> {
>>>> char ch, mbz = 0;
>>>> struct tty_ldisc *ld;
>>>>
>>>> if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
>>>> return -EPERM;
>>>
>>> Why does it return negative error codes?
>>
>> That's how it works in the Linux kernel. That -EPERM will turn,
>> at the system call interface in the C library, into a -1 return
>> value from ioctl, and a positive EPERM value in errno.
>>
>> The kernel cannot set errno; that's purely a user space gadget
>> (embroiled in threads: each thread has it own errno location).
>>
>
>Oh cool, is that why so many C calls return -1 on error? I always
>wondered about that..

Returning -1 on system call failure dates back to the first
versions of Unix. It was standardized by SVID and ultimately
POSIX.

On 11/2/23 15:58, Scott Lurndal wrote:
> candycanearter07 <no@thanks.net> writes:
>> On 11/2/23 10:43, Kaz Kylheku wrote:
>>> On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
>>>>> static int tiocsti(struct tty_struct *tty, char __user *p)
>>>>> {
>>>>> char ch, mbz = 0;
>>>>> struct tty_ldisc *ld;
>>>>>
>>>>> if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
>>>>> return -EPERM;
>>>>
>>>> Why does it return negative error codes?
>>>
>>> That's how it works in the Linux kernel. That -EPERM will turn,
>>> at the system call interface in the C library, into a -1 return
>>> value from ioctl, and a positive EPERM value in errno.
>>>
>>> The kernel cannot set errno; that's purely a user space gadget
>>> (embroiled in threads: each thread has it own errno location).
>>>
>>
>> Oh cool, is that why so many C calls return -1 on error? I always
>> wondered about that..
>
> Returning -1 on system call failure dates back to the first
> versions of Unix. It was standardized by SVID and ultimately
> POSIX.

Cool to know!
--
user <candycane> is generated from /dev/urandom

On Thu, 02 Nov 2023 20:58:10 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>candycanearter07 <no@thanks.net> writes:
>>On 11/2/23 10:43, Kaz Kylheku wrote:
>>> On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
>>>>> static int tiocsti(struct tty_struct *tty, char __user *p)
>>>>> {
>>>>> char ch, mbz = 0;
>>>>> struct tty_ldisc *ld;
>>>>>
>>>>> if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
>>>>> return -EPERM;
>>>>
>>>> Why does it return negative error codes?
>>>
>>> That's how it works in the Linux kernel. That -EPERM will turn,
>>> at the system call interface in the C library, into a -1 return
>>> value from ioctl, and a positive EPERM value in errno.
>>>
>>> The kernel cannot set errno; that's purely a user space gadget
>>> (embroiled in threads: each thread has it own errno location).
>>>
>>
>>Oh cool, is that why so many C calls return -1 on error? I always
>>wondered about that..
>
>Returning -1 on system call failure dates back to the first
>versions of Unix. It was standardized by SVID and ultimately
>POSIX.

Though if they were going to return -1 as a fail then it would have made a lot
more sense to return the negative error and dispense with errno altogether
except where an integer error can't be returned.

And just to confuse matters, the pthreads library functions DO return the error
code but its a positive value.

Muttley@dastardlyhq.com writes:
>On Thu, 02 Nov 2023 20:58:10 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>candycanearter07 <no@thanks.net> writes:
>>>On 11/2/23 10:43, Kaz Kylheku wrote:
>>>> On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
>>>>>> static int tiocsti(struct tty_struct *tty, char __user *p)
>>>>>> {
>>>>>> char ch, mbz = 0;
>>>>>> struct tty_ldisc *ld;
>>>>>>
>>>>>> if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
>>>>>> return -EPERM;
>>>>>
>>>>> Why does it return negative error codes?
>>>>
>>>> That's how it works in the Linux kernel. That -EPERM will turn,
>>>> at the system call interface in the C library, into a -1 return
>>>> value from ioctl, and a positive EPERM value in errno.
>>>>
>>>> The kernel cannot set errno; that's purely a user space gadget
>>>> (embroiled in threads: each thread has it own errno location).
>>>>
>>>
>>>Oh cool, is that why so many C calls return -1 on error? I always
>>>wondered about that..
>>
>>Returning -1 on system call failure dates back to the first
>>versions of Unix. It was standardized by SVID and ultimately
>>POSIX.
>
>Though if they were going to return -1 as a fail then it would have made a lot
>more sense to return the negative error and dispense with errno altogether
>except where an integer error can't be returned.
>
>And just to confuse matters, the pthreads library functions DO return the error
>code but its a positive value.

The introduction of threads pretty much invalidated the idea of
a global errno, which is why all newly defined POSIX system calls
return the error number directly rather than leveraging the
legacy errno (threaded applications define errno as a thread-local
variable to accomodate the legacy system calls).

On Fri, 03 Nov 2023 16:37:16 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Thu, 02 Nov 2023 20:58:10 GMT
>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>>candycanearter07 <no@thanks.net> writes:
>>>>On 11/2/23 10:43, Kaz Kylheku wrote:
>>>>> On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
>>>>>>> static int tiocsti(struct tty_struct *tty, char __user *p)
>>>>>>> {
>>>>>>> char ch, mbz = 0;
>>>>>>> struct tty_ldisc *ld;
>>>>>>>
>>>>>>> if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
>>>>>>> return -EPERM;
>>>>>>
>>>>>> Why does it return negative error codes?
>>>>>
>>>>> That's how it works in the Linux kernel. That -EPERM will turn,
>>>>> at the system call interface in the C library, into a -1 return
>>>>> value from ioctl, and a positive EPERM value in errno.
>>>>>
>>>>> The kernel cannot set errno; that's purely a user space gadget
>>>>> (embroiled in threads: each thread has it own errno location).
>>>>>
>>>>
>>>>Oh cool, is that why so many C calls return -1 on error? I always
>>>>wondered about that..
>>>
>>>Returning -1 on system call failure dates back to the first
>>>versions of Unix. It was standardized by SVID and ultimately
>>>POSIX.
>>
>>Though if they were going to return -1 as a fail then it would have made a lot
>
>>more sense to return the negative error and dispense with errno altogether
>>except where an integer error can't be returned.
>>
>>And just to confuse matters, the pthreads library functions DO return the
>error
>>code but its a positive value.
>
>The introduction of threads pretty much invalidated the idea of
>a global errno, which is why all newly defined POSIX system calls
>return the error number directly rather than leveraging the
>legacy errno (threaded applications define errno as a thread-local
>variable to accomodate the legacy system calls).

Makes sense. Though I'd be interested in knowing what the original logic was
in returning -1 and setting a seperate error variable instead of just returning
the error directly.

candycanearter07 <no@thanks.net> writes:
> On 11/1/23 21:24, Kaz Kylheku wrote:
>> On 2023-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:

[...]

>> One kernel version (that I happen to work with) routes that ioctl
>> to this function:
>> static int tiocsti(struct tty_struct *tty, char __user *p)
>> {
>> char ch, mbz = 0;
>> struct tty_ldisc *ld;
>> if ((current->signal->tty != tty) &&
>> !capable(CAP_SYS_ADMIN))
>> return -EPERM;
>> if (get_user(ch, p))
>> return -EFAULT;
>> tty_audit_tiocsti(tty, ch);
>> ld = tty_ldisc_ref_wait(tty);
>> if (!ld)
>> return -EIO;
>> if (ld->ops->receive_buf)
>> ld->ops->receive_buf(tty, &ch, &mbz, 1);
>> tty_ldisc_deref(ld);
>> return 0;
>> }
>> So the check you have discovered is done upfront before anything. If
>> this is
>> not your controlling tty, and you don't have admin caps, then EPERM.
>> The code is the code; the reason you see the behavior is that the
>> code is what
>> it is, and that is the way it is due to the security aspect of TIOCSTI.
>
> Why does it return negative error codes?

That's the usual Linux (possibly also elsewhere) convention: Code which
doesn't really care about the specific error value can check if the
result of the function is negative. If so, an error occurred. It can
then do whatever error path processing is needed, eg, decrement
reference counts or free locks, and return the value as is to its
caller. In this way, it'll eventually be propagated to userspace.

Muttley@dastardlyhq.com writes:
>On Fri, 03 Nov 2023 16:37:16 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>Muttley@dastardlyhq.com writes:
>>>On Thu, 02 Nov 2023 20:58:10 GMT
>>>scott@slp53.sl.home (Scott Lurndal) wrote:
>>>>candycanearter07 <no@thanks.net> writes:
>>>>>On 11/2/23 10:43, Kaz Kylheku wrote:
>>>>>> On 2023-11-02, candycanearter07 <no@thanks.net> wrote:
>>>>>>>> static int tiocsti(struct tty_struct *tty, char __user *p)
>>>>>>>> {
>>>>>>>> char ch, mbz = 0;
>>>>>>>> struct tty_ldisc *ld;
>>>>>>>>
>>>>>>>> if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
>>>>>>>> return -EPERM;
>>>>>>>
>>>>>>> Why does it return negative error codes?
>>>>>>
>>>>>> That's how it works in the Linux kernel. That -EPERM will turn,
>>>>>> at the system call interface in the C library, into a -1 return
>>>>>> value from ioctl, and a positive EPERM value in errno.
>>>>>>
>>>>>> The kernel cannot set errno; that's purely a user space gadget
>>>>>> (embroiled in threads: each thread has it own errno location).
>>>>>>
>>>>>
>>>>>Oh cool, is that why so many C calls return -1 on error? I always
>>>>>wondered about that..
>>>>
>>>>Returning -1 on system call failure dates back to the first
>>>>versions of Unix. It was standardized by SVID and ultimately
>>>>POSIX.
>>>
>>>Though if they were going to return -1 as a fail then it would have made a lot
>>
>>>more sense to return the negative error and dispense with errno altogether
>>>except where an integer error can't be returned.
>>>
>>>And just to confuse matters, the pthreads library functions DO return the
>>error
>>>code but its a positive value.
>>
>>The introduction of threads pretty much invalidated the idea of
>>a global errno, which is why all newly defined POSIX system calls
>>return the error number directly rather than leveraging the
>>legacy errno (threaded applications define errno as a thread-local
>>variable to accomodate the legacy system calls).
>
>Makes sense. Though I'd be interested in knowing what the original logic was
>in returning -1 and setting a seperate error variable instead of just returning
>the error directly.
>

It's probably in the Lion's commentary somewhere.

https://en.wikipedia.org/wiki/A_Commentary_on_the_UNIX_Operating_System

My copy is in a box somewhere.

Muttley@dastardlyhq.com writes:
> On Fri, 03 Nov 2023 16:37:16 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
>>Muttley@dastardlyhq.com writes:

[...]

>>>Though if they were going to return -1 as a fail then it would have made a lot
>>
>>>more sense to return the negative error and dispense with errno altogether
>>>except where an integer error can't be returned.
>>>
>>>And just to confuse matters, the pthreads library functions DO return the
>>error
>>>code but its a positive value.
>>
>>The introduction of threads pretty much invalidated the idea of
>>a global errno, which is why all newly defined POSIX system calls
>>return the error number directly rather than leveraging the
>>legacy errno (threaded applications define errno as a thread-local
>>variable to accomodate the legacy system calls).
>
> Makes sense. Though I'd be interested in knowing what the original logic was
> in returning -1 and setting a seperate error variable instead of just returning
> the error directly.

At least up to 7th edition UNIX, system error codes didn't exist at
all. Functions returning integers would return -1 to indicate that an
error had occurred and the possible causes of such errors were listed in
the corresponding manual page.

On 2023-11-03, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> Though if they were going to return -1 as a fail then it would have made a lot
> more sense to return the negative error and dispense with errno altogether
> except where an integer error can't be returned.

errno is a complete stupidity, and some of the coding practices that you
have to use around it are even worse.

Like if you want to know whether a LONG_MAX or LONG_MIN return out of
strtol is a legitimate conversion or an error, you have to assign 0 to
errno first, and then check for a nonzero value if LONG_MAX or LONG_MIN
is returned.

(A co-op student could design a better API. Pointer to long where the
result is stored, and int return value.)

When a complex library function fails, which calls multiple system
calls, it's anyone's guess whether or how the value in errno pertains to
the failure cause.

> And just to confuse matters, the pthreads library functions DO return the error
> code but its a positive value.

Under threads, the errno expression expands to something like
(*__calculate_thread_specific_errno_location()) which is an expensive
function call.

Whoever designed the threads API would naturally have cringed at the
thought of the caller having to inspect errno after seeing a -1 value.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-11-03, Scott Lurndal <scott@slp53.sl.home> wrote:
> The introduction of threads pretty much invalidated the idea of
> a global errno, which is why all newly defined POSIX system calls
> return the error number directly rather than leveraging the
> legacy errno (threaded applications define errno as a thread-local
> variable to accomodate the legacy system calls).

Say, Scott, I wonder whether it's defined to do this:

{
int *errno_loc = &errno;

// then access *errno_loc multiple times in the scope
// with less overhead
}

E.g.:

*errno_loc = 0;
long val = strtol(..., ...);

if ((val == LONG_MAX || val == LONG_MIN) && *errno_loc != 0)
{
// out of range
}

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-11-03, Scott Lurndal <scott@slp53.sl.home> wrote:
>> The introduction of threads pretty much invalidated the idea of
>> a global errno, which is why all newly defined POSIX system calls
>> return the error number directly rather than leveraging the
>> legacy errno (threaded applications define errno as a thread-local
>> variable to accomodate the legacy system calls).
>
>Say, Scott, I wonder whether it's defined to do this:
>
> {
> int *errno_loc = &errno;
>
> // then access *errno_loc multiple times in the scope
> // with less overhead
> }

Close enough.

/* Function to get address of global `errno' variable. */
extern int *__errno_location (void) __THROW __attribute__ ((__const__));

# define errno (*__errno_location ())

In article <7gb1N.177699$sxoa.49926@fx13.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>On 2023-11-03, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> The introduction of threads pretty much invalidated the idea of
>>> a global errno, which is why all newly defined POSIX system calls
>>> return the error number directly rather than leveraging the
>>> legacy errno (threaded applications define errno as a thread-local
>>> variable to accomodate the legacy system calls).

I hate having to killfile my own thread.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Security

On Friday, November 3, 2023 at 1:23:51 PM UTC-7, Kenny McCormack wrote:
> In article <7gb1N.177699$sxoa....@fx13.iad>,
> Scott Lurndal <sl...@pacbell.net> wrote:
> >Kaz Kylheku <864-11...@kylheku.com> writes:
> >>On 2023-11-03, Scott Lurndal <sc...@slp53.sl.home> wrote:
> >>> The introduction of threads pretty much invalidated the idea of
> >>> a global errno, which is why all newly defined POSIX system calls
> >>> return the error number directly rather than leveraging the
> >>> legacy errno (threaded applications define errno as a thread-local
> >>> variable to accomodate the legacy system calls).
> I hate having to killfile my own thread.

So you missed the post where Kaz suggested the process would need to make the target tty its controlling tty? That's unfortunate.

Philip Guenther

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-11-10, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <uijcq4$2alo4$2@dont-email.me>, vallor <vallor@cultnix.org> wrote:
>> ...
>>>This is about as on-topic and useful as he could hope for, including
>>>the code from the OS itself.
>>
>> Nope. Sorry.
>>
>> It is as if I posted "I have a cold (or COVID)" and the response was a
>> detailed description of how viruses (*) exist and develop. Interesting
>> perhaps, but not at all helpful or on-topic.
>
>It's all on-topic for the newsgroup. But of course you mean off-topic in
>your bubble.
>
>That's where it gets curious, because how can the the piece of code that
>actually does the check that you were running into and asking about be
>off topic?
>
>"Not the whole answer" and "off topic" are different concepts.

I've you been paying any attention at all for the last decade,
Kenny has never contributed anything useful other than insults.