Re: clang: compile static analyzer
On Fri, 21 Jan 2022 00:45:56 +0100 Steffen Nurpmeso wrote: > I found scan-build to generate a lot of false warnings, so much indeed > that i stopped using it .. in summer 2017. You, and most others, (no sarcasm at all here) are much better at C than I will ever be. I am not even at "amateur" level - more like a part-time hobby. I mostly fiddle with text data compression for fun. For me, clang analyzer is more than helpful. It detects errors that most of you, professional programmers, would never make. You probably don't even realize the power of it, since you never make such embarrassing mistakes while coding as I do. For me, every time there was a warning from clang, it was fully warranted. Took me couple days in some cases to figure out why, but it was always justified and I learned a lot from it. I install clang from ports solely for the analyzer part. It would be nice if it was included in base installation - some of us just want a basic idiot-check tool available when trying to program things. But ports installation works as well too. -- Andre
Re: sndio - sio_getcap() clarification
On Mon, 8 May 2017 00:03:02 +0200 Alexandre Ratchov <a...@caoua.org> wrote: > On Sun, May 07, 2017 at 02:10:03PM -0400, Andre Smagin wrote: > > > > >From my limited testing it appears that sio_getcap() fails if audio > > device does not have identical recording and playback capabilities > > (examples at the end). If that is indeed the case, could it possibly be > > mentioned in the man page somewhere? Perhaps something like: > > The encoding and sample rate are common to play and record. I mean > the audio stack assumes play and record parameters (except channels > count) are the same in full-duplex. > > What you observe seems to be a driver or libsndio bug. Could you > send the output of your program (or "cap") with SNDIO_DEBUG=1 > environment variable exported, and the related dmesg lines? I see. Would the manpage bit about different capabilities for SIO_REC and SIO_PLAY modes still be of use? I know I failed to realize at first that capabilities could be different based on how the device was opened. Here is the log from my worst offender system: $ export SNDIO_DEBUG=1 $ export AUDIODEVICE=rsnd/0 $ cap -p config 0 enc: s16le s24le pchan: 2 rchan: rate: 44100 48000 96000 $ cap -r config 0 enc: s16le pchan: rchan: 2 rate: 44100 48000 96000 $ cap AUDIO_SETPAR: Operation not supported by device sio_getcap() failed $ cap /dev/audio0: Operation not supported by device sio_open() failed $ cap /dev/audio0: Operation not supported by device sio_open() failed $ cap -p config 0 enc: s16le s24le pchan: 2 rchan: rate: 44100 48000 96000 $ cap /dev/audio0: Operation not supported by device sio_open() failed $ cap AUDIO_SETPAR: Operation not supported by device sio_getcap() failed On this system, after sio_getcap fails for the first time, any further sio_getpar and get_getcap requests become unreliable/inconsistent and occasionally completely lock-up the sound subsystem, so the device cannot be opened at all - have to reboot at this point. Opening the device only in SIO_PLAY or SIO_REC mode sometimes sort-of resets it (as you can see in the log above). Also get this on console for every failed sio_getcap: audio0: different play and record parameters returned by hardware >From dmesg (full dmesg at the end): azalia1 at pci0 dev 20 function 2 "AMD Hudson-2 HD Audio" rev 0x02: apic 5 int 16 azalia1: codecs: Realtek ALC662 audio0 at azalia1 Second system with the same symptoms, but without noticed hard lock-ups yet (running "cap -p" or "cap -r" seems to reset it): $ cap /dev/audio0: Operation not supported by device sio_open() failed $ cap -r config 0 enc: s16le pchan: rchan: 2 rate: 44100 48000 96000 $ cap -p config 0 enc: s16le s24le pchan: 2 rchan: rate: 44100 48000 96000 $ cap AUDIO_SETPAR: Operation not supported by device sio_getcap() failed $ cap /dev/audio0: Operation not supported by device sio_open() failed This one is: azalia0 at pci0 dev 20 function 2 "ATI SBx00 HD Audio" rev 0x40: apic 2 int 16 azalia0: codecs: Realtek ALC662 audio0 at azalia0 Dmesg for the first system: OpenBSD 6.1-current (GENERIC.MP) #55: Fri Apr 14 13:54:33 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1535582208 (1464MB) avail mem = 1484423168 (1415MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebe10 (16 entries) bios0: vendor American Megatrends Inc. version "4.6.5" date 04/22/2014 bios0: BIOSTAR Group A68N-5000 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT CRAT SSDT SSDT acpi0: wakeup devices RTL_(S4) LOM_(S4) SBAZ(S4) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4) XHC0(S4) BR11(S4) PWRB(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD A4-5000 APU with Radeon(TM) HD Graphics, 1497.40 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: TSC frequency 1497400130 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (applica
sndio - sio_getcap() clarification
>From my limited testing it appears that sio_getcap() fails if audio device does not have identical recording and playback capabilities (examples at the end). If that is indeed the case, could it possibly be mentioned in the man page somewhere? Perhaps something like: Index: sio_open.3 === RCS file: /build/openbsd/cvs/src/lib/libsndio/sio_open.3,v retrieving revision 1.46 diff -u -p -r1.46 sio_open.3 --- sio_open.3 3 Jan 2017 20:29:28 - 1.46 +++ sio_open.3 7 May 2017 17:22:31 - @@ -285,6 +285,17 @@ parameter combinations in advance can us .Fn sio_getcap function. .Pp +.Fn sio_getcap +function can return different results based on whether +.Dv SIO_PLAY +or +.Dv SIO_REC +mode was selected. +It can fail for the device with differing recording and +playback capabilities opened in +.Dv SIO_PLAY | SIO_REC +mode. +.Pp The .Vt sio_cap structure contains the list of parameter configurations. Examples that I am retrieving with sio_getpar() and sio_getcap() with a program similar to src/regress/lib/libsndio/cap/cap.c: rsnd/0 (play) parameters: s24le/48000, 2 play/2 rec channels rsnd/0 (rec) parameters: s16le/48000, 2 play/2 rec channels rsnd/0 (play+rec) parameters: s16le/48000, 2 play/2 rec channels rsnd/0 (play) capabilities: Configuration 1 out of 1: Encodings: s16le s24le Rates: 44100 48000 96000 Recording channels: Playback channels: 2 rsnd/0 (rec) capabilities: Configuration 1 out of 1: Encodings: s16le Rates: 44100 48000 96000 Recording channels: 2 Playback channels: rsnd/0 (play+rec) capabilities: Error getting capabilities. but on a different system with better audio hardware it succeeds: rsnd/0 (play) parameters: s24le/48000, 2 play/2 rec channels rsnd/0 (rec) parameters: s24le/48000, 2 play/2 rec channels rsnd/0 (play+rec) parameters: s24le/48000, 2 play/2 rec channels rsnd/0 (play) capabilities: Configuration 1 out of 1: Encodings: s16le s24le Rates: 44100 48000 88200 96000 Recording channels: Playback channels: 2 4 6 8 10 rsnd/0 (rec) capabilities: Configuration 1 out of 1: Encodings: s16le s24le Rates: 44100 48000 88200 96000 Recording channels: 2 Playback channels: rsnd/0 (play+rec) capabilities: Configuration 1 out of 1: Encodings: s16le s24le Rates: 44100 48000 88200 96000 Recording channels: 2 Playback channels: 2 4 6 8 10
rdate - truncated error messages
Hello.
After the recent addition of pledge and privilege separation to rdate,
some error messages get truncated, since the pipe message size for the
child is limited to 256. For example:
$ rdate -n pool.ntp.org
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: Can't assign reque
Are there any potential issues with increasing the size a little bit?
As in:
Index: rdate.c
===
RCS file: /build/openbsd/cvs/src/usr.sbin/rdate/rdate.c,v
retrieving revision 1.34
diff -u -p -r1.34 rdate.c
--- rdate.c 31 Oct 2015 18:24:01 - 1.34
+++ rdate.c 23 Dec 2015 17:54:00 -
@@ -64,7 +64,7 @@ extern char*__progname;
__dead voidusage(void);
struct {
- char message[256];
+ char message[1024];
struct timeval new;
struct timeval adjust;
} pdata;
With this change the errors look like this:
ZAURUS: /build/openbsd/current/src/usr.sbin/rdate $ obj/rdate -n pool.ntp.org
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: Can't assign requested address
rdate: Unable to get a reasonable time estimate
ZAURUS: /build/openbsd/current/src/usr.sbin/rdate $ obj/rdate -n google.com
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: Can't assign requested address
rdate: Failed to connect to server: No route to host
rdate: Unable to get a reasonable time estimate
Re: Rewording mbstowcs(3), wcrtomb(3) and wcstombs(3)
On Thu, 19 Mar 2015 13:36:45 +0001 Jason McIntyre j...@kerhand.co.uk wrote: On Thu, Mar 19, 2015 at 03:32:52PM +0200, Kaspars Bankovskis wrote: Is that really accurate to say that elements are stored in a pointer? no idea. it's why i asked stsp to look it over. jmc I looked up the Linux and FreeBSD versions of the man pages and they had wording such as Linux: At most n wide characters are written to dest. At most n bytes are written to dest. FreeBSD: No more than nwchars wide characters are stored. Up to nbytes bytes are stored in mbstring. , so I proposed a similar change. Other OpenBSD man pages use similar form: The strncpy() function copies not more than len characters from the string src to the buffer dst. strlcpy() copies up to dstsize - 1 characters from the string src to dst, KR also say for memcpy copy n characters from ct to s POSIX says for mbstowcs: No more than n elements shall be modified in the array pointed to by pwcs. but I personally find the shall be modified form somewhat ambiguous. -- Andre Smagin
Rewording mbstowcs(3), wcrtomb(3) and wcstombs(3)
Hello. mbstowcs(3), wcrtomb(3) and wcstombs(3) use a bit awkward wording - the first at most, and repeat array pointed to by blah from the previous sentence. Perhaps something similar to this diff would make them easier to read? Index: mbstowcs.3 === RCS file: /cvs/src/lib/libc/locale/mbstowcs.3,v retrieving revision 1.5 diff -u -p -u -r1.5 mbstowcs.3 --- mbstowcs.3 5 Jun 2013 03:39:22 - 1.5 +++ mbstowcs.3 18 Mar 2015 19:05:39 - @@ -46,9 +46,9 @@ converts a null-terminated multibyte cha to the corresponding wide-character string and stores it in the array pointed to by .Fa pwcs . -This function may modify the first at most +Up to .Fa n -elements of the array pointed to by +elements are stored in .Fa pwcs . Each character will be converted as if .Xr mbtowc 3 Index: wcrtomb.3 === RCS file: /cvs/src/lib/libc/locale/wcrtomb.3,v retrieving revision 1.7 diff -u -p -u -r1.7 wcrtomb.3 --- wcrtomb.3 28 Aug 2013 16:24:07 - 1.7 +++ wcrtomb.3 18 Mar 2015 19:05:39 - @@ -48,9 +48,9 @@ pointed to by unless .Fa s is a null pointer. -This function will modify the first at most +Up to .Dv MB_CUR_MAX -bytes of the array pointed by +bytes are stored in .Fa s . .Pp The behaviour of Index: wcstombs.3 === RCS file: /cvs/src/lib/libc/locale/wcstombs.3,v retrieving revision 1.5 diff -u -p -u -r1.5 wcstombs.3 --- wcstombs.3 5 Jun 2013 03:39:22 - 1.5 +++ wcstombs.3 18 Mar 2015 19:05:39 - @@ -45,9 +45,9 @@ converts the null-terminated wide-charac to the corresponding multibyte character string, and stores it in the array pointed to by .Fa s . -This function may modify the first at most +Up to .Fa n -bytes of the array pointed to by +bytes are stored in .Fa s . Each character will be converted as if .Xr wctomb 3
