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 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 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 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 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
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 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 22 Dec 2016, at 23:02, Baptiste Daroussin wrote:
>
> I think it is pretty clear that there are too many people requesting the
> revert
> for the revert not to be done.
Even if this feature is desired, the implementation in the patch is broken and
should be reverted until a correct implement
On 16 Dec 2016, at 19:31, Baptiste Daroussin wrote:
>
> Other than that, it makes more difficult to use vanilla gcc with out userland.
> and it is adding more complexity to be able to build freebsd from a non
> freebsd
> system which some people are working on.
Why? You’ll get some spurious wa
On 4 Jul 2016, at 21:09, Adrian Chadd wrote:
>
> Right, so if we're not careful, we could leak bits of kernel memory,
> and it can also screw up key cache comparisons.
>
> (I asked this question because I've been screwed by it recentlyish,
> and it looks like the latest C standard didn't fix it.
On 22 Feb 2016, at 10:15, Kubilay Kocak wrote:
>
> For the lay persons among us (I'm genuinely interested), what are the
> the downsides to requiring initialization of all fields?
Explicit initialisation, or initialisation in general?
Being able to initialise the entire structure with code that
On 19 Feb 2016, at 23:23, Dimitry Andric wrote:
>
> This warning is only produced when you use -Wall -W, and then initialize
> structs partially, i.e. you initialize some fields but not others. I
> think this is a quite reasonable warning for a high warning level.
The warning is annoying in man
On 30 Dec 2015, at 00:48, Bruce Evans wrote:
>
> - C++ apparently spells this as both _Alignof() and alignof() after 2011/03
This is not correct. C++ spells it alignof. C spells it _Alignof, unless you
include , in which case C spells it alignof and defines _
_alignof_is_defined.
On FreeBSD
Author: theraven
Date: Tue Dec 29 16:29:42 2015
New Revision: 292876
URL: https://svnweb.freebsd.org/changeset/base/292876
Log:
Improvements to BSD-licensed DTC.
- Added an expression parser so that expressions from headers are now working
- Fixed missing null terminators on cross referen
On 26 Oct 2015, at 16:21, Eric van Gyzen wrote:
>
> One counter-argument to this change is that most applications already
> use SIMD, and the number of applications and amount of SIMD usage
> are only increasing.
Note that SSE and SIMD are not the same thing. The x86-64 ABI uses SSE
register
On 13 Nov 2015, at 08:35, Konstantin Belousov wrote:
>
> On Fri, Nov 13, 2015 at 09:18:54AM +0100, Hans Petter Selasky wrote:
>> Hi,
>>
>> On 11/12/15 18:17, Conrad Meyer wrote:
>>> These should cast through (u)intptr_t rather than unsigned long.
>>>
>>
>> This is Linux code, and they use "uns
Author: theraven
Date: Mon Oct 26 11:02:57 2015
New Revision: 289996
URL: https://svnweb.freebsd.org/changeset/base/289996
Log:
Update some obsolete information in the HACKING document.
Reported by: bapt
Modified:
head/usr.bin/dtc/HACKING
Modified: head/usr.bin/dtc/HACKING
On 26 Oct 2015, at 10:48, Baptiste Daroussin wrote:
>
> Just jumping on that one, you should probably revisit de HACKING files :)
Ah, good point. I’ll update them.
David
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/list
Author: theraven
Date: Mon Oct 26 10:37:17 2015
New Revision: 289995
URL: https://svnweb.freebsd.org/changeset/base/289995
Log:
Ensure that dtc is built in C++11 mode.
Reported by: George Abdelmalik
Modified:
head/usr.bin/dtc/Makefile
Modified: head/usr.bin/dtc/Makefile
===
Author: theraven
Date: Sun Oct 25 14:52:16 2015
New Revision: 289935
URL: https://svnweb.freebsd.org/changeset/base/289935
Log:
Lots of improvements to the BSD-licensed dtc
- Various fixes to includes (including recursive includes)
- Lots of testing that the output exactly matches GPL'd d
On 8 Oct 2015, at 13:51, Andriy Gapon wrote:
>
> What if one day github disappears but FreeBSD is still going?
> The full commit message would be lost.
That’s not the only thing that is bad about this commit message. Why ‘Assume
C89?’ We compile libc as C99 + GNU extensions and are likely to
On 17 Sep 2015, at 08:20, Hans Petter Selasky wrote:
>
> On 09/17/15 00:05, Gleb Smirnoff wrote:
>> Weren't you explicitly asked not to touch this system without a proper
>> review and discussion?
>
> Adding a new function is not touching code.
Adding a new interface to an existing core subsyst
On 13 Aug 2015, at 08:56, Marcelo Araujo wrote:
>
> So it means, this commit here was right already:
> https://svnweb.freebsd.org/base?view=revision&revision=286651
>
> Although I made a mistake with the date.
More or less. I partly agree with Bruce that suggesting memcpy is misleading.
I’d
On 13 Aug 2015, at 08:11, Marcelo Araujo wrote:
>
> The bcopy() was removed in IEEE Std 1003.1-2008 and it is marked as LEGACY in
> IEEE Std 1003.1-2004. However, BSD has its implementation before IEEE Std
> 1003.1-2001.
>
> In my understood it is obsolete on POSIX, but not truly obsolete for
On 2 Aug 2015, at 17:34, Ian Lepore wrote:
>
> It generates a compiler error, so the output is going to contain
> file-and-line like any other compiler error, as well as the message from
> the source code.
It will, of course, vary between compilers, but this is what clang generates:
$ cat stati
On 29 Jul 2015, at 14:36, Dimitry Andric wrote:
>
> I'll have a look if this can be fixed using pre-C++11 constructs
LLVM 3.4 had its own unique pointer template (llvm::OwningPtr? The doxygen
docs for 3.4 are no longer online, unfortunately). I don’t think that
unique_ptr from libc++ require
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 loc
On 11 Jul 2015, at 21:56, Konstantin Belousov wrote:
>
>> Bucket 2: The system call could also just fail and return an error
>> (MSG_NOSIGPIPE).
> SIGPIPE exists to ensure that naive programs do something reasonable
> when their stdout suddenly goes away. Or, transposing the PoV, it allows
> to w
On 9 Jul 2015, at 10:19, NGie Cooper wrote:
>
> Yes, but this case will fail for gcc 4.3 ~ 4.4 through 5.x if you use
> my recommended method...
I think that’s probably fine. We basically have four cases that we care about:
- People who are using clang because it’s the system compiler [works]
On 9 Jul 2015, at 03:53, NGie Cooper wrote:
>
> $ cat ~/has_immintrin.c
> #include
>
> #if __has_include()
> #error "I have immintrin.h"
> #else
> #error "I don't have immintrin.h"
> #endif
> $ clang -c ~/has_immintrin.c
> /home/ngie/has_immintrin.c:4:2: error: "I have immintrin.h"
> #error "I
On 19 Jun 2015, at 15:32, Marcelo Araujo wrote:
>
> Maybe would be a good idea run an 'exp run' with this patch? Just to double
> check if any port will break, although after you rename, I don't believe it
> will conflict anymore, however an 'exp run' would show you it.
It’s probably worth doi
On 19 Jun 2015, at 14:41, Hans Petter Selasky wrote:
>
> On 06/19/15 14:54, David Chisnall wrote:
>> I definitely know of people building out-of-ports programs on FreeBSD whose
>> code you have just broken (including myself,
> > though I do Objective-C stuff on 10, so
On 19 Jun 2015, at 12:57, Hans Petter Selasky wrote:
>
> Hi,
>
>> Then they will get a compile error no matter what GNUstep’s Foundation.h
>> does. It can’t prevent cdefs.h from redefining __weak to be something
>> different.
>>
>
> Except "#undef __weak”
Please read the example that I wro
On 19 Jun 2015, at 11:45, Hans Petter Selasky wrote:
>
> Appearently this will be fixed in GNUSTEP base:
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/cdefs_elf.h?only_with_tag=MAIN
>
> Is this still an issue?
It is impossible to fix it in GNUstep Base, because we can’t guarantee that
u
I only just caught this (having seen the fallout from NetBSD doing the same
thing in a shipping release and the pain that it’s caused):
__weak is a reserved keyword in Objective-C, please pick another name for this.
This in cdefs.h makes it impossible to include any FreeBSD standard headers in
On 13 Jun 2015, at 11:17, Ian Lepore wrote:
>
> If you would have told me a year ago that you had a simple scheme that
> could make 30 years of experience maintaining code for unix-like systems
> completely worthless I would have been skeptical, but it seems we're
> well on our way.
There is a l
Author: theraven
Date: Fri Apr 24 10:21:20 2015
New Revision: 281927
URL: https://svnweb.freebsd.org/changeset/base/281927
Log:
__xlocale_C_ctype should not be const. It contains a reference count that is
modified by newlocale / duplocale / freelocale.
MFC after:1 week
Modified:
he
Author: theraven
Date: Fri Apr 24 10:17:55 2015
New Revision: 281925
URL: https://svnweb.freebsd.org/changeset/base/281925
Log:
Small changes to locale-related man pages.
Fix a missing .h and change the recommended include for the POSIX2008
functions from xlocale.h to locale.h. Including xlo
On 20 Apr 2015, at 17:19, Bruce Evans wrote:
>
> Enums should never be used in ABIs, since their size can be anything
> large enough.
The rules for the size of enums also differ between C and C++, though clang
(and, I think, gcc) support an attribute for specifying the enum type.
> They also c
On 2 Apr 2015, at 11:22, Mateusz Guzik wrote:
>
> Now one has to wonder how obnoxious one has to get so that people think
> "this can't be real".
>
> I tried really hard. :)
Not sure about your locale, but here (where the tradition originated) if you
fool someone in the morning then they are a
On 1 Apr 2015, at 18:41, Mateusz Guzik wrote:
>
> I guess you were right, this was bad.
>
> I moved the implementation to null.c, I hope this makes everyone happy.
>
> https://lists.freebsd.org/pipermail/svn-src-all/2015-April/101876.html
This almost certainly does not make people happy:
- *
On 10 Mar 2015, at 10:18, Konstantin Belousov wrote:
>
> Because you cannot grep for the panic string when __func__ is used.
The userspace assert uses __func__, __FILE__ and __LINE__, which means that you
never need to grep the source code to find out where the assert came from: the
assertion
On 5 Mar 2015, at 14:13, Slawa Olhovchenkov wrote:
>
> Not better, no.
Does telnet support creating server sockets? No.
Does telnet support IPsec? No.
Does telnet let you specify the tcp window size? No.
Does telnet come with a massive selection of options for insecure login /
authenticatio
On 5 Mar 2015, at 14:04, Dmitry Sivachenko wrote:
> It is so nice to have most useful stuff out of the box.
The question is whether a tool for logging into remote machines without
encryption is 'the most useful stuff'. The tool is also [ab]used for network
testing, but we already provide a be
On 5 Mar 2015, at 13:14, Slawa Olhovchenkov wrote:
>
> In previos message -- silently return when telnet speak about used IP
> address and diagnostic messages. One simple command do many diagnostic
> information.
Okay, so check the return code. Or pass -v if you want more verbose
information:
> On 5 Mar 2015, at 12:42, Slawa Olhovchenkov wrote:
>
>> netcat - nc(1) - which can also work in the other direction and is designed
>> specifically for this purpose.
>
> nc(1) don't correctly work.
It works for me for everything that I used to use telnet for (connection
testing, checking p
On 5 Mar 2015, at 12:21, Slawa Olhovchenkov wrote:
>
>> I guess when they are going to be not precious enough to be removed? :)
>>
>> In modern world of ssh and https, does any OS require them in base?
>
> yes.
> Some telecom equipment require rlogin.
'Some relatively obscure use case needs th
On 5 Mar 2015, at 12:33, Slawa Olhovchenkov wrote:
>
> And how to test open/listing ports/sockets?!
netcat - nc(1) - which can also work in the other direction and is designed
specifically for this purpose.
> How to connect to mpd control socket?!
mpdcon from the command line, MPDroid from my
On 5 Mar 2015, at 12:30, Slawa Olhovchenkov wrote:
>
> Yes, if ships before (don't break if working).
> Some Linux distro remove telnet from default install.
> Do you like to remove telnet also?
Absolutely, now that netcat is part of the default install. For anything that
a sane user might con
On 10 Feb 2015, at 18:30, Rui Paulo wrote:
>
> Another thing I had in mind (which is more work) was to abstract the devctl
> kernel code in an API which could make it easy to fan out the notifications
> to multiple /dev devices. However, that may be overkill.
This kind of notification is some
On 21 Nov 2014, at 23:26, Scott Long wrote:
> That’s a good question to look further into. I didn’t see any measurable
> differences with this change. I think that the cost of the function call
> itself masks the cost of a few extra instructions, but I didn’t test with
> switching it on/off
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
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 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 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 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 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
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 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
>
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 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 3 Jun 2014, at 06:01, Adrian Chadd wrote:
> I wonder if in the short term we should just use inlines for now, at
> least so the methodization can get done without hurting people on
> ARM/MIPS.
It's probably worth thinking a bit more carefully about the KPI, since it's
something we'll likely
On 30 May 2014, at 06:18, Rui Paulo wrote:
> Is this going to cause any ports fallout?
It shouldn't do. Any code that compiles on OS X will expect these to be in the
correct place, and since DragonFly applied the fix first we'd hopefully have
found any fallout via dports.
David
On 20 May 2014, at 18:16, Gleb Smirnoff wrote:
> Would be cool if most of tools (netstat, systat, etc...) could
> determine size of terminal and dynamically widen all their fields.
> Thus, tool can run w/o any abbreviations when run in a script mode,
> run abbreviated on a small terminal, and run
On 11 May 2014, at 14:05, Ian Lepore wrote:
> On Sun, 2014-05-11 at 13:58 +0100, David Chisnall wrote:
>> On 11 May 2014, at 13:53, Ian Lepore wrote:
>>
>>> Ooops, indeed, thanks. Although... it's a good change in terms of
>>> speeding up the build, I ju
On 11 May 2014, at 13:53, Ian Lepore wrote:
> Ooops, indeed, thanks. Although... it's a good change in terms of
> speeding up the build, I just didn't intend to commit it until it got
> tested with -j levels higher than I can test with my little 6-core
> machine.
I'd be happy to test it on a 32
Bruce,
On 6 May 2014, at 05:46, Bruce Evans wrote:
> The standard behaviour is undefined. It cannot be relied on. From C99
> (n869.txt):
>
> %7.20.3.1 The calloc function
> % %Synopsis
> % %[#1]
> % %#include
> %void *calloc(size_t nme
On 5 May 2014, at 22:51, Andrey Chernov wrote:
> For standard malloc/realloc interface it is up to the caller to check
> n*size not overflows. You must trust caller already does such check.
Do a search of the CVE database sometime to see how well placed that trust
generally is. Or even look at
On 5 May 2014, at 22:40, Andrey Chernov wrote:
> On 05.05.2014 22:28, David Chisnall wrote:
>> On 5 May 2014, at 18:42, Andrey Chernov wrote:
>>
>>> Please don't commit OpenBSD errors. Now you mix calloc() with the
>>> realloc() for the same varia
On 5 May 2014, at 22:33, Warner Losh wrote:
> reallocf():
> The reallocf() function is identical to the realloc() function, except
> that it will free the passed pointer when the requested memory cannot be
> allocated. This is a FreeBSD specific API designed to ease the problems
>
On 5 May 2014, at 20:49, Pedro Giffuni wrote:
> Yes, but I reverted it because there are other ways to check for overflows
> without the performance hit.
Do we have a good reusable routine for doing this somewhere? Clang and gcc
both have some idiom recognisers that try to spot when people ar
On 5 May 2014, at 18:42, Andrey Chernov wrote:
> Please don't commit OpenBSD errors. Now you mix calloc() with the
> realloc() for the same variable later which makes calloc() zeroing
> pointless and waste of CPU.
The purpose of calloc() here is not (primarily) to get the zero'd size, it's to
g
On 9 Apr 2014, at 15:19, Kubilay Kocak wrote:
> That expectation is orthogonal to whether we or other projects do it one
> way or another. RHEL users may well be as confused as ours (whether of
> not ours are). It may be relevant as a data point, but not for decision
> making.
I can confirm that
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
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
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
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 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: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 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 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
>>
>&
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
=
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 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
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,
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
=
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
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
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
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 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 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
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 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
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 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 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 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 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
1 - 100 of 313 matches
Mail list logo
