Re: svn commit: r213002 - in stable/8: include lib/libc/gen

[Joerg Sonnenberger]

On Wed, Sep 22, 2010 at 07:32:25PM +0100, Gavin Atkinson wrote:
> Ours (just introduced):
> 
> char * basename_r(path, bname)
> 
> Android (from [1]):
> 
> intbasename_r(const char* path, char*  buffer, size_t  bufflen)
> 
> The semantics seem very different.  Ours allocates a buffer, on Android
> you pass in a buffer, for a start.

...and the Android interface is what most *_r functions expose.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r214210 - head/sys/boot/i386/boot2

[Joerg Sonnenberger]

On Fri, Oct 22, 2010 at 06:07:21PM +, Roman Divacky wrote:
> Log:
>   Avoid using memcpy() for copying 32bit chunks. This shrinks
>   the resulting code a little.

Can't you force the use of the builtin memcpy for this?

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r227812 - head/lib/libc/string

[Joerg Sonnenberger]

On Tue, Nov 22, 2011 at 02:20:15PM +, David Chisnall wrote:
> In this case, either | or || is fine, because neither reads any memory
> or has side effects so | and || are equivalent to the compiler, but
> the use of | tells a human reading the code that the order is unimportant.  

The use of | is just more obscure. The compiler can easily interfere
here that the execution order is irrelevant as the statements are side
effect free.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r228004 - in head: contrib/libcxxrt lib/libcxxrt

[Joerg Sonnenberger]

On Sat, Nov 26, 2011 at 06:46:33PM +, David Chisnall wrote:
> Log:
>   Update libcxxrt to remove the pthread dependency.

This looks wrong. I think it is perfectly sensible to require libc to
provide working stubs for the locking primitives. TLS support falls into
the same categoriy -- it doesn't require libpthread either.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r228435 - in head/libexec/rtld-elf: . amd64 arm i386 ia64 mips powerpc powerpc64 sparc64

[Joerg Sonnenberger]

On Mon, Dec 12, 2011 at 11:03:15AM +, Konstantin Belousov wrote:
>   To allow use of external references from the dispatch function, resolution
>   of the R_MACHINE_IRESOLVE relocations in PLT is postponed until GOT entries
>   for PLT are prepared, and normal resolution of the GOT entries is finished.
>   Similar to how it is done by GNU, IRELATIVE relocations are resolved in
>   advance, instead of normal lazy handling for PLT.

Are you sure that you didn't introduce major locking issues with this?

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r228435 - in head/libexec/rtld-elf: . amd64 arm i386 ia64 mips powerpc powerpc64 sparc64

[Joerg Sonnenberger]

On Mon, Dec 12, 2011 at 07:21:32PM +0200, Kostik Belousov wrote:
> On Mon, Dec 12, 2011 at 06:17:09PM +0100, Joerg Sonnenberger wrote:
> > On Mon, Dec 12, 2011 at 11:03:15AM +, Konstantin Belousov wrote:
> > >   To allow use of external references from the dispatch function, 
> > > resolution
> > >   of the R_MACHINE_IRESOLVE relocations in PLT is postponed until GOT 
> > > entries
> > >   for PLT are prepared, and normal resolution of the GOT entries is 
> > > finished.
> > >   Similar to how it is done by GNU, IRELATIVE relocations are resolved in
> > >   advance, instead of normal lazy handling for PLT.
> > 
> > Are you sure that you didn't introduce major locking issues with this?
> What do you mean, exactly ?
> 
> The dispatcher function is called under the bind lock, yes.

What happens if the dispatcher function is trying to re-enter the
dynamic linker?

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r228614 - head/sbin/dhclient

[Joerg Sonnenberger]

On Sat, Dec 17, 2011 at 01:19:07AM +, Dimitry Andric wrote:
> Log:
>   In sbin/dhclient, work around warnings about the size argument to
>   strlcpy appearing to be the size of the source buffer, instead of the
>   destination.

If you touch this and don't want to use strdup-like functions, at least
make it a memcpy. strlcpy is very crappy from a performance PoV...

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r228650 - head/usr.bin/netstat

[Joerg Sonnenberger]

On Sat, Dec 17, 2011 at 09:53:56PM +, Bjoern A. Zeeb wrote:
> 
> On 17. Dec 2011, at 17:21 , Dimitry Andric wrote:
> 
> > Author: dim
> > Date: Sat Dec 17 17:21:47 2011
> > New Revision: 228650
> > URL: http://svn.freebsd.org/changeset/base/228650
> > 
> > Log:
> >  In usr.bin/netstat/atalk.c, work around a clang false positive with
> >  printf format warnings and conditional operators.
> > 
> 
> This does not sound like a good idea.  Make clang work.

Strictly speaking, clang is correct here. While the 'h' modifier is
effectively a nop due to integer promotion rules, the intention is
clearly "I am going to use a unsigned short here". Of course, the bug in
the change is that it is using short...

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r228670 - head/usr.sbin/pkg_install/updating

[Joerg Sonnenberger]

On Sat, Dec 17, 2011 at 11:35:46PM +, Dimitry Andric wrote:
> Modified: head/usr.sbin/pkg_install/updating/main.c
> ==
> --- head/usr.sbin/pkg_install/updating/main.c Sat Dec 17 23:18:14 2011
> (r228669)
> +++ head/usr.sbin/pkg_install/updating/main.c Sat Dec 17 23:35:46 2011
> (r228670)
> @@ -141,7 +141,7 @@ main(int argc, char *argv[])
>   strcmp(pkgdbdir->d_name, "..") != 0) {
>  
>   /* Create path to +CONTENTS file for 
> each installed port */
> - n = strlcpy(tmp_file, pkgdbpath, 
> strlen(pkgdbpath)+1);
> + n = strlcpy(tmp_file, pkgdbpath, 
> sizeof(tmp_file));
>   n = strlcpy(tmp_file + n, "/", 
> sizeof(tmp_file) - n);
>   n = strlcat(tmp_file + n, 
> pkgdbdir->d_name,
>   sizeof(tmp_file) - n);

Either use strlcat without the pointer modifications or just go with
snprintf in first place. This is bogus...

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r196752 - head/lib/libc/stdtime

[Joerg Sonnenberger]

On Thu, Sep 03, 2009 at 11:08:26AM +0200, Dag-Erling Smørgrav wrote:
> @@ -65,6 +65,15 @@
>  .It "\&031\ EM \t032\ SUB \t033\ ESC \t034\ FS \t035\ GS"
>  .It "\&036\ RS \t037\ US \t177\ DEL"
>  .El
> +.Pp
> +.Em NOTE :
> +if the value passed to the
> +.Fn iscntrl
> +function is a
> +.Vt signed char ,
> +as is usually the case, it must be cast to an
> +.Vt unsigned char
> +to avoid sign-extension errors.
>  .Sh RETURN VALUES
>  The
>  .Fn iscntrl

This is actually not good enough. ISO C doesn't specify whether plain
char is signed or unsigned.

Also, isascii is the only exception to this rule, so the change for that
is wrong.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r196752 - head/lib/libc/stdtime

[Joerg Sonnenberger]

On Thu, Sep 03, 2009 at 03:25:26PM +0200, Dag-Erling Smørgrav wrote:
> > This is actually not good enough. ISO C doesn't specify whether plain
> > char is signed or unsigned.
> 
> This is FreeBSD.  Our char is signed.  On systems where it isn't (IRIX
> is the only one I know of), the cast is a no-op.

GCC's default for ARM is unsigned. Just to name the most popular
platform. I don't know if FreeBSD has local patches, but I expect a
non-trivial amount of code is ported from/to ARM systems as well.

> 
> > Also, isascii is the only exception to this rule, so the change for that
> > is wrong.
> 
> No.  The fact that isascii() accidentally returns the correct answer
> even in the absence of a cast is irrelevant.  Passing a signed char to
> isascii() invokes undefined behavior.

To quote SUS:

The isascii() function shall return non-zero if c is a 7-bit US-ASCII
character code between 0 and octal 0177 inclusive; otherwise, it shall
return 0.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r225815 - head/usr.bin/fetch

[Joerg Sonnenberger]

On Wed, Sep 28, 2011 at 02:47:22PM +0200, Dag-Erling Smørgrav wrote:
> > Maybe it would be nice if both files were UTF-8, but I'm not sure if
> > manpages support that.
> 
> They do.

Not really. If it seems to work, it is by accident, not by design.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r219084 - in head: bin/test tools/regression/bin/test

[Joerg Sonnenberger]

