Re: #pragma once
Well..h files are a crock to begin with. You can always do stuff like: *#include "bunch_of_constants_you_will_need.c"* Still C is a crock. The preprocessor is a crock. The 'macro' system is a crock. And the language is a crock. (it's from New Jersey, I'm told...) Rather than small proposed changes like this -- what about moving to a more modern language (Rust?). So these types of trivialities are not even conceptualized. -mac On Mon, Oct 24, 2022 at 1:05 AM Robert Elz wrote: > Date:Sun, 23 Oct 2022 09:50:20 + > From:Taylor R Campbell > Message-ID: <20221023095027.eb8ef60...@jupiter.mumble.net> > > | I wasn't able to find a clear statement of the semantics anywhere: > | Is it keyed by (dev,ino), by pathname, by some kind of normalized > | pathname, by file content? gcc's own documentation is very sparse and > | just describes it as nonportable. > > I had not weighed in on this before, but that issue was the biggest > problem I could see with this. > > That and that using guards allows having mutually exclusive (but > different) include files ... though of course they could always be > used for any such cases even if the #pragma scheme became the normal > way. > > | So on balance, #pragma once doesn't seem worthwhile to me today, and > | I think we should stick to traditional include guards for now. > > I agree. > > kre > > >
Re: Representing a rotary encoder input device
Are you planning on including rotary Quadrature Encoders? Often, such encoders when used for volume-control type applications have an extra contact set, actuated by pushing the knob in. They have the A and B quadrature and this (optional) pushbutton. On Tue, Sep 21, 2021 at 5:53 PM Jason Thorpe wrote: > Hey folks... > > As part of a long-running hardware project I have been playing with, I'm > experimenting with using a rotary encoder for input. For reference, here > is the Devicetree binding for rotary encoders: > > > https://github.com/devicetree-org/devicetree-source/blob/master/Bindings/input/rotary-encoder.txt > > Rotary encoders come in a bunch of different forms, of course... ranging > from simple knobs with detents to devices similar to the original iPod > click wheel. Some include built-in push buttons (that signal a separate > GPIO from the two GPIOs used to signal the rotary control itself). > > Trying to think about the best way to represent such a device, I guess > within wscons (they almost seem sort of like a 1-axis mouse, but I could be > convinced otherwise). > > Personally I'm seeing my use cases teetering towards using relative events > (value selection that from 0-9 that wraps around back to 0, and also volume > control that simply saturates at 0 or 100). But I want to make sure I > cover the absolute cases, as well. > > Thoughts? > > -- thorpej > >
Re: maximum limit of files open with O_EXLOCK
I got the message about files as a user: arm64>make m cc -g -Wall -std=gnu17 -O3 -lm -o m m.c arm64>./m bleh 1021: Too many open files arm64> On Sun, Jun 20, 2021 at 8:51 PM David Holland wrote: > On Sat, Jun 19, 2021 at 08:12:38AM +, nia wrote: > > The Zig developer found the kernel limit: > > https://nxr.netbsd.org/xref/src/sys/kern/vfs_lockf.c#116 > > > > but it doesn't seem to be adjustable through sysctl. > > I wonder if it should be. > > I wonder if the logic should be changed to allow one "free" lock per > open file, since those are already limited, and it's not like the > amounts of memory involved are large. > > -- > David A. Holland > dholl...@netbsd.org >
Re: fsck updating but not fixing filesystem
Another data point: I can't remember ever when NTFS didn't come up clean after a crash, except of course when the disk itself was bad. "NTFS (NT File System) is a proprietary journaling file system developed by Microsoft. Starting with Windows NT 3.1, it is the default file system of the Windows NT family." On Mon, Aug 24, 2020 at 7:41 AM David Brownlee wrote: > On Mon, 24 Aug 2020 at 11:46, Mouse wrote: > > > > > I think the general consensus is that ffs can be inconsistent it ways > > > fsck is unable to detect. > > > > ...much less fix. Yes. When I was doing the program that eventually > > got massaged into resize_ffs, during development I had some filesystems > > that were definitely corrupted but that fsck was happy with. (I rather > > wish I'd saved some of them as test cases, but I didn't.) > > Sounds like there is an in interesting fuzzing project in there for > someone - make a filesystem mage and the repeatedly damage it, then > see if fsck can fix it, then if you get a rump panic when moving > everything around, and then re-run fsck to see if it indicates any new > issues :) > > (So far 3.5TB of my original RAID1 filesystem transferred to a plain > disk, so should be able to run some A/B fsck tests later today to > establish if the raid controller is the issue in this case) > > David > > > David >
Re: style change: explicitly permit braces for single statements
A few years ago when I worked at Tesla, we had to have our production code
pass a MISRA C linter: https://gimpel.com/
MISRA C requires braces even with a single clause. I'm not going to try to
justify MISRA C's rules; but only say that 'programmers in automobile /
embedded' world probably find this extra brace practice normal.
I have a 4K screen, so a few lines wasted this way... doesn't really bother
me anymore. If I were bothered, I'd make the font 1 or 2 points smaller
and get more lines. (If any of us is still using an 80 x 24 terminal --
here's a nickel:https://dilbert.com/strip/1995-06-24 )
On Sun, Jul 12, 2020 at 1:50 AM Robert Elz wrote:
> Date:Sun, 12 Jul 2020 13:01:59 +1000
> From:Luke Mewburn
> Message-ID: <20200712030159.gh12...@mewburn.net>
>
>
> | | IMHO, permitting braces to be consistently used:
> | | - Adds to clarity of intent.
> | | - Aids code review.
> | | - Avoids gotofail:
> https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug
>
>
> Permitting the braces is probably no big deal, but does none of
> that. Actually using the extra braces might, but unless you change
> "permitting" to "requiring", that's unlikely to happen a lot.
>
> I simply cannot see myself changing
>
> if (p == NULL)
> return NULL;
>
> into
>
> if (p == NULL) {
> return NULL;
> }
>
> Aside from anything else, the closing brace occupies an extra
> line (and often two, as those are often followed by blank lines)
> which means two less lines of context I get to see in my window
> (however big the window is - enlarging it still means 2 less lines
> of context than would be possible) - and that's for each time this
> is done.
>
> But as long as they're just permitted, and not required, then I
> don't have a big problem with it - but note that if I'm working
> on code written like that, I'm likely to delete non-required
> meaningless braces (just as cleaning up trailing whitespace,
> fixing tab vs space indentation, and wrapping long lines, etc).
>
> kre
>
>
