On 25 May 2018, at 05:27, Maxim Sobolev wrote:
>
> The idea looks very inmature and short-sighted to me. i386 is here to stay
> not as a server/desktop platform but as an embedded/low power/low cost
> platform for at least 5-10 years to come. There are plenty of applications in
> the world tha
On 26 May 2018, at 00:41, Maxim Sobolev wrote:
>
> If you've seen any of the atom bay trail systems in action you may understand
> what I mean. You get full blown x64 system with four cores and it takes only
> 2W of power.
Which is pretty much my point - if you want a low-power x86 system for
On 16 Dec 2017, at 18:05, John Baldwin wrote:
>
> When I build a FreeBSD/mips64 kernel with clang,
> _any_ simple NFS op triggers a kernel stack overflow. Kernels compiled
> with GCC do not.
That is not my experience. I haven’t tried a MIPS64 kernel built with clang,
but with in-tree gcc I ge
On 19 Jan 2018, at 05:07, Conrad Meyer wrote:
>
> The spec says the behavior is undefined; not that the compiler has to
> produce a warning or error message. The compiler *does* get to
> arbitrarily decide what it wants to do when it encounters UB. It is
> wholly free to implement this particul
On 22 Nov 2011, at 20:27, David Schultz wrote:
> Benchmark or not, I think you'll have a very hard time finding a
> single real program that routinely calls strcasecmp() with
> identical pointers!
I've seen this pattern very often. Often the linker is able to combine
constant strings defined in
Author: theraven
Date: Fri Nov 25 20:59:04 2011
New Revision: 227983
URL: http://svn.freebsd.org/changeset/base/227983
Log:
Import libc++ / libcxxrt into base. Not build by default yet (use
MK_LIBCPLUSPLUS=yes to enable). This is a work-in-progress. It works for
me, but is not guaranteed
Author: theraven
Date: Sat Nov 26 15:57:09 2011
New Revision: 227999
URL: http://svn.freebsd.org/changeset/base/227999
Log:
Return not-implemented from pthread_once and pthread_key_create, rather
than silently failing and returning success.
Without this, code calls pthread_once(), receive
Author: theraven
Date: Sat Nov 26 16:49:25 2011
New Revision: 228002
URL: http://svn.freebsd.org/changeset/base/228002
Log:
style(9) fix.
Approved by: dim (mentor)
Modified:
head/lib/libc/gen/_pthread_stubs.c
Modified: head/lib/libc/gen/_pthread_stubs.c
Author: theraven
Date: Sat Nov 26 18:46:33 2011
New Revision: 228004
URL: http://svn.freebsd.org/changeset/base/228004
Log:
Update libcxxrt to remove the pthread dependency.
Also add the license from upstream to contrib.
Approved by: dim (mentor)
Added:
head/contrib/libcxxrt/LICENS
On 27 Nov 2011, at 09:19, Bjoern A. Zeeb wrote:
> On Sat, 26 Nov 2011, David Schultz wrote:
>
>> On Sat, Nov 26, 2011, Bjoern A. Zeeb wrote:
>>> On Sat, 26 Nov 2011, David Chisnall wrote:
>>>
>>>> Author: theraven
>>>> Date: Sat Nov 26
On 29 Nov 2011, at 04:50, Max Khon wrote:
> All this makes it possible to build and link gdb with -ledit.
When I had a quick look a couple of days ago, kadmin and [k]gdb were the only
things that linked against readline in base. With them now linking against
libedit, can we remove readline fr
/dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/lib/libc/stdlib/at_quick_exit.3Wed Dec 7 15:25:48 2011
(r228322)
@@ -0,0 +1,58 @@
+.\" Copyright (c) 2011 David Chisnall
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in sourc
Author: theraven
Date: Wed Dec 7 16:12:54 2011
New Revision: 228323
URL: http://svn.freebsd.org/changeset/base/228323
Log:
style(9) cleanups.
Approved by: brooks (mentor)
Modified:
head/lib/libc/stdlib/quick_exit.c
Modified: head/lib/libc/stdlib/quick_exit.c
==
Author: theraven
Date: Wed Dec 7 21:02:35 2011
New Revision: 228329
URL: http://svn.freebsd.org/changeset/base/228329
Log:
Some fixes to the man pages for [at_]quick_exit(3)
Reviewed by:pluknet
Approved by:dim (mentor)
Modified:
head/lib/libc/stdlib/at_quick_exit.3
head/lib/
On 7 Dec 2011, at 19:11, David Schultz wrote:
> Why not use the standard spelling, '_Noreturn'? In pre-C1X modes,
> _Noreturn is a reserved identifier since it starts with an underscore
> and capital letter, so it's not considered namespace pollution.
Because that would be too obvious...
David
Author: theraven
Date: Wed Dec 7 21:17:50 2011
New Revision: 228330
URL: http://svn.freebsd.org/changeset/base/228330
Log:
As per das@'s suggestion, s/__noreturn/_Noreturn/, since the latter is an
identifier reserved for the implementation in C99 and earlier so there is
no sensible reason f
On 11 Dec 2011, at 21:12, Andreas Tobler wrote:
> As far as I understand, GCC does not support this attribute [[noreturn]] yet.
> But it defines both, __cplusplus and __cplusplus=201103L. On gcc-4.7
> __cplusplus=201103L is the default when we build libstdc++.
Advertising C++11 compatibility an
Author: theraven
Date: Thu Dec 15 11:16:41 2011
New Revision: 228528
URL: http://svn.freebsd.org/changeset/base/228528
Log:
Small style(9) improvements.
Approved by: dim (mentor)
Modified:
head/lib/libc/stdlib/quick_exit.c
Modified: head/lib/libc/stdlib/quick_exit.c
===
Author: theraven
Date: Thu Dec 15 11:21:56 2011
New Revision: 228529
URL: http://svn.freebsd.org/changeset/base/228529
Log:
Add a pointless and superfluous GNUism that people at a certain large data
aggregation and advertising company seem to believe is standard.
Approved by: dim (mentor
On 19 Dec 2011, at 19:52, Warner Losh wrote:
> -1. The needs of the many? Please. Let's break a useful feature because
> some people don't understand it and are impatient? That's lame.
How useful is gprof-based profiling these days? Now that we have the DTrace
pid provider, don't we have a
On 20 Dec 2011, at 06:20, Bruce Evans wrote:
> Don't be silly. Building profiled libraries takes as much as 1 minute.
> Many would not want to wait that long (if they noticed how long it takes).
> This is not 1994 when building of profiling libraries was left in because
> it only took an extra ho
Author: theraven
Date: Sat Dec 24 13:28:49 2011
New Revision: 228859
URL: http://svn.freebsd.org/changeset/base/228859
Log:
Some GCC-compatibility definitions. Define clang's feature test pseudomacros
to always evaluate to 0 if we are using a compiler that doesn't implement
them.
This lets
mic.h
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/include/stdatomic.hSat Dec 24 15:17:01 2011(r228862)
@@ -0,0 +1,296 @@
+/*-
+ * Copyright (c) 2011 Ed Schouten
+ * David Chisnall
+ * All rights res
Author: theraven
Date: Sat Dec 24 15:31:06 2011
New Revision: 228863
URL: http://svn.freebsd.org/changeset/base/228863
Log:
...and actually install it.
Approved by: dim (mentor)
Modified:
head/include/Makefile
Modified: head/include/Makefile
Author: theraven
Date: Sun Dec 25 16:03:54 2011
New Revision: 228875
URL: http://svn.freebsd.org/changeset/base/228875
Log:
Restore __is_threaded in C++ mode. Some Google stuff needs it apparently.
Reported by: swills
Approved by: dim (mentor)
Modified:
head/include/stdio.h
Modifie
Author: theraven
Date: Tue Dec 27 21:36:31 2011
New Revision: 228918
URL: http://svn.freebsd.org/changeset/base/228918
Log:
Define NULL to nullptr in C++11 mode (not strictly required, but it makes
migrating code to C++11 easier).
Approved by: dim (mentor)
Modified:
head/sys/sys/_null
On 30 Dec 2011, at 16:52, Sean C. Farley wrote:
>> My quick googling didn't show anything at all about the C++ standard and
>> stdbool.h or __bool_true_false_are_defined. It was probably originally set
>> because bool, true, and false are all C++ keywords so certain code that
>> wanted to ifde
Author: theraven
Date: Mon Jan 16 18:19:53 2012
New Revision: 230225
URL: http://svn.freebsd.org/changeset/base/230225
Log:
Use the signal fence builtin in stdatomic.h when using the clang atomic
builtins, rather than the __asm hack. Somehow I missed the existence of this
builtin originally
Author: theraven
Date: Tue Jan 17 15:20:41 2012
New Revision: 230267
URL: http://svn.freebsd.org/changeset/base/230267
Log:
Fix clang atomic to use for atomic_is_lock_free().
Reviewed by: ed
Approved by: dim (mentor)
Modified:
head/include/stdatomic.h
Modified: head/include/stdatomi
On 19 Jan 2012, at 18:09, Ed Schouten wrote:
> In the very nearby future (after I switch SPARC64 and MIPS to
> libcompiler_rt), it should be possible to safely use C11's
> on all supported architectures. The C11 interface allows any operation
> to be combined with any type of barrier.
>
> Maybe
On 20 Jan 2012, at 00:46, David Xu wrote:
> It depends on hardware, if it is a large machine with lots of cpu,
> a small conflict on dual-core machine can become a large conflict
> on large machine because it is possible more cpus are now
> running same code which becomes a bottleneck. On a large
suz [label="SUZUKI Shinsuke\n...@freebsd.org\n2002/03/26"]
syrinx [label="Shteryana Shopova\nsyr...@freebsd.org\n2006/10/07"]
takawata [label="Takanori Watanabe\ntakaw...@freebsd.org\n2000/07/06"]
+theraven [label="David Chisnall\nthera...@freebsd.org\n2011/
Author: theraven
Date: Sat Nov 12 14:39:20 2011
New Revision: 227467
URL: http://svn.freebsd.org/changeset/base/227467
Log:
Fix the number of decimal digits used for Swiss Francs (0 -> 2). Found by
the libc++ test suite. If there is some locale test suite somewhere, it might
be worth running
Author: theraven
Date: Sat Nov 12 19:55:48 2011
New Revision: 227472
URL: http://svn.freebsd.org/changeset/base/227472
Log:
Expose the unimplemented libm functions in the math.h header. This allows
C++'s to work without the compiler complaining that the C++ versions
are calling implicitly-de
Author: theraven
Date: Sat Nov 12 20:16:06 2011
New Revision: 227474
URL: http://svn.freebsd.org/changeset/base/227474
Log:
Fix SIGATOMIC_M{IN,AX} on x86-64. These are meant to be the minimum values
that are allowed in a sig_atomic_t, but it looks like they were just copied
from the x86 versi
Author: theraven
Date: Sat Nov 12 20:25:11 2011
New Revision: 227475
URL: http://svn.freebsd.org/changeset/base/227475
Log:
Expose all of the C99 limits.h stuff when we're in C++11 mode (or some
approximation thereof). C++11 finally adds long long to C++. Now even C++
programmers are allowed
Author: theraven
Date: Sat Nov 12 20:45:10 2011
New Revision: 227476
URL: http://svn.freebsd.org/changeset/base/227476
Log:
Don't expose the wctype.h macros in C++ mode. They cause problems when
people try to invoke the namespaced versions of the functions of the
same names.
Approved b
Author: theraven
Date: Sun Nov 13 16:18:48 2011
New Revision: 227487
URL: http://svn.freebsd.org/changeset/base/227487
Log:
The spec says that FILE must be defined in wchar.h, but it wasn't. It
is now. Also hide some macros in C++ mode that will break C++
namespaced calls.
Approved by
Author: theraven
Date: Sun Nov 13 17:07:26 2011
New Revision: 227490
URL: http://svn.freebsd.org/changeset/base/227490
Log:
Hide some more macros that will break C++ when compiling in C++ mode.
Approved by: dim (mentor)
Modified:
head/include/ctype.h
Modified: head/include/ctype.h
es seen they
> have 2 digits, though.
>
> Thanks,
> Erik
>
> Den 12/11/2011 kl. 15.39 skrev David Chisnall:
>
>> Author: theraven
>> Date: Sat Nov 12 14:39:20 2011
>> New Revision: 227467
>> URL: http://svn.freebsd.org/changeset/base/227467
>
On 14 Nov 2011, at 18:02, David Schultz wrote:
> On Mon, Nov 14, 2011, Dimitry Andric wrote:
>> On 2011-11-14 09:21, Stefan Farfeleder wrote:
>>> On Sun, Nov 13, 2011 at 04:18:48PM +0000, David Chisnall wrote:
>>>> Author: theraven
>>>> Date: Sun Nov
On 17 Nov 2011, at 14:31, Alexey Dokuchaev wrote:
Kinda gross but "FBSD-9.0-RELEASE-amd64-amd64-bootonly.iso"?
>>>
>>> Can't we use one if they are equal?
>>
>> I'd prefer consistency. [...]
>
> But it looks so plain stupid!
I've had someone ask me what amd64-amd64 meant when I pointed t
,0 +1,162 @@
+/*-
+ * Copyright (c) 2011 The FreeBSD Foundation
+ * All rights reserved.
+ *
+ * This software was developed by David Chisnall under sponsorship from
+ * the FreeBSD Foundation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitt
Author: theraven
Date: Mon Nov 21 23:32:14 2011
New Revision: 227807
URL: http://svn.freebsd.org/changeset/base/227807
Log:
(Hopefully) Fix the build with clang by removing a typedef that's no longer
needed.
Approved by: brooks (mentor)
Modified:
head/lib/libc/string/strcasecmp.c
Modi
Author: theraven
Date: Tue Nov 22 14:11:42 2011
New Revision: 227818
URL: http://svn.freebsd.org/changeset/base/227818
Log:
Fix a crash when trying to duplicate a locale that contains some implicit C
locale components.
Reported by: Michael Butler
Approved by: dim (mentor)
Modified:
On 22 Nov 2011, at 11:21, Bruce Evans wrote:
> If this optimization were any good, then the compiler would already do
> it. In fact, gcc-4.2.1 already does it -- the reverse of it -- it rewrites:
>
> "if ((i == 0) | (j == 0)) return; test();"
>
> into:
>
> "if (i == 0 || j == 0) re
On 1 Feb 2017, at 08:13, Konstantin Belousov wrote:
>
> On Wed, Feb 01, 2017 at 10:38:42AM -0500, Alexander Kabaev wrote:
>> On Wed, 1 Feb 2017 16:17:21 +0200
>> Konstantin Belousov wrote:
>>
>>> Please do not retry on sc failure, return the error to upper layer.
>>> See also r313007 and precee
On 25 Aug 2017, at 07:32, Mark Millard wrote:
>
> As I remember _Static_assert is from C11, not
> the older C99.
In pre-C11 dialects of C, _Static_assert is an identifier reserved for the
implementation. sys/cdefs.h defines it to generate a zero-length array if the
condition is true or a nega
Author: theraven
Date: Thu Sep 7 17:51:35 2017
New Revision: 323277
URL: https://svnweb.freebsd.org/changeset/base/323277
Log:
Document some invariants for the XLC_ enum.
These can't be reordered without breaking other code. Document that and add
some static asserts to ensure that anyon
On 8 Sep 2017, at 21:09, Mateusz Guzik wrote:
>
> Author: mjg
> Date: Fri Sep 8 20:09:14 2017
> New Revision: 323329
> URL: https://svnweb.freebsd.org/changeset/base/323329
>
> Log:
> Allow __builtin_memset instead of bzero for small buffers of known size
This change seems redundant, because
On 10 Jul 2014, at 18:13, Adrian Chadd wrote:
> ... I think this particular commit highlights our almost complete lack
> of useful data types in our C libraries.
>
> I think it's about time we grew a similar list of basic DSAs.
>
> I had to reimplement hash tables, trees and callwheels at work
On 11 Jul 2014, at 15:03, John Baldwin wrote:
>
> http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice
>
> is a decent start on the multitude of reasons to avoid using it.
>
> I also avoid 'import * from foo' in Python for similar reasons.
>
> OTOH, mo
On 11 Jul 2014, at 22:26, John Baldwin wrote:
>> For things that live in the base system, there's not much danger of boost
>> conflicts. 'using namespace std' is mostly a problem when it's in headers
>> (especially
> library headers), because it can break large amounts of code. In a tiny
>
Author: theraven
Date: Sat Jul 12 07:47:50 2014
New Revision: 268566
URL: http://svnweb.freebsd.org/changeset/base/268566
Log:
Turn off exceptions and rtti when building the c++ version of users.
Neither is used in the program and this saves us 10KB (around 40%) in binary
size.
Modified:
On 10 Jul 2014, at 16:29, Ed Schouten wrote:
> With the patch above, the binary shrinks to 15640 bytes, so my
> concerns are somewhat addressed. :-)
I wasn't seeing that saving, but I've now committed a tweak to the Makefile
that turns off exceptions and RTTI. This shrinks the binary to 15569
On 24 Apr 2013, at 03:40, Juli Mallett wrote:
> I don't see why we shouldn't just replace regnum.h with the NetBSD
> version, and merge that to all active branches. Since you're trying
> to update these headers, Warner, it would be great if you could do
> that.
That would probably be sensible.
On 5 May 2013, at 19:31, Andrey Chernov wrote:
> It is better to fix this function return type to match POSIX standard
> rather than to document its non-standard behavior. We try to follow
> POSIX when possible and this is the case.
We follow Darwin in this case, which returns 0 on success or -1
On 10 May 2013, at 10:01, Eitan Adler wrote:
> I thought style(9) disliked the leading (void) but I could be wrong.
The cast to (void) tells the compiler that you are ignoring the return result.
Without it, you will introduce new warnings and break the build on certain
compiler versions with
On 10 May 2013, at 10:12, Eitan Adler wrote:
> I don't remember any recent tool which uses that cast
> to remove errors.
clang -Wunused-result
gcc -Wunused-result
David
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/list
On 26 May 2013, at 03:45, Bruce Evans wrote:
> Hmm, it would be useful to have a compiler flag for initializing all
> local variables to trap representations on entry to functions.
The clang memory sanitizer does this.
David
___
svn-src-head@freebsd
Author: theraven
Date: Sun Jun 16 21:15:35 2013
New Revision: 251820
URL: http://svnweb.freebsd.org/changeset/base/251820
Log:
Fix some missing symbols in the libsupc++ Version.map
MFC after:1 week
Modified:
head/gnu/lib/libsupc++/Version.map
Modified: head/gnu/lib/libsupc++/Version
Author: theraven
Date: Mon Jun 17 15:30:47 2013
New Revision: 251855
URL: http://svnweb.freebsd.org/changeset/base/251855
Log:
Rename a parameter in sys/time.h so that you don't get warnings for things
like libdialog that include both this header and math.h.
Modified:
head/sys/sys/time.h
M
Author: theraven
Date: Mon Jun 17 15:34:22 2013
New Revision: 251856
URL: http://svnweb.freebsd.org/changeset/base/251856
Log:
Add a checker to dtc, based on a feature request from rwatson / brooks.
This checks that every node that has children specifies their register sizes.
This is not ena
Author: theraven
Date: Tue Jun 18 10:26:22 2013
New Revision: 251934
URL: http://svnweb.freebsd.org/changeset/base/251934
Log:
Fix bug in destructor for checker manager in DTC that caused segfaults on
exit.
Modified:
head/usr.bin/dtc/checking.cc
Modified: head/usr.bin/dtc/checking.cc
=
On 19 Jun 2013, at 16:13, John Baldwin wrote:
> portsnap does not work for src. (I thought we had already covered that
> in earlier threads?) portsnap only moves forward. It is a very important
> feature for our users that whatever tool they use for source updating be
> bidirectional. In part
On 20 Jun 2013, at 00:10, Warner Losh wrote:
>> - FreeBSD developers, who are probably okay with installing a port, but
>> would prefer a version that didn't depend on kitchen/sink?
>>
>> - Users, who wish to be able to update the source tree and then either build
>> world, or build some optio
On 20 Jun 2013, at 14:09, Julian Elischer wrote:
>> Which of the classes of user that I outlined do you think wants to be able
>> to do that? As a FreeBSD user, I never felt the desire to do that, but
>> maybe I was unusual. As a FreeBSD developer, I don't mind installing the svn
>> port to b
On 20 Jun 2013, at 20:34, Warner Losh wrote:
> People trying new versions of FreeBSD. Some of them install the release,
> others might install a snapshot, some will do an install world. But if it
> worked in release 9.3 and broke in 9.4, then to find where they would need to
> install an svn p
On 3 Feb 2014, at 18:32, Alexander Kabaev wrote:
> More than likely. It does appear libc++ does not go through same pains
> to maintain ABI stable as libstdc++ does. The lack of all and any
> symbol versions in shared library binary strongly suggests that not
> only they do not bother with ABI st
On 3 Feb 2014, at 22:00, Alexander Kabaev wrote:
> At the very least, new library did remove
> _ZNKSt3__111__libcpp_db12__comparableEPKvS2_ which was public before.
This symbol is part of the debugging infrastructure and is used when you build
your code with aggressive debug checks by defining
On 12 Feb 2014, at 18:42, Jung-uk Kim wrote:
> It seems Apple removed it later.
>
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131125/094181.html
>
> Do you know what they did?
They decided to break ABI compatibility with the version of XCode that ships
with the bug. This i
On 13 Feb 2014, at 01:04, Alexander Kabaev wrote:
> The refusal to use tools that are there precisely to help to help with
> the binary compatibility in favor of mindless library bumps is just sad.
Perhaps you could share with the class. What is the correct way of solving
this problem?
For
On 15 Feb 2014, at 17:02, Bruce Evans wrote:
> Why? There are hundreds if not thousands of static inline functions in
> headers, and most of these functions are not always used, so there would
> be [hundreds if not thousands] * [number of #includes] compiler warnings
> if compilers warned about
On 16 Feb 2014, at 04:09, Bruce Evans wrote:
> [a long list of corner cases where the warning may not be correct]
Fortunately, the goal of compiler warnings is not to address every possible
case, but rather to minimise false positives while still giving useful results.
The warning can be turn
Author: theraven
Date: Sun Feb 23 21:13:07 2014
New Revision: 262394
URL: http://svnweb.freebsd.org/changeset/base/262394
Log:
Fix parsing multiple roots with whitespace between them.
Patch by: Patrick Wildt
Modified:
head/usr.bin/dtc/fdt.cc
Modified: head/usr.bin/dtc/fdt.cc
=
On 25 Feb 2014, at 07:52, Baptiste Daroussin wrote:
> On Tue, Feb 25, 2014 at 05:22:22PM +1100, Peter Jeremy wrote:
>> On 2014-Feb-22 13:14:38 +0100, Baptiste Daroussin wrote:
>>> On Sat, Feb 22, 2014 at 07:23:50PM +1100, Peter Jeremy wrote:
I'd also query the reason for including Debian-sp
On 5 Mar 2014, at 23:17, Glen Barber wrote:
> After several months of testing and fixing (and breaking)
> various parts of release/release.sh changes, it is now
> possible to build FreeBSD/arm images as part of the release
> process.
That's great! How much effort would it be to add QEMU ima
On 6 Mar 2014, at 17:47, Glen Barber wrote:
> On Thu, Mar 06, 2014 at 04:37:11PM +0000, David Chisnall wrote:
>> On 5 Mar 2014, at 23:17, Glen Barber wrote:
>>
>>> After several months of testing and fixing (and breaking)
>>> various parts of release/release.s
On 26 Mar 2014, at 22:30, Dimitry Andric wrote:
> Add a SUBDIR_PARALLEL option to bsd.subdir.mk, to allow make to process
> all the SUBDIR entries in parallel, instead of serially. Apply this
> option to a selected number of Makefiles, which can greatly speed up the
> build on multi-core mac
Author: theraven
Date: Wed Apr 2 11:10:46 2014
New Revision: 264038
URL: http://svnweb.freebsd.org/changeset/base/264038
Log:
Fix an issue where the locale and rune locale could become out of sync,
causing mb* functions (and similar) to be called with the wrong data
(possibly a null pointer
s, sizeof(struct dirent *),
&dcomp, alphasort_thunk);
+#endif
*namelist = names;
return (nitems);
Added: head/lib/libc/gen/scandir_b.c
==
--- /dev/null 00:00:00 1970 (empty, becaus
On 2 Apr 2014, at 17:18, Konstantin Belousov wrote:
> This is completely wrong. You cannot modify FreeBSD 8.x namespace in
> 11.x HEAD time.
That was an error, however we are using symbol versioning completely wrongly in
FreeBSD anyway (see the last two DevSummit discussions and the wiki page)
Author: theraven
Date: Wed Apr 2 16:29:29 2014
New Revision: 264043
URL: http://svnweb.freebsd.org/changeset/base/264043
Log:
Move scandir_b to a later symbol version.
Modified:
head/lib/libc/gen/Symbol.map
Modified: head/lib/libc/gen/Symbol.map
=
On 2 Apr 2014, at 18:24, Konstantin Belousov wrote:
> It does, I read it.
Read the code again. Or even just read the comments. In particular the
blocks_abi.h file contains a detailed description of why the rest of what you
say is wrong.
> Now libc depends on the non-standard ABI
Not true,
Author: theraven
Date: Thu Apr 3 08:08:36 2014
New Revision: 264069
URL: http://svnweb.freebsd.org/changeset/base/264069
Log:
Add an extra void* cast to work around a bug in FreeBSD-gcc inherited
from Apple.
Modified:
head/lib/libc/include/block_abi.h
Modified: head/lib/libc/include/block
Author: theraven
Date: Thu Apr 3 08:16:45 2014
New Revision: 264070
URL: http://svnweb.freebsd.org/changeset/base/264070
Log:
Move _b functions into the 11.x symbol version namespace.
Modified:
head/lib/libc/Versions.def
head/lib/libc/gen/Symbol.map
head/lib/libc/stdlib/Symbol.map
Modif
Author: theraven
Date: Thu Apr 3 17:31:38 2014
New Revision: 264082
URL: http://svnweb.freebsd.org/changeset/base/264082
Log:
Fix the inheritance of the FBSDprivate_1.0 namespace.
Modified:
head/lib/libc/Versions.def
Modified: head/lib/libc/Versions.def
=
On 4 Apr 2014, at 12:52, Baptiste Daroussin wrote:
> On Wed, Apr 02, 2014 at 04:07:48PM +0000, David Chisnall wrote:
>> Author: theraven
>> Date: Wed Apr 2 16:07:48 2014
>> New Revision: 264042
>> URL: http://svnweb.freebsd.org/changeset/base/264042
>>
>&
On 4 Apr 2014, at 12:52, Baptiste Daroussin wrote:
> This breaks a couple of ports starting with cups, those ports do expect
> libdispatch to be available if _BLOCK_ exists. Do you plan to import
> libdispatch soon?
I've just tried building the print/cups-client port and it builds correctly for
On 4 Apr 2014, at 13:14, Baptiste Daroussin wrote:
> On Fri, Apr 04, 2014 at 01:10:24PM +0100, David Chisnall wrote:
>> On 4 Apr 2014, at 12:52, Baptiste Daroussin wrote:
>>
>>> This breaks a couple of ports starting with cups, those ports do expect
>>> libdi
On 4 Apr 2014, at 13:23, Jordan Hubbard wrote:
> On Apr 4, 2014, at 4:59 PM, David Chisnall wrote:
>
>> I believe that libdispatch most likely won't be imported until there is an
>> in-tree consumer, but it's in ports and there's nothing stopping ports
>&
On 4 Apr 2014, at 13:44, Jordan Hubbard wrote:
> On Apr 4, 2014, at 5:33 PM, David Chisnall wrote:
>
>> The slight problem, however, is that we would still like to be able to build
>> the base system with a more or less standard C compiler. Blocks are in
>> clang and
On 4 Apr 2014, at 14:44, Jordan Hubbard wrote:
> Ah, OK. And I’m guessing there’s been no interest in forward-porting the
> blocks support to 4.7? That’s kind of… a bummer.
I don't think so. Warner has been forward-porting some of the FreeBSD binutils
changes, but even Pedro (who did the b
Author: theraven
Date: Sat Apr 5 08:17:48 2014
New Revision: 264143
URL: http://svnweb.freebsd.org/changeset/base/264143
Log:
Silence a warning with GCC that was breaking the build with Juniper's GCC.
Reviewed by: marcel
Modified:
head/lib/libc/stdlib/atexit.c
head/lib/libc/stdlib/he
Author: theraven
Date: Sun Apr 6 17:06:27 2014
New Revision: 264196
URL: http://svnweb.freebsd.org/changeset/base/264196
Log:
Move definitions out of rpc_com so that the linker doesn't complain about
multiple definitions.
Reported by: sbruno
Modified:
head/lib/libc/rpc/rpc_com.h
he
On 16 Oct 2014, at 14:41, Mateusz Guzik wrote:
> Well, atomic_set can be as simple as v->counter = i; (which btw will
> make it look identical to linux version). This should not give any
> measureable effect unless atomic_set on given var is abused quite a lot.
v->counter = i does not establish
On 19 Oct 2014, at 13:02, Andriy Gapon wrote:
> I think that on platforms where an optimized version of fls() is available
> that
> would work faster than this cool piece of bit magic.
If you're lucky, the compiler's idiom recogniser will spot this. You're
generally better off using the built
On 4 Nov 2014, at 10:28, Stefan Farfeleder wrote:
> Shouldn't Coverity understand that err doesn't return?
err() is marked as __dead2, which expands to __attribute__((__noreturn__)). If
Coverity doesn't know that __attribute__((__noreturn__)) functions don't
return, then that's a Coverity bug
On 6 Nov 2014, at 01:04, Rui Paulo wrote:
> I don't think the non-temporary fix was ever committed. What's the problem?
> Is something else defining these methods?
Yes, they're defined by libc++ too. The problem is that gcc 4.9 wants to be
able to throw bad_array_new_length exceptions when
On 11 Nov 2014, at 16:31, Brooks Davis wrote:
> In general, we need to fix the C/C++ standard to us express the
> things we actually mean when we use const (for example see strchr()'s
> use of const). I believe the last issue now being tracked on Google's
> internal list of deficiencies in the C
1 - 100 of 269 matches
Mail list logo