On Sun, Feb 27, 2011 at 12:28:06PM +, Xin LI wrote:
> Author: delphij
> Date: Sun Feb 27 12:28:06 2011
> New Revision: 219084
> URL: http://svn.freebsd.org/changeset/base/219084
> 
> Log:
>   Accept == as an alias of = which is a popular GNU extension.

It is not a popular GNU extension. It is crap only bash supports.
Do you really want to encourage that?

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r219084 - in head: bin/test tools/regression/bin/test

[Joerg Sonnenberger]

On Sun, Feb 27, 2011 at 03:11:43PM +0100, Erik Trulsson wrote:
> On Sun, Feb 27, 2011 at 01:30:58PM +0100, Joerg Sonnenberger wrote:
> > On Sun, Feb 27, 2011 at 12:28:06PM +, Xin LI wrote:
> > > Author: delphij
> > > Date: Sun Feb 27 12:28:06 2011
> > > New Revision: 219084
> > > URL: http://svn.freebsd.org/changeset/base/219084
> > > 
> > > Log:
> > >   Accept == as an alias of = which is a popular GNU extension.
> > 
> > It is not a popular GNU extension. It is crap only bash supports.
> > Do you really want to encourage that?
> 
> In what way is it 'crap', and in what way would adding support for it
> be a problem?

It is completely redundant and inconsistent with pretty much every other
test(1) implementation. E.g. it isn't even supported by /bin/test from
coretutils. The very presence of this in various shell scripts is a
direct result of silently accepting it in bash, even in sh mode. This is
just further encouragement to legalize it.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r261283 - in head: contrib/libc++ contrib/libc++/include contrib/libc++/include/experimental contrib/libc++/include/ext contrib/libc++/src etc/mtree lib/libc++ sys/sys tools/build/mk

[Joerg Sonnenberger]

On Tue, Feb 04, 2014 at 12:07:29PM -0700, Warner Losh wrote:
> 
> On Feb 4, 2014, at 1:41 AM, David Chisnall wrote:
> > It sounds like you're just looking at the output from nm, without bothering 
> > to check how the symbols are used.  
> 
> With all due respect, if it is in nm output, it is part of the ABI,
> intended or not.

With all due respect, a lot of people disagree with that. Now, whether
or not those symbol should have been hidden is a separate issue.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r257203 - head/sys/arm/arm

[Joerg Sonnenberger]

On Mon, Oct 28, 2013 at 08:43:37AM +1100, Bruce Evans wrote:
> Oops, the parser easily can't do this right because macro parameters
> must usually have redundant parentheses and C parsers are specified
> to act as if on the output of the preprocessor so they can't easily
> either have a special case to ignore these redundant parentheses or
> know that they aren't in the unpreprocessed source so they should be
> ignored.

Did you bother to try your assumptions about the compiler in question?

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r232275 - in head/sys: amd64/include i386/include pc98/include x86/include

[Joerg Sonnenberger]

On Fri, Mar 02, 2012 at 03:11:21PM +1100, Bruce Evans wrote:
> >If we could add the returns_twice attribute to setjmp() then the
> >compiler makes sure all registers are dead before calling it and
> >jmp_buf wouldn't have to be that big.
> 
> I think compilers already do stuff like that automatically.  They have
> to for setjmp() to work.  Since there was no way to declare such
> attributes 20 years ago, compilers had to know that setjmp() was
> special and make it work when it only has a Standard C declaration
> (and some magic in its inmplementation).

It is an existing bug in FreeBSD that the *kernel* doesn't have such
attribution. Since it is using -ffreestanding, interference is
incorrect. LLVM recently moved the attribution logic from the LLVM
librarie into the C frontend where it belongs, but this does have the
negative side effect that it no longer magically fixes up issues for
-ffreestanding.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r232894 - head/contrib/llvm/tools/clang/lib/Basic

[Joerg Sonnenberger]

On Tue, Mar 13, 2012 at 04:14:25PM +1100, Bruce Evans wrote:
> clang and gcc define __FLT_EVAL_METHOD__, but get it wrong in different
> ways, so this definition is unusuable.  For example, it is always 0 for
> clang; this is correct with SSE, but without SSE, -1 is correct.  Thus
> __FLT_EVAL_METHOD__ is unusable for defining FLT_EVAL_METHOD.

Upstream version sets it correctly, the change went in either shortly
before or after 3.0 release. I.e. clang -target i386-freebsd -mno-sse uses
__FLT_EVAL_METHOD__ 2, clang -target i386-freebsd -msse uses
__FLT_EVAL_METHOD__ 0.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r230231 - head/sys/kern

[Joerg Sonnenberger]

On Mon, Jan 16, 2012 at 08:42:56PM +, Sergey Kandaurov wrote:
> Log:
>   Be pedantic and change // comment to C-style one.

If you want to be pedantic, at least be correct. // is perfectly valid
C99.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r230864 - in head: lib/libc/amd64/gen lib/libc/arm/gen lib/libc/i386/gen lib/libc/ia64/gen lib/libc/mips/gen lib/libc/powerpc/gen lib/libc/powerpc64/gen lib/libc/sparc64/gen sys/sys

[Joerg Sonnenberger]

On Wed, Feb 01, 2012 at 01:33:53PM +, Konstantin Belousov wrote:
> Log:
>   Make the sys/ucontext.h self-contained by changing the return type
>   of __getcontextx_size(3) from size_t to int.

Are you sure that this doesn't break the ABI? That is: are you sure that
it doesn't return garbage in the higher 32bit on LP64 platforms?

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r243665 - head/sbin/dump

[Joerg Sonnenberger]

On Thu, Nov 29, 2012 at 02:01:47PM +0200, Konstantin Belousov wrote:
> Also, being quite removed from the function definition, there is a chance
> that some future modification would make the attribute a lie.

At least clang enforces the correctness of the attribute.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r244760 - head/sys/kern

[Joerg Sonnenberger]

On Fri, Dec 28, 2012 at 02:43:33AM +, David Xu wrote:
> Author: davidxu
> Date: Fri Dec 28 02:43:33 2012
> New Revision: 244760
> URL: http://svnweb.freebsd.org/changeset/base/244760
> 
> Log:
>   Use strlcpy to NULL-terminate error message even if user provided a short
>   buffer.

Are you sure that none of this depends on the zeroing behavior of
strncpy?

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r236582 - head/lib/libc/stdlib

[Joerg Sonnenberger]

On Tue, Jun 05, 2012 at 04:39:01PM +0400, Andrey Chernov wrote:
> Moreover, standard metion "unsuccessful call" case for free() where errno 
> state is totally undefined.

...which would be a programming mistake in first place and is valid as
justification.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r236582 - head/lib/libc/stdlib

[Joerg Sonnenberger]

On Tue, Jun 05, 2012 at 05:13:05PM +0400, Andrey Chernov wrote:
> On Tue, Jun 05, 2012 at 02:55:20PM +0200, Joerg Sonnenberger wrote:
> > On Tue, Jun 05, 2012 at 04:39:01PM +0400, Andrey Chernov wrote:
> > > Moreover, standard metion "unsuccessful call" case for free() where errno 
> > > state is totally undefined.
> > 
> > ...which would be a programming mistake in first place and is valid as
> > justification.
> 
> Not only that (I mean programming mistake in the realpath). F.e. internal 
> free/malloc state can be damaged by other code even earlier. But all of 
> this is not the case, since POSIX allows it to modify errno on _success_,
> which is main reason of the change.
> Please see 
> http://austingroupbugs.net/view.php?id=385

That is about explicitly recognizing how stupid the notion of free(3)
not preserving errno is. Seriously, before you start to randomly bloat
code all over the place, restricting the behavior of free(3) to be
sensible is a much saner option.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r236582 - head/lib/libc/stdlib

[Joerg Sonnenberger]

On Tue, Jun 05, 2012 at 06:31:14PM +0400, Andrey Chernov wrote:
> BTW, if general consensus will be to track unpublished standard, I will 
> back out my change (in hope our malloc() maintainer will change free() to 
> directly save errno).

The standard is quite irrelevant here. FreeBSD is free to require a more
restricted behavior of free(3).

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r236582 - head/lib/libc/stdlib

[Joerg Sonnenberger]

