[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lynx-dev] ..on SOCKS5 support
From: |
Mouse |
Subject: |
Re: [Lynx-dev] ..on SOCKS5 support |
Date: |
Sun, 15 Sep 2019 21:42:46 -0400 (EDT) |
> ssh -D starts a SOCKS5 server on the SSH client side AIUI.
This depends on which ssh implementation you've got.
> + pbuf[i++] = (((unsigned)socks5_port) >> 8) & 0xFF;
> + pbuf[i++] = ((unsigned)socks5_port) & 0xFF;
> This should even be optimisable by compilers.
That depends on what kind of optimization you're talking about and,
depending on that, other details. I'll assume you're talking about
optimizing it into a single two-byte store.
Depending on which variant of C the compiler adheres to (er,
tries to adhere to), and things I can't see such as the declaration of
pbuf, you may need hints of one sort or another to allow the compiler
to deduce that the first LHS does not alias i, socks5_port, or (if it's
a pointer rather than array) pbuf itself. Even then, you would have to
be on a big-endian machine, or have a byte-swapping store instruction
available, for it to be optimized into a single store (though if an
in-register byte-swap is available, a byte-swap plus a store may still
be faster than two single-byte stores). You'd also need to be on an
architecture which doesn't trap on unaligned stores, or have
compiler-accessible proof that &pbuf[i] is even before the sequence
begins. And, of course, pbuf needs to be an array of, or pointer to, a
type of suitable size and information content, but I assume that's
already covered.
Not that the former code is all that great; it's got its own problems.
But I don't think it's all that reasonable to blithely assume the
replacement you propose "should ... be optimisable", though I do
suspect it is unlikely to be slower than the original on machines where
each produces the right result.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML address@hidden
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
- Re: [Lynx-dev] ..on SOCKS5 support, (continued)
- Re: [Lynx-dev] ..on SOCKS5 support, Thomas Dickey, 2019/09/07
- Re: [Lynx-dev] ..on SOCKS5 support, Steffen Nurpmeso, 2019/09/07
- Re: [Lynx-dev] ..on SOCKS5 support, Thomas Dickey, 2019/09/08
- Re: [Lynx-dev] ..on SOCKS5 support, Steffen Nurpmeso, 2019/09/09
- Re: [Lynx-dev] ..on SOCKS5 support, Thomas Dickey, 2019/09/10
- Re: [Lynx-dev] ..on SOCKS5 support, Steffen Nurpmeso, 2019/09/11
- Re: [Lynx-dev] ..on SOCKS5 support, Steffen Nurpmeso, 2019/09/14
- Re: [Lynx-dev] ..on SOCKS5 support, Steffen Nurpmeso, 2019/09/14
- Re: [Lynx-dev] ..on SOCKS5 support, Thomas Dickey, 2019/09/15
- Re: [Lynx-dev] ..on SOCKS5 support, Thorsten Glaser, 2019/09/15
- Re: [Lynx-dev] ..on SOCKS5 support,
Mouse <=
- Re: [Lynx-dev] ..on SOCKS5 support, Thorsten Glaser, 2019/09/15
- Re: [Lynx-dev] ..on SOCKS5 support, Mouse, 2019/09/16
- Re: [Lynx-dev] ..on SOCKS5 support, Thomas Dickey, 2019/09/16
- Re: [Lynx-dev] ..on SOCKS5 support, Steffen Nurpmeso, 2019/09/16
- Re: [Lynx-dev] ..on SOCKS5 support, Mouse, 2019/09/16
- Re: [Lynx-dev] ..on SOCKS5 support, Steffen Nurpmeso, 2019/09/16
- Re: [Lynx-dev] ..on SOCKS5 support, Steffen Nurpmeso, 2019/09/16
- Re: [Lynx-dev] ..on SOCKS5 support, Steffen Nurpmeso, 2019/09/16
Re: [Lynx-dev] ..on SOCKS5 support, Thorsten Glaser, 2019/09/07