Re: static inline, not inline static

[Anders Andersson]

On Mon, Aug 29, 2022 at 2:01 AM Philip Guenther  wrote:
>
> On Sun, Aug 28, 2022 at 2:11 PM Anders Andersson  wrote:
>>
>> On Sun, Aug 28, 2022 at 3:15 PM Jonathan Gray  wrote:
>> >
>> > diff --git lib/libc/locale/wctoint.h lib/libc/locale/wctoint.h
>> > index ea50c5ae1b6..14c7f0c466d 100644
>> > --- lib/libc/locale/wctoint.h
>> > +++ lib/libc/locale/wctoint.h
>> > @@ -30,7 +30,7 @@
>> >   */
>> >
>> >
>> > -inline static int
>> > +static inline int
>> >  wctoint(wchar_t wc)
>> >  {
>> > int n;
>> > [...]
>>
>> Why this change? As far as I can see, the standard allows for any order.
>
>
> C99 standard stated:
> "The placement of a storage-class specifier other than at the beginning of 
> the declaration
>  specifiers in a declaration is an obsolescent feature.
>
> My recall is that it was officially removed in C11.
>
> ok guenther@

This intrigued me so I had to do some archaeology. The grammar allows
any random order from K first edition up to (and including) this
month's C23 draft, but the warning has been in there since the first
ANSI C standard (and is still in C23).

Maybe someone forgot to push for this, and no one dares to remove the warning.

Re: static inline, not inline static

[Anders Andersson]

On Sun, Aug 28, 2022 at 3:15 PM Jonathan Gray  wrote:
>
> diff --git lib/libc/locale/wctoint.h lib/libc/locale/wctoint.h
> index ea50c5ae1b6..14c7f0c466d 100644
> --- lib/libc/locale/wctoint.h
> +++ lib/libc/locale/wctoint.h
> @@ -30,7 +30,7 @@
>   */
>
>
> -inline static int
> +static inline int
>  wctoint(wchar_t wc)
>  {
> int n;
> [...]

Why this change? As far as I can see, the standard allows for any order.

Re: Diff for www:openssh/users.html

[Anders Andersson]

On Wed, Jun 10, 2020 at 3:23 AM  wrote:
>
> Hi,
>
> Here a diff for www page: openssh/users.html
>
> Change URLs to those on archive.org (and others sites)
>
> Right?

It says "The following operating systems and products are known to
integrate OpenSSH into the base system.". If a system no longer
exists, shouldn't it be removed from that list?

I would not be impressed with a product if I found that half of their
"recommendations" were dead projects just listed to fill out space.

Re: [PATCH] sysupgrade

[Anders Andersson]

On Thu, Apr 30, 2020 at 6:02 AM James Jerkins
 wrote:
>
> Hello,
>
> This patch adds two new options to sysupgrade. The first option is for small 
> box systems like an APU system that only has the base and manual sets 
> installed. The second option is for headless systems without X11 like 
> servers. I have tested this patch from the 6.5 release to 6.6 release to 
> current for both the minimal and no X11 options. In order to test, I did 
> remove the ftp -N option which is not present in the 6.5 or 6.6 releases. I 
> also tested sysupgrade without invoking either new option from 6.5 to 6.6 to 
> current for regression. All of these tests resulted in a successful upgrade.
>
> I also repeated the above tests from a full install to minimal and base 
> installs and, of course, the system is broken after such an upgrade. While it 
> is possible to check for the presence of clang or xinit to guess if the 
> requested upgrade is safe, I believe it would still only be a guess that 
> couldn't eliminate all the creative ways someone could break their 
> installation. If anyone has a suggestion for how to address this problem I am 
> willing to work on it and submit an updated patch.
>
> Thank you to all the OpenBSD developers for the incredible work you do every 
> day on OpenBSD and for sharing your work.

I recently bought an APU with the smallest disk I could find (16 GB
mSATA), I don't remember the full install of all sets taking more than
10%. No need to remove stuff.

I don't really see why a system-wide tool should have several options
for hardcoded subsets of some of the possible ways to create a
non-standard installation, especially when using these options will
break an otherwise working setup. IF there is such an option, surely
it should take a list of sets that you have installed?

Especially when I've read here that there is a wish for some of the
devs that the option of selecting subsets should probably just be
removed.

Re: umb(4) authentication

[Anders Andersson]

On Mon, Jan 13, 2020 at 4:42 PM Martijn van Duren
 wrote:
>
> On 1/13/20 4:30 PM, Anders Andersson wrote:
> > On Mon, Jan 13, 2020 at 3:00 PM leeb  wrote:
> >>
> >> Hello,
> >>
> >> I had an itch, so I scratched it.
> >>
> >> The umb(4) driver has a FIXME in if_umb.c for user name
> >> and passphrase support. My LTE provider happens to require
> >> this so I thought I'd have a go.
> >>
> >> The provider seems happy with my umb changes, and I've
> >> added some bits in ifconfig(8) to allow setting of the
> >> authentication information (user/pass/protocol):
> >>
> >> umb0: flags=8851 mtu 1500
> >> index 5 priority 6 llprio 3
> >> roaming disabled registration home network
> >> state up cell-class LTE rssi -67dBm speed 47.7Mps up 95.4Mps down
> >> SIM initialized PIN valid (3 attempts left)
> >> subscriber-id 999 ICC-id 999 provider 
> >> xx
> >> device MC7700 IMEI 999 firmware SWI9200X_03.05.19.00Aap
> >> phone# 999 APN xx User  Pass x 
> >> Auth CHAP
> >> dns x.x.x.x x.x.x.x
> >> groups: egress
> >> status: active
> >> inet x.x.x.x --> x.x.x.x netmask 0xfffc
> >>
> >> (please excuse line wraps, and I've redacted possibly
> >> sensitive info)
> >>
> >> Now, this is my first attempt at OpenBSD development, and
> >> writing my changes raised a few questions. So, does someone
> >> want to spare a few minutes off-list, or should I just
> >> clutter up tech@ ?
> >>
> >> (I've read the top of the Makefile, I've been through the
> >> web pages on AnonCVS and release(8))
> >>
> >> Thanks,
> >>
> >> Lee.
> >
> > This email should be gold plated and moved to a permanent location in
> > the FAQ on how to help OpenBSD and how to request new features.
> >
> Lee is obviously new to the community and doesn't know the workflow well
> enough. He tries to be polite and make sure he doesn't clutter the list.
> If you actually read his mail you would've seen that he has a diff and
> it works for him, so it's obviously not a dumb feature request.
>
> Please refrain from ridiculing people with good intentions.

I did read the whole email. Now I'm wondering if you read my reply?
It's not very long, just one sentence. Did you add a few "not" in
there that I didn't write? Or if you are meta-trolling me somehow, I
apologize if I missed the wooshing noise.

Re: umb(4) authentication

[Anders Andersson]

On Mon, Jan 13, 2020 at 3:00 PM leeb  wrote:
>
> Hello,
>
> I had an itch, so I scratched it.
>
> The umb(4) driver has a FIXME in if_umb.c for user name
> and passphrase support. My LTE provider happens to require
> this so I thought I'd have a go.
>
> The provider seems happy with my umb changes, and I've
> added some bits in ifconfig(8) to allow setting of the
> authentication information (user/pass/protocol):
>
> umb0: flags=8851 mtu 1500
> index 5 priority 6 llprio 3
> roaming disabled registration home network
> state up cell-class LTE rssi -67dBm speed 47.7Mps up 95.4Mps down
> SIM initialized PIN valid (3 attempts left)
> subscriber-id 999 ICC-id 999 provider 
> xx
> device MC7700 IMEI 999 firmware SWI9200X_03.05.19.00Aap
> phone# 999 APN xx User  Pass x Auth 
> CHAP
> dns x.x.x.x x.x.x.x
> groups: egress
> status: active
> inet x.x.x.x --> x.x.x.x netmask 0xfffc
>
> (please excuse line wraps, and I've redacted possibly
> sensitive info)
>
> Now, this is my first attempt at OpenBSD development, and
> writing my changes raised a few questions. So, does someone
> want to spare a few minutes off-list, or should I just
> clutter up tech@ ?
>
> (I've read the top of the Makefile, I've been through the
> web pages on AnonCVS and release(8))
>
> Thanks,
>
> Lee.

This email should be gold plated and moved to a permanent location in
the FAQ on how to help OpenBSD and how to request new features.

Re: Employment verification – request for contact details

[Anders Andersson]

On Tue, May 7, 2019 at 12:47 PM Lipinska, Sara
 wrote:
>
> HireRight Limited is a limited liability company incorporated in England 
> (registered number 4036193) whose registered office is at Gun Court, 70 
> Wapping Lane, London, E1W 2RD.
>
> This communication contains information that may be confidential, proprietary 
> in nature, and may also be attorney-client privileged and/or work product 
> privileged. It is for the exclusive use of the intended recipient(s). If you 
> are not the intended recipient(s) or the person responsible for delivering it 
> to the intended recipient(s), please note that any form of dissemination, 
> distribution or copying of this communication is strictly prohibited and may 
> be unlawful. If you have received this communication in error, please 
> immediately notify the sender by replying to this message and delete this 
> e-mail immediately. Thank you for your cooperation. Please be advised that 
> neither HireRight, its affiliates, its employees or agents accept liability 
> for any errors, omissions or damages caused by delays of receipt or by any 
> virus infection in this message or its attachments, or which may otherwise 
> arise as a result of this e-mail transmission.

It's not polite to post legal threats. If you don't want people to
disseminate, distribute or copy what you write, you should probably
not send it out to a mailing list.

Re: yacc print_grammar(): loop -> fprintf()

[Anders Andersson]

On Wed, Jan 3, 2018 at 1:58 PM, Michael W. Bombardieri  wrote:
> Hello,
>
> In yacc the function print_grammar() writes the file y.output if
> the -v option is used. fprintf() can be used directly for writing
> "spacing" space characters of indentation so a loop can be removed.
>
> - Michael
>
>
> Index: reader.c
> ===
> RCS file: /cvs/src/usr.bin/yacc/reader.c,v
> retrieving revision 1.34
> diff -u -p -u -r1.34 reader.c
> --- reader.c25 May 2017 20:11:03 -  1.34
> +++ reader.c3 Jan 2018 12:40:54 -
> @@ -1806,7 +1806,7 @@ pack_grammar(void)
>  void
>  print_grammar(void)
>  {
> -   int i, j, k;
> +   int i, k;
> int spacing = 0;
> FILE *f = verbose_file;
>
> @@ -1822,9 +1822,8 @@ print_grammar(void)
> spacing = strlen(symbol_name[rlhs[i]]) + 1;
> } else {
> fprintf(f, "%4d  ", i - 2);
> -   j = spacing;
> -   while (--j >= 0)
> -   putc(' ', f);
> +   if (spacing > 0)
> +   fprintf(f, "%*s", spacing, "");
> putc('|', f);
> }


This takes longer to understand, requires a check for a special case,
and likely ends up being slower.

Re: Regulators as sensors?

[Anders Andersson]

On Tue, Nov 21, 2017 at 11:19 PM, STeve Andre'  wrote:
> On 11/21/17 16:31, Mark Kettenis wrote:
>>
>> The diff below exposes voltage regulators as sensors.  This makes it
>> easy to look at the current settings of these regulators.  The
>> downside is that these aren't really sensors as the voltages are not
>> actually measured.
>>
>> The functionality is optional; callers can pass NULL in the
>> regulator_register() if the regulators aren't particularly
>> interesting.
>>
>> This is what it looks like on the rk3399-firefly:
>>
>> milhaud$ sysctl hw.sensors
>> hw.sensors.rktemp0.temp0=23.89 degC (CPU)
>> hw.sensors.rktemp0.temp1=28.75 degC (GPU)
>> hw.sensors.rkpmic0.volt0=0.90 VDC (vdd_cpu_l)
>> hw.sensors.rkpmic0.volt1=1.80 VDC (vcc1v8_dvp)
>> hw.sensors.rkpmic0.volt2=1.80 VDC (vcc1v8_pmu)
>> hw.sensors.rkpmic0.volt3=3.00 VDC (vcc_sd)
>> hw.sensors.rkpmic0.volt4=1.80 VDC (vcca1v8_codec)
>> hw.sensors.rkpmic0.volt5=3.00 VDC (vcc_3v0)
>>
>> thoughts?
>
>
> As someone who does hardware stuff, having easy access to these sensorts
> can't hurt, and might be useful in some situations.  I've measured voltages
> before and found during extreme temperature conditions things changed. So
> it's possibly useful and doesn't cost much.

This reply illustrates the problem, and I think it won't be the last
time someone misunderstands the feature.

They are *not* sensors, so they will not vary under load. They don't
reflect the actual voltage, so they are useless for checking if the
hardware works as it should. I bet that a lot of people will still
assume that they can be used as such, leading people to believe that
everything is OK with their hardware when it's not.

Re: Httpd support for internal redirects.

[Anders Andersson]

On Wed, Oct 11, 2017 at 6:31 AM, Ori Bernstein  wrote:
> My website generator is a little stupid at times. It generates
> files with .html suffixes, but urls without them.
>
> I worked around this with some redirects, but it never felt
> quite right doing an extra round trip. Therefore, I added
> internal redirects, processing the rewrite before responding to
> an http request.

Maybe I don't fully understand the problem, but is it not better to
fix your broken website generator than to add more code to httpd?