On Wed, Jun 06, 2012 at 01:01:54AM +0400, Andrey Chernov wrote:
> On Wed, Jun 06, 2012 at 06:11:01AM +1000, Bruce Evans wrote:
> > This is essentially unusable (so a bad idea).  Instead of unconditionally
> > saving and restoring errno around calls to free(), portable POSIX code
> > can soon use a messy ifdef to avoid doing this in some cases, but still
> > has to do it in other cases.  The results is just bloat and complexity
> > at the source level:
> 
> It looks like they now consider POSIX as moving target where previous 
> POSIX versions compatibility is not so essential to care about much. I 
> don't have other interpretation of their decision to suddenly accept 
> free() as not modifying errno. Since they clearly indicate code 
> differences for old and new standard, they are well aware of them and of 
> resulting code bloating.

Can you please stop the unjustified rants? The "new" behavior of free(3)
doesn't break any existing code, so it is certainly compatible with
"old" free(3). The "new" behavior can be obtained easily for code that
wants to be portable to "old" implementations using the C preprocessor
and a small inline wrapper. As such, there is no code bloating.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r233700 - head/sys/kern

[Joerg Sonnenberger]

On Fri, Mar 30, 2012 at 09:49:51PM +0200, Dimitry Andric wrote:
> On 2012-03-30 15:30, Stefan Farfeleder wrote:
> >here are a few similar cases.
> 
> Hm, what about this one that clang warns about:
> 
>   sys/dev/asr/asr.c:2420:57: warning: for loop has empty body [-Wempty-body]
> for (ha = &Asr_softc_list; *ha; ha = &((*ha)->ha_next));
>^
>   sys/dev/asr/asr.c:2420:57: note: put the semicolon on a separate line to 
> silence this warning [-Wempty-body]
> 
> I'm not sure about it though, the code looks like this:
> 
> static int
> asr_attach(device_t dev)
> {
> [...]
> Asr_softc_t  *sc, **ha;
> [...]
> LIST_INIT(&(sc->ha_ccb));
> /* Link us into the HA list */
> for (ha = &Asr_softc_list; *ha; ha = &((*ha)->ha_next));
> *(ha) = sc;
> 
> It seems the for loop walks the list until the end, then tacks 'sc' onto
> it.
> 
> So to 'fix' the warning, and make the meaning more explicit, we should
> probably rewrite that fragment as:
> 
> LIST_INIT(&(sc->ha_ccb));
> /* Link us into the HA list */
> for (ha = &Asr_softc_list; *ha; ha = &((*ha)->ha_next))
>   ;
>   *(ha) = sc;

I would really just move the ha = into the loop body -- same semantic
and no such issue as a dangling ;.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r234353 - in head: . contrib/llvm contrib/llvm/include/llvm contrib/llvm/include/llvm-c contrib/llvm/include/llvm-c/Transforms contrib/llvm/include/llvm/ADT contrib/llvm/include/llvm/A

[Joerg Sonnenberger]

On Thu, Apr 19, 2012 at 09:14:41PM +, Alexander Best wrote:
> On Mon Apr 16 12, Dimitry Andric wrote:
> > Author: dim
> > Date: Mon Apr 16 21:23:25 2012
> > New Revision: 234353
> > URL: http://svn.freebsd.org/changeset/base/234353
> > 
> > Log:
> >   Upgrade our copy of llvm/clang to trunk r154661, in preparation of the
> >   upcoming 3.1 release (expected in a few weeks).  Preliminary release
> >   notes can be found at: 
> 
> very nice. :)
> 
> any reason '-fformat-extensions'-support still hasn't been pushed upstream as
> something like '-fbsd-extensions'?

I think it's the wrong approach. What about adding a freebsd_printf
format modifer (similar to the existing gnu_printf) and tagging the
kernel printf accordingly?

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r235209 - head/games/fortune/datfiles

[Joerg Sonnenberger]

On Wed, May 09, 2012 at 04:05:09PM -0700, Garrett Cooper wrote:
> I've been told multiple times that YMMV for make -C vs cd ; make, FYI,
> so I've modified my behavior to match the cd ; make idiom. Interesting
> why I've only been told this in BSD circles though...

Please note that it should be cd && make, at least some version of make
implement the (old?) POSIX make behavior of using set -e by default.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r247713 - head/lib/libedit

[Joerg Sonnenberger]

On Sun, Mar 03, 2013 at 10:34:36AM -0500, Pedro Giffuni wrote:
> I have no idea why NetBSD survives without linking ncurses here but
> next time I will test this further before trusting the package author.

libedit links against libterminfo on NetBSD.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r189765 - in head: . lib/libc lib/libc/nls

[Joerg Sonnenberger]

On Fri, Mar 13, 2009 at 01:36:07PM -0500, Sean C. Farley wrote:
> I have not explored either.  The Citrus version appears to have more  
> functionality, however, the Citrus website is ambiguous about the  
> license.

Please forget whatever you read on the Citrus website and just look
inside the NetBSD repository.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r199670 - head/sys/dev/bge

[Joerg Sonnenberger]

On Sun, Nov 22, 2009 at 08:50:27PM +, Pyun YongHyeon wrote:
> Log:
>   Fix two long standing bugs on bge(4). Most pre BCM5755 controllers
>   have a DMA bug when buffer address crosses a multiple of the 4GB
>   boundary(e.g. 4GB, 8GB, 12GB etc).

Does this only affect transfers that *cross* a 4GB boundary or does it
also affect transfers that *end* at a 4GB boundary? E.g. if the mbuf
cluster starts at 0xff00 with size 0x100 -- will the DMA engine
stall happen or not?

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r199670 - head/sys/dev/bge

[Joerg Sonnenberger]

On Mon, Nov 23, 2009 at 12:53:24PM -0800, Pyun YongHyeon wrote:
> On Mon, Nov 23, 2009 at 02:05:11AM +0100, Joerg Sonnenberger wrote:
> > On Sun, Nov 22, 2009 at 08:50:27PM +, Pyun YongHyeon wrote:
> > > Log:
> > >   Fix two long standing bugs on bge(4). Most pre BCM5755 controllers
> > >   have a DMA bug when buffer address crosses a multiple of the 4GB
> > >   boundary(e.g. 4GB, 8GB, 12GB etc).
> > 
> > Does this only affect transfers that *cross* a 4GB boundary or does it
> > also affect transfers that *end* at a 4GB boundary? E.g. if the mbuf
> > cluster starts at 0xff00 with size 0x100 -- will the DMA engine
> > stall happen or not?
> > 
> 
> AFAIK publicly available datasheet explicitly mentions 4GB boundary
> limitation(page 153). For BCM5704 case, the datasheet also says
> buffer descriptors that ends exactly on any multiple of 4GB,
> BCM5704 will generate host address overflow error even though the
> buffer descriptor does not actually cross over the 4GB boundary
> (page 213).

I'm asking because the case of crossing the 4GB boundary could be
handled transparently via scatter/gather register. If the address
overflow happens for the boundary, a work-around in the bus-dma layer
would still be applied easy when scatter/gather is supported by the
device to bounce the last cache line or so.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r210578 - head/usr.bin/grep

[Joerg Sonnenberger]

On Thu, Jul 29, 2010 at 12:11:14AM +, Gabor Kovesdan wrote:
>   - Some improvements on the exiting code, like replacing memcpy with
> strlcpy/strcpy

Why is this an improvement? At least for non-trivial sizes, it is quite
likely to be a regression. Especially using strlcpy as replacement for
memcpy+\0 is bogus.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r201999 - head/lib/libc/stdio

[Joerg Sonnenberger]

On Mon, Jan 11, 2010 at 02:29:03PM +1100, Bruce Evans wrote:
> calloc() has the same overflow bug, if any.  Standards seem to require
> fread and calloc to work even if the multiplication would occur, though
> they cannot work in most cases where the multiplication would occur,
> even if the overflow is avoided.

Well, calloc on any BSD supported architecture can not allocate more
than SIZE_MAX (or SIZE_MAX itself). There is an error defined for that.
fread and fwrite will access invalid addressses, so doing nothing would
be a correct implementation of "undefined". Cutting it off at
SIZE_MAX/size seems silly as it would give the same behavior.

Frankly, I would just back this out and let the application hit the
wall...

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r186529 - head/sys/dev/acpi_support

[Joerg Sonnenberger]

On Sun, Dec 28, 2008 at 10:00:37PM +0100, Dimitry Andric wrote:
> On 2008-12-28 20:30, Stanislav Sedov wrote:
> >>> - ACPI_OBJECT acpiarg[0];
> >>> + ACPI_OBJECT acpiarg[1];
> > I wonder how does gcc allowed this. It emits warnings only in
> > pedantic mode which we cannot use to compile kernel with.
> 
> Zero-sized arrays are non-standard, but have been allowed by gcc (and
> many other compilers) since a long time, so it is logical that it
> doesn't warn about it by default.

