Re: CVS commit: src/sys/kern

2020-06-01 Thread Rin Okuyama

On 2020/06/02 2:08, Joerg Sonnenberger wrote:

On Sun, May 31, 2020 at 11:24:20PM +, Rin Okuyama wrote:

Module Name:src
Committed By:   rin
Date:   Sun May 31 23:24:20 UTC 2020

Modified Files:
src/sys/kern: kern_timeout.c

Log Message:
Stop allocating buffers dynamically in a DDB session, in order not to
disturb on-going debugged state of kernel datastructures.


This breaks the build with clang as it uses a declared-but-not-defined
type callout_cpu.


Fixed. Sorry for breakage.

Thanks,
rin


Re: CVS commit: src/sys/kern

2020-06-01 Thread Joerg Sonnenberger
On Sun, May 31, 2020 at 11:24:20PM +, Rin Okuyama wrote:
> Module Name:  src
> Committed By: rin
> Date: Sun May 31 23:24:20 UTC 2020
> 
> Modified Files:
>   src/sys/kern: kern_timeout.c
> 
> Log Message:
> Stop allocating buffers dynamically in a DDB session, in order not to
> disturb on-going debugged state of kernel datastructures.

This breaks the build with clang as it uses a declared-but-not-defined
type callout_cpu.

Joerg


Re: CVS commit: src/lib/libedit (strncpy->strlcpy)

2020-06-01 Thread Christos Zoulas

> This feels not good.
> strncpy->strlcpy has repercussions like how strlcpy doesn't zero out the
> remaining length and thus leaks uninitialized data.
> 
> There has to be a reasonable way to handle these warnings instead of
> rototilling which str*cpy function is used.

Please read the code before commenting. Yes, I know that they are not
equivalent, but in this case the destination strings are all local variables
on the stack used internally only in the functions declared, to be compared
or printed with other NUL-terminated strings. It is pointless to zero out
the rest of the data.

christos


signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/lib/libedit (strncpy->strlcpy)

2020-06-01 Thread maya
On Sun, May 31, 2020 at 07:24:24PM -0400, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Sun May 31 23:24:24 UTC 2020
> 
> Modified Files:
>   src/lib/libedit: terminal.c tty.c
> 
> Log Message:
> use strlcpy() instead of strncpy() for gcc happiness
> 
...

> @@ -1319,10 +1319,8 @@ terminal_settc(EditLine *el, int argc __
>   if (argv == NULL || argv[1] == NULL || argv[2] == NULL)
>   return -1;
>  
> - strncpy(what, ct_encode_string(argv[1], >el_scratch), sizeof(what));
> - what[sizeof(what) - 1] = '\0';
> - strncpy(how,  ct_encode_string(argv[2], >el_scratch), sizeof(how));
> - how[sizeof(how) - 1] = '\0';
> + strlcpy(what, ct_encode_string(argv[1], >el_scratch), sizeof(what));
> + strlcpy(how,  ct_encode_string(argv[2], >el_scratch), sizeof(how));
>  

This feels not good.
strncpy->strlcpy has repercussions like how strlcpy doesn't zero out the
remaining length and thus leaks uninitialized data.

There has to be a reasonable way to handle these warnings instead of
rototilling which str*cpy function is used.