Having no size at all would be standard compliant, e.g. acpiarg[[];

Joreg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r187713 - head/sbin/ipfw

[Joerg Sonnenberger]

On Mon, Jan 26, 2009 at 02:03:39PM +, Luigi Rizzo wrote:
>   Some implementations of getopt() expect that argv[0] is always the
>   program name, and ignore that entry.  ipfw2.c code instead skips
>   this entry and starts with options at offset 0, relying on a more
>   tolerant implementation of the library.

This is not true. Some (aka GNU) implementation consider optind = 0 as
reset condition.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r194493 - head/usr.bin/catman

[Joerg Sonnenberger]

On Sun, Jun 21, 2009 at 08:12:51PM -0500, Matthew D. Fuller wrote:
> Actually, I looked at this sort of things some years ago when I was
> sitting in front of a PPro (which was way outdated by that time), and
> even the largest manpage I could find in base didn't take more than 6
> or 8 seconds to render.

At 800MHz, the GCC man page needs 3 seconds on a Core2...

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r194681 - head/usr.sbin/wpa/ndis_events

[Joerg Sonnenberger]

On Wed, Jul 01, 2009 at 03:25:33PM +0400, Maxim Konovalov wrote:
> static void
> usage()
> {
>   /* Insert an empty line if the function has no local variables. */
> ...
> 
> Apart from the empty line, what's wrong?

It is K&R style. It should be

static void
usage(void)
{
...

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r184471 - in head/bin: cat cp

[Joerg Sonnenberger]

On Mon, Nov 03, 2008 at 12:34:47AM +0100, Ivan Voras wrote:
> > It looks like it's probably worth pushing the limit up to 8 MB when we
> > have lots of memory :)
> 
> Yes, it's an improvement, but who will ever notice? :)

Is even the improvement from 64KB to 1MB even measurable? I mean on
anything but a VAX...

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: svn commit: r184605 - head/sys/dev/usb

[Joerg Sonnenberger]

On Mon, Nov 03, 2008 at 11:49:50PM +0100, Christoph Mallon wrote:
> You may want to make cmd[] static and/or const, so the compiler really  
> just puts the bytes in the data section instead of generating code,  
> which pretty much is the same as the assignments you just removed.

I didn't make it const originally as I am not sure if the USB stack will
never modify the buffer.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: svn commit: r185674 - head/lib/libarchive

[Joerg Sonnenberger]

On Mon, Dec 08, 2008 at 02:14:32PM +0900, Bang Jun-young wrote:
> MSC actually supports inline functions as '__inline' keyword in C mode. The
> above should be written as follows:

Can you say that for all versions? Besides, it will very likely inline
this anyway, so it doesn't matter very much.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: svn commit: r206043 - in head/usr.sbin/pkg_install: add delete lib version

[Joerg Sonnenberger]

On Thu, Apr 01, 2010 at 05:02:34PM -0700, Garrett Cooper wrote:
> 1. FILENAME_MAX could be less than PATH_MAX, and actually is on
> the BSDs (256 vs 1024). PATH_MAX allows for duplicate slashes and all
> sorts of whacky path crud and probably should be used more liberally
> in the pkg_install code. This however isn't always true in the NetBSD
> case because they're aiming for portability of pkg_install, however
> PATH_MAX is always guaranteed to be at least as large as FILENAME_MAX.

Well, I've been slowly working on eliminating the use of PATH_MAX in the
NetBSD/pkgsrc version of pkg_install. The performance gain from using
fixed stack space is minimal and the error handling generally
incompletely at best.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r206043 - in head/usr.sbin/pkg_install: add delete lib version

[Joerg Sonnenberger]

On Sat, Apr 03, 2010 at 04:32:15AM -0700, Garrett Cooper wrote:
>I'm sorry but I'm a little bit confused by this statement: do you
> mean that you're replacing PATH_MAX sized buffers to FILENAME_MAX
> sized buffers? If so this may cause an issue because several of the
> variables used in constructing the file paths in pkg_install aren't
> necessarily correct in overflow cases. We need to avoid introducing
> potential functional flaws with filename truncation like this.

No, I am replacing fixed size buffers with variable size buffers. The
extraction code should generally be able to support arbitrary deep path
names, for the rest the kernel can complain.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r206843 - head/sbin/ipfw

[Joerg Sonnenberger]

On Mon, Apr 19, 2010 at 03:44:25PM -0700, Julian Elischer wrote:
> >Index: sbin/ipfw/ipfw2.c
> >===
> >--- sbin/ipfw/ipfw2.c (revision 206844)
> >+++ sbin/ipfw/ipfw2.c (working copy)
> >@@ -326,7 +326,7 @@
> >#ifdef TCC
> >#define U64_FMT "I64"
> >#else
> >-#define U64_FMT "llu"
> >+#define U64_FMT "ju"
> >#endif
> >uint64_t d;
> 
>  believe there is a posix define for this?
> (though I can't remember it right now).

PRIu64

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r204493 - head/lib/libc/stdlib

[Joerg Sonnenberger]

On Tue, Mar 02, 2010 at 12:04:02PM +, Bruce Simpson wrote:
> Have you looked at  ? It is used by pf and the multicast code.

The implementation in sys/tree.h is certainly not the most efficient on
various scales.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r192908 - in head: share/man/man9 sys/conf sys/kern sys/sys

[Joerg Sonnenberger]

On Thu, May 28, 2009 at 07:28:45PM +0200, Dag-Erling Sm?rgrav wrote:
> "Bruce A. Mah"  writes:
> > My understanding is that we do this to let groff manage the whitespace
> > between sentences.
> 
> Groff doesn't need anyone's help to manage the whitespace between
> sentences...

A short example. Another sentence
!=
A short example.  Another sentence
=
A short example.
Another sentence

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r268566 - head/usr.bin/users

[Joerg Sonnenberger]

On Sat, Jul 12, 2014 at 09:34:28PM +1000, Bruce Evans wrote:
> Run time:
> C++ sort() was twice as slow as qsort() for sorting 1 million dummy
> users in the allocation tests.  About 8 seconds instead of 4, except
> when compiled with -g -O0 it was 15 seconds instead of 4.

I find that claim strange and not reproducable. In my tests, std::sort
tends to be significant faster than qsort. Attached is a small test
program that for me is twice as fast for sorting integers...

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r268566 - head/usr.bin/users

[Joerg Sonnenberger]

On Mon, Jul 14, 2014 at 08:37:56PM +0100, Alexander Nasonov wrote:
> Joerg Sonnenberger wrote:
> > On Sat, Jul 12, 2014 at 09:34:28PM +1000, Bruce Evans wrote:
> > > Run time:
> > > C++ sort() was twice as slow as qsort() for sorting 1 million dummy
> > > users in the allocation tests.  About 8 seconds instead of 4, except
> > > when compiled with -g -O0 it was 15 seconds instead of 4.
> > 
> > I find that claim strange and not reproducable. In my tests, std::sort
> > tends to be significant faster than qsort. Attached is a small test
> > program that for me is twice as fast for sorting integers...
> 
> Integers are faster indeed but I'm not sure about used-defined
> types like basic_string. qsort uses 3-way
> comparison while std::sort always uses less_than (a The compiler can optimize when a and b are integers but not when
> they're user-defined types with a user-defined comparison function.

The trinary vs binary partial order function only matters if you have
lots of duplicate values.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r273331 - in head: sbin/ifconfig share/man/man4 sys/conf sys/modules sys/modules/if_vxlan sys/net sys/sys

[Joerg Sonnenberger]

On Mon, Dec 01, 2014 at 03:24:20PM +0100, Dag-Erling Smørgrav wrote:
> Adrian Chadd  writes:
> > Dag-Erling Smørgrav  writes:
> > > I added code to cmd_register() in ifconfig.c to warn about duplicate
> > > commands.  [...]
> > Would you mind committing that code, so we at least get warned about
> > it when we try?
> 
> It's quadratic and runs every time a set of commands is added, which
> means the total running time is closer to n! than n^2.  I can add it
> with an #ifdef, but that's not very useful.  It would be better to
> rewrite ifconfig to use a hash table instead of a linked list.

Can't you use a simple bloom filter to cover 99% of the cases and just
fallback to a simple search on match?

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r276565 - in head/gnu: lib/libstdc++/doc usr.bin/diff usr.bin/diff/doc usr.bin/gdb usr.bin/gperf usr.bin/gperf/doc

[Joerg Sonnenberger]

On Fri, Jan 02, 2015 at 10:35:57PM +0100, Baptiste Daroussin wrote:
> The man pages remains, for binutils for examples, the manpages were generated
> out of the texinfo files meaning the manpage contains the same amount of
> informations

Have you actually looked at them? as(1) for example doesn't contain the
language description.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r277203 - in head/sys: kern sys

[Joerg Sonnenberger]

On Wed, Jan 14, 2015 at 11:44:00PM +, Robert Watson wrote:
>   - As we anticipate embedding mbufs headers within variable-size regions of
> memory in the future, change the definitions of byte arrays embedded in
> mbufs to be of size [0] rather than [MLEN] and [MHLEN].

This is not valid C. You may be able to use flexible array members ([])
instead.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r281959 - head/usr.bin/whois

[Joerg Sonnenberger]

On Sat, Apr 25, 2015 at 12:51:44AM +, Xin LI wrote:
>   Attempt to connect to alternate addresses if the connect doesn't
>   succeed in 180ms, and cut wait time between connection attempts
>   in half for each additional, if no connection was established.

180ms is very short. I have such latency over 2G, 3G and 4G most of the
time, soo wouldn't this make whois pretty much useless on such
connections?

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r281959 - head/usr.bin/whois

[Joerg Sonnenberger]

On Sat, Apr 25, 2015 at 11:04:46AM -0400, Shawn Webb wrote:
> On Sat, 2015-04-25 at 16:51 +0200, Joerg Sonnenberger wrote:
> > On Sat, Apr 25, 2015 at 12:51:44AM +, Xin LI wrote:
> > >   Attempt to connect to alternate addresses if the connect doesn't
> > >   succeed in 180ms, and cut wait time between connection attempts
> > >   in half for each additional, if no connection was established.
> > 
> > 180ms is very short. I have such latency over 2G, 3G and 4G most of the
> > time, soo wouldn't this make whois pretty much useless on such
> > connections?
> 
> Google Chromium/Chrome uses a 300ms timeout when falling back from IPv6
> to IPv4. Maybe the 180ms timeout should be increased to match?

They do the connection in parallel, don't they?

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r279236 - head/sys/netinet

[Joerg Sonnenberger]

On Tue, Feb 24, 2015 at 11:59:02AM -0700, Ian Lepore wrote:
> ETHER_ALIGN is wonderful... if you're on a platform that can DMA to an
> arbitrary boundary.

Isn't it generally more a case of "if the device's DMA engine isn't
extremely bad designed"? There is a strong correlation between devices
not supporting DMA to arbitrary locations and devices requiring a single
data segment. Heck, from a design point of few there is no justification
for not supporting skipping a few byte at the start of the receive. The
device can easily just add two bytes of noise to make it double word
aligned if necessary... VIA Rhine forever!

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r279236 - head/sys/netinet

[Joerg Sonnenberger]

On Tue, Feb 24, 2015 at 12:57:04PM +, Zbigniew Bodek wrote:
>   In fact, the assumption that 'struct ip' is always 4-byte aligned
>   is definitely false, as we have no impact on data alignment of packet
>   stream received.

Pretty much all drivers do guarantee this by setting up buffers
accordingly. Why can't yours do the same?

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: Deorbiting i386

[Joerg Sonnenberger]

On Sun, May 27, 2018 at 03:15:05PM -0700, Maxim Sobolev wrote:
> Well, strip extra 32 bits, use slower memory and busses (extra decoding
> logic etc). Voila, you suddenly have platform that can run 99% of code in
> wild today with just few hundred mW of power. Try that with arm32, you
> would be surprised how many software is technically compiling and all that,
> but has some weird runtime issues with either byte order or unaligned
> memory accesses. Not even mention performance issues due to the lack of
> hand-crafted JITs.

Surprisingly, neither unaligned memory access nor byte order is really a
problem on ARM. The first can be turned off on all but vintage CPUs and
the latter is typically LE nowadays if not runtime switchable. The two
portability gotchas for ARM are entirely different things:
(1) char == unsigned char
(2) Over-sized shifts are saturing.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362333 - in head: contrib/flex contrib/flex/src usr.bin/lex usr.bin/lex/lib

[Joerg Sonnenberger]

On Wed, Jun 24, 2020 at 12:09:03PM +0200, Dimitry Andric wrote:
> On 24 Jun 2020, at 02:41, Kyle Evans  wrote:
> > 
> > On Thu, Jun 18, 2020 at 1:09 PM Jung-uk Kim  wrote:
> >> 
> >> Author: jkim
> >> Date: Thu Jun 18 18:09:16 2020
> >> New Revision: 362333
> >> URL: https://svnweb.freebsd.org/changeset/base/362333
> >> 
> >> Log:
> >>  MFV:  r362286
> >> 
> >>  Merge flex 2.6.4.
> >> 
> > 
> > Hi,
> > 
> > I'm looking at getting amd64 world buildable again by gcc6; this seems
> > to give it some gas:
> > 
> > /usr/src/contrib/flex/src/main.c: In function 'check_options':
> > /usr/src/contrib/flex/src/main.c:347:14: error: assignment discards
> > 'const' qualifier from pointer target type
> > [-Werror=discarded-qualifiers]
> >   if ((slash = strrchr(M4, '/')) != NULL) {
> > 
> > The following trivial patch seems to make gcc6 happy again.
> 
> This is a strange one. As gcc6 has been removed from ports, I had to
> resort to an older 12-STABLE box which still had it, but no matter what
> I try, I cannot get the warning that is being produced by the CI system.
> What does it do differently?
> 
> Also, the warning is indeed bogus, as strrchr() returns a non-const char
> pointer. As I can't reproduce it, I also can't verify which gcc version
> fixes the bogus warning.

The warning is correct if you have a C++-aware string.h. It will provide
two overloads for strrchr, which return the constness of the argument.
So if you give it a const char *, it returns a const char *; if you give
it a char *, it returns a char *.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r343633 - head/usr.bin/shar

[Joerg Sonnenberger]

On Thu, Jan 31, 2019 at 03:29:03PM -0800, Bryan Drewery wrote:
> On 1/31/19 3:21 PM, Bryan Drewery wrote:
> > Author: bdrewery
> > Date: Thu Jan 31 23:21:18 2019
> > New Revision: 343633
> > URL: https://svnweb.freebsd.org/changeset/base/343633
> > 
> > Log:
> >   Shar files may be seen as binary by grep.
> >   
> >   Suggest using -a to egrep to properly see executed commands.
> >   
> >   This is a minor improvement to the manpage.  A better improvement
> >   would be removal or gigantic warnings.
> 
> I dare someone to remove this utility.
> There may still be documentation suggesting its use somewhere due to
> pre-bugzilla days but now we can do proper binary attachments I believe.

bsdtar --format shar?

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r355569 - head/sys/amd64/linux32

[Joerg Sonnenberger]

On Mon, Dec 09, 2019 at 07:18:06PM +, John Baldwin wrote:
> Author: jhb
> Date: Mon Dec  9 19:18:05 2019
> New Revision: 355569
> URL: https://svnweb.freebsd.org/changeset/base/355569
> 
> Log:
>   Use 4 byte stack alignment instead of 8 byte.
>   
>   This was an old bug prior to r355373 and mostly harmless as it would
>   waste at most a handful of bytes on the stack.

Doesn't Linux assume 128bit alignment for i386 nowadays?

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r308563 - in head/lib: libgcc_eh libgcc_s

[Joerg Sonnenberger]

On Fri, Nov 11, 2016 at 11:28:08PM +, Ed Maste wrote:
> Author: emaste
> Date: Fri Nov 11 23:28:07 2016
> New Revision: 308563
> URL: https://svnweb.freebsd.org/changeset/base/308563
> 
> Log:
>   libcc_{s,eh}: build without SSP
>   
>   As in the gnu/lib/libgcc Makefile:
>   libgcc is linked in last and thus cannot depend on ssp
>   symbols coming from earlier libraries. Disable stack protection
>   for this library.

That doesn't make sense to me given that libgcc_s at least definitely
depends on libc for the system calls?

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r333482 - head/usr.bin/expand

[Joerg Sonnenberger]

On Fri, May 11, 2018 at 04:57:06PM -0700, John Baldwin wrote:
> On Friday, May 11, 2018 06:55:03 AM Eitan Adler wrote:
> > Author: eadler
> > Date: Fri May 11 06:55:02 2018
> > New Revision: 333482
> > URL: https://svnweb.freebsd.org/changeset/base/333482
> > 
> > Log:
> >   [expand] add __dead2 annotation to usage
> 
> Can't any modern compiler infer this already from the call to exit() at the 
> end?

A modern compiler can certainly infer that all branches are dead, but it
can't infer if that is the intention. That can make a huge difference
for any code analysis.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r305392 - head/sys/conf

[Joerg Sonnenberger]

On Sun, Sep 04, 2016 at 09:31:19PM +0200, Dimitry Andric wrote:
> On 04 Sep 2016, at 20:57, Conrad Meyer  wrote:
> > 
> > On Sun, Sep 4, 2016 at 10:55 AM, Dimitry Andric  wrote:
> >> Author: dim
> >> Date: Sun Sep  4 17:55:22 2016
> >> New Revision: 305392
> >> URL: https://svnweb.freebsd.org/changeset/base/305392
> >> 
> >> Log:
> >>  For kernel builds, instead of suppressing certain clang warnings, make
> >>  them non-fatal, so there is some incentive to fix them eventually.
> >> 
> >> Modified:
> >>  head/sys/conf/kern.mk
> >> 
> >> Modified: head/sys/conf/kern.mk
> >> ==
> >> --- head/sys/conf/kern.mk   Sun Sep  4 17:50:23 2016(r305391)
> >> +++ head/sys/conf/kern.mk   Sun Sep  4 17:55:22 2016(r305392)
> >> @@ -17,13 +17,13 @@ CWARNFLAGS?=-Wall -Wredundant-decls -Wn
> >> # kernel where fixing them is more trouble than it is worth, or where 
> >> there is
> >> # a false positive.
> >> .if ${COMPILER_TYPE} == "clang"
> >> -NO_WCONSTANT_CONVERSION=   -Wno-constant-conversion
> >> -NO_WSHIFT_COUNT_NEGATIVE=  -Wno-shift-count-negative
> >> -NO_WSHIFT_COUNT_OVERFLOW=  -Wno-shift-count-overflow
> >> -NO_WSELF_ASSIGN=   -Wno-self-assign
> >> -NO_WUNNEEDED_INTERNAL_DECL=-Wno-unneeded-internal-declaration
> >> +NO_WCONSTANT_CONVERSION=   -Wno-error-constant-conversion
> >> +NO_WSHIFT_COUNT_NEGATIVE=  -Wno-error-shift-count-negative
> >> +NO_WSHIFT_COUNT_OVERFLOW=  -Wno-error-shift-count-overflow
> >> +NO_WSELF_ASSIGN=   -Wno-error-self-assign
> >> +NO_WUNNEEDED_INTERNAL_DECL=-Wno-error-unneeded-internal-declaration
> >> NO_WSOMETIMES_UNINITIALIZED=   -Wno-error-sometimes-uninitialized
> >> -NO_WCAST_QUAL= -Wno-cast-qual
> >> +NO_WCAST_QUAL= -Wno-error-cast-qual
> > 
> > I like goal of the change.  Shouldn't these be -Wno-error=cast-qual,
> > etc., though?
> 
> That's how gcc spells them.  Clang accepts both forms, there is no
> functional difference.

Actually, GCC documents them as -W(no-)error=* as well.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r328446 - head/stand/uboot/lib

[Joerg Sonnenberger]

On Fri, Jan 26, 2018 at 09:51:00PM +, Warner Losh wrote:
> Author: imp
> Date: Fri Jan 26 21:50:59 2018
> New Revision: 328446
> URL: https://svnweb.freebsd.org/changeset/base/328446
> 
> Log:
>   Now that exit is __dead2, we need to tag ub_exit() as __dead2. To do
>   that, we have to put a while (1); after the syscall that will never
>   return to fake out the compiler

__builtin_unreachable() ?

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r329164 - in head: include sys/amd64/include sys/i386/include sys/mips/include sys/powerpc/include sys/sparc64/include

[Joerg Sonnenberger]

On Mon, Feb 12, 2018 at 02:48:14PM +, Warner Losh wrote:
> Author: imp
> Date: Mon Feb 12 14:48:14 2018
> New Revision: 329164
> URL: https://svnweb.freebsd.org/changeset/base/329164
> 
> Log:
>   We don't support gcc < 4.2.1, so varargs.h now is just #error
>   always. Unifdef for versions prior to 4.2.1 and remove now-unused
>   header files.

In my experience it is better to really drop it. Keeping the header with
an #error is just creating *more* pain than having no header at all.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331510 - in head: share/man/man4 sys/conf sys/dev/vmware/vmci sys/modules/vmware sys/modules/vmware/vmci

[Joerg Sonnenberger]

On Sun, Mar 25, 2018 at 09:03:20AM -0700, Rodney W. Grimes wrote:
> Kirk would have to back me up on this, but my understanding of the
> decisions that the UCB Regents legal staff came to was that each
> file should have a complete copyright and license clause and any
> thing less causes problems because of "seprability", and "alterability"
> because of seperate files.

Are you talking about a decision made before the USA joined the rest of
the civilised world as signee of the Berne Convention? The copyright
notice was certainly required at the time. A full license clause is
nicer for "stealing" things, but certainly not required.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331510 - in head: share/man/man4 sys/conf sys/dev/vmware/vmci sys/modules/vmware sys/modules/vmware/vmci

[Joerg Sonnenberger]

On Sun, Mar 25, 2018 at 09:46:16AM -0700, Rodney W. Grimes wrote:
> > On Sun, Mar 25, 2018 at 09:03:20AM -0700, Rodney W. Grimes wrote:
> > > Kirk would have to back me up on this, but my understanding of the
> > > decisions that the UCB Regents legal staff came to was that each
> > > file should have a complete copyright and license clause and any
> > > thing less causes problems because of "seprability", and "alterability"
> > > because of seperate files.
> > 
> > Are you talking about a decision made before the USA joined the rest of
> > the civilised world as signee of the Berne Convention?
> > The copyright
> > notice was certainly required at the time. A full license clause is
> > nicer for "stealing" things, but certainly not required.
> 
> With or without application of Berne Convention, without a license
> you (us, FreeBSD project, foundation) have no rights to publish
> (redistribute) the work, unless that copyright is a of the form
> that it would "placed in the public domain" the work.

That doesn't mean that every file has to include such a license tag.
Neither does it have to carry a copyright note nowadays, but that used
to be different.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r325816 - head/libexec/rtld-elf/mips

[Joerg Sonnenberger]

On Tue, Nov 14, 2017 at 05:16:03PM +, John Baldwin wrote:
> Author: jhb
> Date: Tue Nov 14 17:16:03 2017
> New Revision: 325816
> URL: https://svnweb.freebsd.org/changeset/base/325816
> 
> Log:
>   Appease old GCC by disabling .cfi_sections for GCC 4.x.

This commit message makes no sense to me. .cfi_sections is not a feature
of GCC, it is at most a feature of binutils.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r337921 - head/lib/libbe

[Joerg Sonnenberger]

On Thu, Aug 16, 2018 at 06:37:48PM +, Kyle Evans wrote:
> Author: kevans
> Date: Thu Aug 16 18:37:47 2018
> New Revision: 337921
> URL: https://svnweb.freebsd.org/changeset/base/337921
> 
> Log:
>   libbe(3): Prefer safer versions of strcat/strcpy

Why not use snprintf in both cases?

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r328159 - head/sys/modules

[Joerg Sonnenberger]

On Fri, Jan 19, 2018 at 08:40:56PM +0200, Andriy Gapon wrote:
> I seem to recall that the actual shift happens to be N % 32 for 32-bit 
> registers
> (at least on some processors).

It depends. That's the behavior some architectures implement. Others
will just give you 0 as result for N>32. This is a case of UB where the
implementation-defined behavior of different CPUs is actually
inconsistent.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284898 - in head: . share/mk

[Joerg Sonnenberger]

On Sun, Jun 28, 2015 at 12:13:11AM -0700, Adrian Chadd wrote:
> One must use -I=/usr/include - then the sysroot stuff gets appended correctly.

You really want to use -isysroot =/usr/include. One issue the NetBSD
patches solves is that GCC seems to consider sysroot vs non-sysroot as
property for whether the default paths should be searched, which is
insane. The patches allow building a single GCC binary that can use
--sysroot ${DESTDIR} or not and will do the right thing..

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r284898 - in head: . share/mk

[Joerg Sonnenberger]

On Sun, Jun 28, 2015 at 11:48:48AM +0200, Dimitry Andric wrote:
> What is actually the perceived problem with having paths in those linker
> scripts?  If you use --sysroot, the libraries are searched relative to
> that sysroot, right?

Depends. A plain absolute path stays a plain absolute path. One prefixed
with = is adjusted accordingly. E.g. you want to get

SEARCH_DIR("=/usr/lib");

and not "/usr/lib".

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r285552 - head/usr.bin/xargs

[Joerg Sonnenberger]

On Wed, Jul 15, 2015 at 10:29:22AM +0100, David Chisnall wrote:
> On 15 Jul 2015, at 01:02, Xin Li  wrote:
> > 
> > My only concern with strtonum() is that it's English only.
> 
> Given that strtonum() wraps strtoll, it ought to support whatever the current
> locale is (assuming that the program calls setlocale() before calling
> strtonum(), otherwise it will use the C locale[1]).  Or do you mean
> that the error messages are not localised?

The error messages are part of the API and not localised.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r310138 - head/lib/libc/stdio

[Joerg Sonnenberger]

On Fri, Dec 16, 2016 at 02:45:19PM -0800, John Baldwin wrote:
> In general I agree with something like this instead, but it is quite a bit 
> more
> tedious to use as you have to run it once to determine the length, allocate a
> buffer, and then run it again.

Why do you need to determine the length? It's not like people write
novells in the kernel to describe bit fields. A reasonable sized stack
buffer covers pretty much all the interesting cases.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r310171 - head/sys/sys

[Joerg Sonnenberger]

On Mon, Dec 19, 2016 at 12:37:27PM -0800, Ravi Pokala wrote:
> With all apologies to Churchill, SCN/PRI are the worst way to address
> this in a machine-independent way, except for all the other ways that
> have been tried from time to time. :-P

They can't be the worst as they at least don't involve additional
variables or using larger than necessary types.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r311109 - head/usr.bin/patch

[Joerg Sonnenberger]

On Tue, Jan 03, 2017 at 08:52:03AM -0700, Ian Lepore wrote:
> I'm also trying to picture the real-world need to diff and patch lines
> of ascii text longer than 64K, but for every problem out there, there
> is someone with a perverse need to solve that problem outside of the
> normal lines we all live between.

Patches for the generated Makefiles of wxGTK in pkgsrc have been the
reasons why we moved to our own version of patch on all non-NetBSD
platforms.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r311109 - head/usr.bin/patch

[Joerg Sonnenberger]

On Tue, Jan 03, 2017 at 11:27:28AM -0500, Pedro Giffuni wrote:
> I think this is a valid reason to leave things as they are. FWIW, both
> NetBSD and OpenBSD seem be fine with just SHORT_MAX.

NetBSD's patch doesn't use (U)SHRT_MAX.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r321969 - in head/sys/boot: arm/at91/libat91 arm/ixp425/boot2 i386/boot2

[Joerg Sonnenberger]

On Thu, Aug 03, 2017 at 05:53:43PM +1000, Bruce Evans wrote:
> Freestanding versions (static and otherwise) cause problems with builtins.
> -ffreestanding turns off all builtins.  The static memcpy used to be
> ifdefed so as to use __builtin_memcpy instead of the static one if the
> compiler is gcc.  That apparently broke with gcc-4.2, since the builtin
> will call libc memcpy() in some cases, although memcpy() is unavailable
> in the freestanding case.

GCC always had a requirement that freestanding environment must provide
certain functions (memcpy, memmove, memset, memcmp). At least memcpy and
memset are regulary used for certain code constructs. While most calls
will be inlined, it is not required.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r313494 - head/libexec/rtld-elf

[Joerg Sonnenberger]

On Thu, Feb 09, 2017 at 11:33:06PM +, Konstantin Belousov wrote:
>   Protected symbol reference in GOT of the defining object must be
>   resolved to itself, same as -Bsymbolic globally.

This doesn't make sense to me. Why do they remain in the DSO, they
should have been resolved the linker already?

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r320579 - head/usr.bin/patch

[Joerg Sonnenberger]

On Mon, Jul 03, 2017 at 10:42:15AM -0500, Pedro Giffuni wrote:
> IMHO, the (new) BSD patch behavior is somewhat more natural in the sense
> that no one asked git to add a prefix to the path so it makes sense to
> ignore it. Recent GNU patch does support many git-specific features that we
> don't.

I quite disagree. git patches (just like hg in this regard) are stupid,
they can just drop the additional directories and it wouldn't change
anything.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r286100 - in head/sys: net netipsec

[Joerg Sonnenberger]

On Thu, Jul 30, 2015 at 10:32:01PM -0700, John-Mark Gurney wrote:
> Ryan Stone wrote this message on Fri, Jul 31, 2015 at 01:03 -0400:
> > You can't use CTASSERT in a header. You'll get a compile error if two
> 
> Testing a fix now...
> 
> > different headers included in the same translation unit have a CTASSERT on
> > the same line number.
> 
> Not w/ clang anymore...  _Static_assert is now a built-in..  And we have
> a few CTASSERTs in header files already...

Clang also supports __COUNTER__.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r287217 - head/usr.sbin/syslogd

[Joerg Sonnenberger]

On Fri, Aug 28, 2015 at 10:17:56PM +1000, Bruce Evans wrote:
> >-static void die(int);
> >+static void die(int) __dead2;
> 
> Since the function is static, it is very easy for the compiler to see
> that it doesn't return.

But the compiler can't tell if it is the *intention* that the function
never returns. The warning behavior exists because that can easily
change with macros etc. 

> Even gcc-4.2.1 does this by default, since
> -O implies -funit-at-a-time for gcc-4.2.1.  For clang, there is no way
> to prevent this (except possibly -O0) since, since -fno-unit-at-a-time
> is broken in clang.

It is not broken. It is loadly ignored as unsupported. The very
existance of the option in GCC has always been a concession to broken
and badly written code, including of course GCC's own CRT.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r287217 - head/usr.sbin/syslogd

[Joerg Sonnenberger]

On Sun, Aug 30, 2015 at 03:36:27PM +1000, Bruce Evans wrote:
> On Fri, 28 Aug 2015, Joerg Sonnenberger wrote:
> 
> >On Fri, Aug 28, 2015 at 10:17:56PM +1000, Bruce Evans wrote:
> >>>-static void   die(int);
> >>>+static void   die(int) __dead2;
> >>
> >>Since the function is static, it is very easy for the compiler to see
> >>that it doesn't return.
> >
> >But the compiler can't tell if it is the *intention* that the function
> >never returns. The warning behavior exists because that can easily
> >change with macros etc.
> 
> The compiler should trust the programmer to write correct functions.

That's a good one. Programmers are notorious for one thing, which is not
writing correct code.

> >>Even gcc-4.2.1 does this by default, since
> >>-O implies -funit-at-a-time for gcc-4.2.1.  For clang, there is no way
> >>to prevent this (except possibly -O0) since, since -fno-unit-at-a-time
> >>is broken in clang.
> >
> >It is not broken. It is loadly ignored as unsupported. The very
> >existance of the option in GCC has always been a concession to broken
> >and badly written code, including of course GCC's own CRT.
> 
> Unsupported == incompatible == broken.
> 
> My use of this option can probably be reduced to -fno-toplevel-reorder,
> but that is even more broken in clang (it and -ftoplevel-reorder are
> "unknown arguments", while -fno-unit-at-a-time is an "unsupported
> optimization", and -funit-at-a-time works).

Neither -fno-unit-at-a-time nor -funit-at-a-time is an optimisation.
Nothing in the standard suggests a specific ordering and well written
programs don't make such assumptions. All use cases I have seen so far
are miswritten and fragile and would be better served by using a
different approach. This is no different from broken code requiring
function calls in a sequence point to be executed in a specific order.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r287217 - head/usr.sbin/syslogd

[Joerg Sonnenberger]

On Sun, Aug 30, 2015 at 11:53:00AM +0200, Ed Schouten wrote:
> 2015-08-28 16:38 GMT+02:00 Joerg Sonnenberger :
> > But the compiler can't tell if it is the *intention* that the function
> > never returns. The warning behavior exists because that can easily
> > change with macros etc.
> 
> I think it's important to keep in mind what this keyword was designed for.
> 
> The idea behind this attribute (and the C11 _Noreturn keyword) is to
> allow for propagation of optimisation state across compilation units.
> You use it to annotate functions in header files, so that the compiler
> does not need to handle function return at the call site. This
> knowledge can be automatically be inferred if the function is static.

I disagree that optimisation is the primary design goal. Static analysis
and optimisation just have a huge overlap in this area.

> I agree with Bruce that this change makes little sense. I would even
> go as far as to say that GCC/Clang should just throw warnings if
> _Noreturn is used on a function that is static or used on a definition
> instead of a declaration.

That makes no sense. The presence of the attribute allows the compiler
to *ensure* that the function really does not return. Having done this
in NetBSD, I can assure you that there are often enough cases where the
compiler can not figure it out automatically, especially if the
attribution is missing on some function pulled in externally. GCC at
least up to 4.8 has not warned about such cases and I have multiple bugs
where function *could* fall through.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r283320 - head/sys/kern

[Joerg Sonnenberger]

On Sat, May 23, 2015 at 07:09:04PM +, Konstantin Belousov wrote:
> Author: kib
> Date: Sat May 23 19:09:04 2015
> New Revision: 283320
> URL: https://svnweb.freebsd.org/changeset/base/283320
> 
> Log:
>   If thread requested to not stop on non-boundary, then not only
>   stopping signals should obey, but also all forms of single-threading.

This sentence is messes up my English parser...

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r268137 - head/sys/sys

[Joerg Sonnenberger]

On Fri, Jun 19, 2015 at 03:22:49PM +0100, David Chisnall wrote:
> > NetBSD:
> > > sys/cdefs_elf.h
> > #define __weak  __attribute__((__weak__))
> > 
> > FreeBSD:
> > > sys/cdefs.h
> > #define __weak  __attribute__((__weak__))
> 
> NetBSD is the only system that I’m aware of that has actually shipped
> this, and it broke a lot of things.

"A lot of things"? Let's keep a sense of proportion: it broke exactly
one thing and that's gnustep. This isn't the first time that Apple's
language extension broke system headers either, see __block and glibc.
Objective C has no more ownership of "__weak" than the OS has and the
common style of header keywords is actually a much stronger reason
*against* the pseudo-keyword use in Objective C.

Joerg
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r291666 - head/libexec/rtld-elf

[Joerg Sonnenberger]

On Thu, Dec 03, 2015 at 10:50:28AM +0200, Konstantin Belousov wrote:
> > Modified: head/libexec/rtld-elf/Makefile
> > ==
> > --- head/libexec/rtld-elf/Makefile  Thu Dec  3 00:02:01 2015
> > (r291665)
> > +++ head/libexec/rtld-elf/Makefile  Thu Dec  3 00:06:59 2015
> > (r291666)
> > @@ -13,7 +13,7 @@ SRCS= rtld_start.S \
> > malloc.c xmalloc.c debug.c libmap.c
> >  MAN=   rtld.1
> >  CSTD?= gnu99
> > -CFLAGS+=   -Wall -DFREEBSD_ELF -DIN_RTLD
> > +CFLAGS+=   -Wall -DFREEBSD_ELF -DIN_RTLD -fno-builtin
> >  CFLAGS+=   -I${SRCTOP}/lib/csu/common
> >  .if exists(${.CURDIR}/${MACHINE_ARCH})
> >  RTLD_ARCH= ${MACHINE_ARCH}
> > @@ -22,7 +22,6 @@ RTLD_ARCH=${MACHINE_CPUARCH}
> >  .endif
> >  CFLAGS+=   -I${.CURDIR}/${RTLD_ARCH} -I${.CURDIR}
> >  .if ${MACHINE_ARCH} == "powerpc64"
> > -CFLAGS+=   -mcall-aixdesc
> I wanted to set -ffreestanding for rtld compilation, but considered it only
> a minor issue.  Could you test this instead of -fno-builtin, please ?

I don't tthink either should be used -- -fno-builtin is certainly a very
blunt hammer. Are you sure that doesn't disable all kinds of useful
things like optimisations of the string functions etc?

A more selective approach would to add something like:

void *real_malloc(size_t) __asm__("malloc");

and call that. I would call it a bug that -fno-builtin-calloc does not
work.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r296124 - in head: share/man/man7 share/mk sys/conf

[Joerg Sonnenberger]

On Fri, Feb 26, 2016 at 02:19:33PM -0800, Bryan Drewery wrote:
> On 2/26/16 2:14 PM, Bryan Drewery wrote:
> > Author: bdrewery
> > Date: Fri Feb 26 22:14:00 2016
> > New Revision: 296124
> > URL: https://svnweb.freebsd.org/changeset/base/296124
> > 
> > Log:
> >   Import bsd.clang-analyze.mk based on NetBSD's version.
> >   
> >   This allows 'make analyze' or 'make OBJ.clang-analyzer' to run the
> >   Clang static analyzer and present results on stdout.
> >   
> >   Obtained from:NetBSD (CVS Rev. 1.3)
> >   Sponsored by: EMC / Isilon Storage Division
> >   Differential Revision:https://reviews.freebsd.org/D5449
> > 
> 
> I just wanted to call special attention to this one.  You may find it
> useful to run in something you maintain.  scan-build can achieve the
> same thing but this one is at least built-in and dependency-free.

The primary limitation is that it only gives the text report and that
generally doesn't include the reasoning, i.e. which pre-conditions the
analyzer has been taking into account for deriving with a specific
warning. That sadly makes it quite a bit less useful.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r290499 - head/usr.bin/localedef

[Joerg Sonnenberger]

On Sat, Nov 07, 2015 at 04:22:29PM +, Baptiste Daroussin wrote:
> Author: bapt
> Date: Sat Nov  7 16:22:29 2015
> New Revision: 290499
> URL: https://svnweb.freebsd.org/changeset/base/290499
> 
> Log:
>   Workaround an issue on i386 to unbreak the build until the real issue is 
> tracked
>   down
> 
> Modified:
>   head/usr.bin/localedef/collate.c
> 
> Modified: head/usr.bin/localedef/collate.c
> ==
> --- head/usr.bin/localedef/collate.c  Sat Nov  7 15:03:45 2015
> (r290498)
> +++ head/usr.bin/localedef/collate.c  Sat Nov  7 16:22:29 2015
> (r290499)
> @@ -1255,7 +1255,8 @@ dump_collate(void)
>* Large (> UCHAR_MAX) character priorities
>*/
>   RB_NUMNODES(collchar_t, collchars, &collchars, n);
> - large = calloc(sizeof (collate_large_t) * n, 1);
> + large = malloc(sizeof (collate_large_t) * n);
> + memset(large, 0, sizeof (collate_large_t) * n);
>   if (large == NULL) {
>   fprintf(stderr, "out of memory");
>   return;

Why was this not calloc(sizeof(), n) in first place?!

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r358133 - head/sys/vm

[Joerg Sonnenberger]

On Wed, Feb 19, 2020 at 10:34:23PM +, Jeff Roberson wrote:
> Author: jeff
> Date: Wed Feb 19 22:34:22 2020
> New Revision: 358133
> URL: https://svnweb.freebsd.org/changeset/base/358133
> 
> Log:
>   Silence a gcc warning about no return from a function that handles every
>   possible enum in a switch statement.  I verified that this emits nothing
>   as expected on clang.  radix relies on constant propagation to eliminate
>   any branching from these access routines.

__builtin_unreachable() ?

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r358248 - head/sys/vm

[Joerg Sonnenberger]

On Sat, Feb 22, 2020 at 08:24:45PM +0100, Dimitry Andric wrote:
> It might be better to define our own UNREACHABLE macro, similar to what
> llvm itself does, roughly something like:
> 
> __noreturn void internal_unreachable(const char *, const char *, int);
> #define UNREACHABLE(msg) internal_unreachable(msg, __FILE__, __LINE__)
> 
> And have the implementation of internal_unreachable() log the file,
> line and message, then abort or panic in some appropriate way.

One way to deal with it is to use __builtin_trap() for debug builds and
__builtin_unreachable() otherwise. They both signify code that shouldn't
be reached, but they differ in how the compiler will use that knowledge.

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r300375 - head/sys/arm/include

[Joerg Sonnenberger]

On Sat, May 21, 2016 at 04:52:38PM +, Ian Lepore wrote:
> Author: ian
> Date: Sat May 21 16:52:38 2016
> New Revision: 300375
> URL: https://svnweb.freebsd.org/changeset/base/300375
> 
> Log:
>   Adjust _ALIGNBYTES to the proper value for arm and armv6 arches.  Modern
>   compilers can emit arm instructions that require 8-byte alignment.  The
>   alignment-sensitive instructions were added in armv5, which has to be
>   supported by our combined v4/v5 kernels, so the value is set uncoditionally
>   for all arm architecture versions.

Doesn't this change effectively break the ABI of CMSG?

Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"