Re: format strings in libexpat
On Sat, Feb 18, 2023 at 08:22:56AM +, Miod Vallat wrote: > libexpat assumes the compiler might not know of the C99 format > specifiers for ptrdiff_t and size_t, and tries to guess alternative > format strings. The problem is the printf runtime. There is no good way to detect the support without running a test program and for a library that is explicitly used in many cross-compilation environments, that's a problem. > The following diff relieves it of this misery (but can't be sent > upѕtream, as it is too aggressive). I think it might be a good idea to try again. Since C++11 support made much of the runtime parts of C99 mandatory, even Microsoft had to adopt and they were the last big holdout. I don't know how ancient the systems are that expat targets, but asking seems to be a reasonable idea nowadays. Joerg
Re: Inconsistent isdigit(3) man page
Am Fri, Jan 20, 2023 at 09:32:38AM -0700 schrieb Bob Beck: > Various spec docs seem all over the place on this, so I am also > paging Dr. Posix in this email... Hi Philip! :) Is isdigit() > safe from being screwed up by locale or not? I think this POSIX.1-2017 (i.e. Open Group Issue 7), locales are required to be based on the Portale Character Set and the digit class is required to map the ASCII code points only. In that sense, isdigit() is locale invariant. Joerg
Re: ssh: progress meter: prefer setitimer(2) to alarm(3)
On Sat, Dec 31, 2022 at 04:16:18PM -0500, Scott Cheloha wrote: > Even Windows went with Linux: WSL2 has Linux syscall compatibility, WSL2 is running a Linux kernel under HyperV. WSL1 is the system call translation layer. Joerg
Re: ssh-keygen(1): by default generate ed25519 key (instead of rsa)
Am Tue, Nov 08, 2022 at 01:23:52PM +1100 schrieb Darren Tucker: > On Tue, 8 Nov 2022 at 11:05, Joerg Sonnenberger wrote: > > Am Mon, Nov 07, 2022 at 12:53:43PM +0100 schrieb Renaud Allard: > [...] > > > Wouldn't it also be a good idea for ssh client to also try the ed25519 key > > > first if there are multiple keys? > > > > That's already happening. > > Not quite: the default value for IdentityFile has RSA before ED25519. > Changing the default order is a potentially disruptive change, though, > as configs that previously worked may hit MaxAuthTries instead. > > IdentityFile > [...] The default is ~/.ssh/id_rsa, > ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, > ~/.ssh/id_ed25519_sk and ~/.ssh/id_dsa. > > $ SSH_AUTH_SOCK= ssh -F/dev/null localhost > Enter passphrase for key '/home/dtucker/.ssh/id_rsa': > Enter passphrase for key '/home/dtucker/.ssh/id_ecdsa': > Enter passphrase for key '/home/dtucker/.ssh/id_ed25519': I tried that first and it picked up id_ed25519 from the agent, even if both keys are accepted by the server. I guess that makes the answer a case of "it's complicated". Joerg
Re: ssh-keygen(1): by default generate ed25519 key (instead of rsa)
Am Mon, Nov 07, 2022 at 12:53:43PM +0100 schrieb Renaud Allard: > > > On 11/6/22 15:29, Job Snijders wrote: > > Dear all, > > > > Support for using Ed25519 for server and user authentication was > > introduced in 2014. I like the compactness of Ed25519 public keys. > > > > Perhaps now is a good time to make Ed25519 the default key type when > > invoking ssh-keygen(1) without arguments? > > > > Kind regards, > > > > Job > > > Hi Job, > > Wouldn't it also be a good idea for ssh client to also try the ed25519 key > first if there are multiple keys? That's already happening. Joerg
Re: ssh-keygen(1): by default generate ed25519 key (instead of rsa)
On Sun, Nov 06, 2022 at 04:29:59PM +0100, Solène Rapenne wrote: > Le Sun, 6 Nov 2022 14:29:52 +, > Job Snijders a écrit : > > > Dear all, > > > > Support for using Ed25519 for server and user authentication was > > introduced in 2014. I like the compactness of Ed25519 public keys. > > > > Perhaps now is a good time to make Ed25519 the default key type when > > invoking ssh-keygen(1) without arguments? > > > > Kind regards, > > > > Job > > Does it have other advantages over rsa apart being more compact? If server and client are in the same CPU range, the much faster signing (factor 15) will easily compensate the slowing verification (factor 6) when compared with 2048bit RSA. This is why servers generally prefer ECC, especially with perfect forward security. It doesn't matter as much in the context of OpenSSH. For the question at hand: I regulary have to interact with SSH servers that don't support ECDSA or ED25519. Those are mostly non-OpenSSH implementations and/or deeply embedded devices. Joerg
Re: wc(1): add -L flag to write length of longest line
On Thu, Sep 29, 2022 at 08:39:16PM +1000, Jonathan Gray wrote: > wc counts items in files. Finding the longest item indeed sounds > like a task better suited to awk. Finding outliers, means and counting are all parts of the same basic class of operations. A good implementation of all of them requires constant space and a fixed time per input character. An implementation in awk will generally not have that property. Joerg
SSH_USER_AUTH
Hello, does anyone still know the motivation for SSH_USER_AUTH pointing to a file with the data instead of containing it directly? It makes the use a bit more annoying and the only argument I can come up with is not putting up to about 4KB into the environment. Joerg
Re: quiz(6): update european countries
On Mon, Jul 04, 2022 at 05:44:33PM -0400, Daniel Dickman wrote: > I also noticed NetBSD removed The Hague as a capital of The Netherlands, > but I disagree with that. Maybe some of the Dutch folks on this mailing > list can weigh in which is right. Amsterdam is the capital, The Hague is the seat of government. Similar to what Germany had for a while after the reunion with Bonn as seat of government and Berlin as capital. There are a couple of other examples like that. Joerg
Re: Picky, but much more efficient arc4random_uniform!
Am Wed, May 18, 2022 at 12:49:21PM +0200 schrieb Steffen Nurpmeso: > What surprised me was that the Apple code requires more calls, and > that today divisions and multiplications still matter. I think it > was the Cyrix 166+ (or was it Athlon 1600+) where +,-,<<,>> was > one cycle, * was ten cycles, and %,/ was fourty cycles. But > i think the Core i5 8th Gen that i have requires one cycle for all > of them. I dare you to find any CPU optimized for speed where division and modulo are as fast as multiplication. What you have nowadays is a single cycle for basic operations like additions and shifts, about three cycles for multiplications (on x86 at least) and an order of magnitude more for division. That's not really surprising either if you consider that integer multiplication has a fast circuit implementation where as division is often implemented as cascading conditional subtraction. The difference matters enough turning the reminder operation in the ELF hash into essentially (x - x * (1/size) * size) give a 2% speed up for a large application like Firefox ten years ago. Joerg
Re: Picky, but much more efficient arc4random_uniform!
Am Fri, May 13, 2022 at 09:43:26AM -0500 schrieb Luke Small: > I made a couple new versions of a new kind of arc4random_uniform-like > function and some example functions which use them. Instead of having a > sufficiently large random number greater than the modulus, I pick a random > number using arc4random() from a bitfield where the length of the bitfield > is just below or slightly beyond the value of the modulus and returns the > bitfield it if it is less than the value of the modulus. If your main use case is limiting the amount of cryptography when using small bounds, there is a much simpler approach to be taken here. For boundaries below 256, use arc4random_buf to extract one byte if bound is a power of two, otherwise two. This gives most of the performance benefit without complicating the algorithm. Extracting two bytes ensures that the propability of success is > 99% and the double extracting doesn't eat up the benefits. Joerg
Re: EVFILT_USER and kevent(2)
Am Sat, Apr 30, 2022 at 10:05:05PM +0100 schrieb Stuart Henderson: > On 2022/04/30 13:51, Visa Hankala wrote: > > I am in two minds about EVFILT_USER. On the one hand, having it on > > OpenBSD might help with ports. > > No opinion on the addition, but I don't think we ran into this in ports > so far. There is software in ports which can use it but it can all work > without too. (I know about zeek and asterisk's res_timing_kqueue, though > we typically don't use the latter at all anyway as it has a pluggable > timer implementation and the pthread timer seems more accurate). When this was discussed in NetBSD, the best example brought up was nginx and its thread pool, which supposedly is disabled otherwise. It's NetBSD's PR 55663, if anyone wants to follow that discussion. Joerg
Re: clang: compile static analyzer
Am Fri, Jan 21, 2022 at 12:45:56AM +0100 schrieb Steffen Nurpmeso: > Fwiw, i have been astonished by this thread. I found scan-build > to generate a lot of false warnings, so much indeed that i stopped > using it .. in summer 2017. I've spend time on the static analyzer output in NetBSD and I wouldn't say so much that it creates too many false warnings, but that the pure text version is not helpful. The HTML output at least explains the reasoning. From those pre-conditions, it is often easy to deduce why it is a false positive from *other* conditions in the program. Properly asserting those would certainly improve code. The biggest advantage in coverity is the logic they have for preserving the state of analysis across code changes, e.g. once you tag a reported issue as analyzed and not a problem, it tries very hard to not show it again. Joerg
Re: Stop mentioning ld(1) warning messages in mktemp.3 and tmpnam.3
On Thu, Nov 04, 2021 at 06:30:29PM -0600, Theo de Raadt wrote: > Joerg Sonnenberger wrote: > > > On Thu, Nov 04, 2021 at 10:12:32PM +0100, Frederic Cambus wrote: > > > I'm building myself a small tool [1] to display .gnu.warning.* sections > > > names in ELF objects along with their content, and will check which > > > other projects use those sections. So far, aside from us, FreeBSD, > > > NetBSD, and DragonFly all use these sections in their libc, and glibc > > > does as well. > > > > In the past, the linker section was the only option to get usage > > warnings. It has the major downside that the implementation is somewhat > > buggy as GNU ld triggers the warning in a number of cases that do not > > include usage and there is no way to flag individual uses as safe. > > This disadvantage doesn't exist with the warning attribute. The downside > > of the attribute is that it requires very recent clang or modernish GCC > > to be supported. If it is supported, it provides a significant better > > user experience. > > And I believe that is false. > > Compile-time warnings scroll off the screen, and result in noone giving a > damn. > > When the warnings are at the very end, as they are with ld, at least > some people pay attention. > > I've been watching this for decades, and I can say with confidence that > everyone has learned to tune-out compile time warnings to a very high > degree. I don't completely disagree about the compiler warnings, but they at least tell you where the problem is in a reasonable precise manner. We also now have reasonable good ways to selectively turn them into compiler errors. The ld warnings are worse in pretty much every way: - they are non-fatal by default as well - they are all or nothing - you can't whitelist individual warnings - they give very poor diagnostics for finding where the problem is - they have known false positives e.g. when using shared linking Joerg
Re: Stop mentioning ld(1) warning messages in mktemp.3 and tmpnam.3
On Thu, Nov 04, 2021 at 10:12:32PM +0100, Frederic Cambus wrote: > I'm building myself a small tool [1] to display .gnu.warning.* sections > names in ELF objects along with their content, and will check which > other projects use those sections. So far, aside from us, FreeBSD, > NetBSD, and DragonFly all use these sections in their libc, and glibc > does as well. In the past, the linker section was the only option to get usage warnings. It has the major downside that the implementation is somewhat buggy as GNU ld triggers the warning in a number of cases that do not include usage and there is no way to flag individual uses as safe. This disadvantage doesn't exist with the warning attribute. The downside of the attribute is that it requires very recent clang or modernish GCC to be supported. If it is supported, it provides a significant better user experience. Joerg
Re: Should 80MB of RAM be enough for kernel relinking on i386?
On Thu, Sep 23, 2021 at 09:21:46PM +0100, Stuart Henderson wrote: > (the extra register used by PIE > hurts i386 mode a lot more than amd64 > mode with its extra registers), Just for the sake of correctness: it hurts much less on x86_64, because there is IP-relative addressing for code *and* data. Unless you are using the medium or large code model (> 2GB code or data), functions can compute addresses in a single instruction without a temporary register or binding one to the GOT. So you get a smaller prologue and epilogue in any function that touches a a global variable. Joerg
Re: iked(8): Increase the default Child SA data lifetime limit
On Tue, Aug 03, 2021 at 01:12:54AM +0300, Vitaliy Makkoveev wrote: > Index: sbin/iked/types.h > === > RCS file: /cvs/src/sbin/iked/types.h,v > retrieving revision 1.43 > diff -u -p -r1.43 types.h > --- sbin/iked/types.h 13 May 2021 15:20:48 - 1.43 > +++ sbin/iked/types.h 2 Aug 2021 21:41:55 - > @@ -67,7 +67,7 @@ > #define IKED_CYCLE_BUFFERS 8 /* # of static buffers for mapping */ > #define IKED_PASSWORD_SIZE 256 /* limited by most EAP types */ > > -#define IKED_LIFETIME_BYTES 536870912 /* 512 Mb */ > +#define IKED_LIFETIME_BYTES 1073741824 /* 512 Mb */ > #define IKED_LIFETIME_SECONDS10800 /* 3 hours */ > > #define IKED_E 0x1000 /* Decrypted flag */ > Comment and value don't match? Also, isn't 512MB quite low with modern crypto algorithms? Joerg
Re: getopt.3 bugs section
On Sat, Jan 09, 2021 at 02:07:32PM +0100, Christian Weisgerber wrote: > Edgar Pettijohn: > > > In the BUGS section for the getopt(3) manual it mentions not using > > single digits for options. I know spamd uses -4 and -6 there are > > probably others. Should they be changed? Or is the manual mistaken? > > You misunderstand. The manual warns against the use of digits to > pass numerical arguments. This usage exists in some historical > cases, e.g. "nice -10" where <10> is the number 10. > > The use of digits as flags characters, like -4 or -6 to indicate > IPv4 or IPv6, is perfectly fine. If you want to change this, it seems best to point to existing good and bad examples. Good: - using digits as flags, e.g. for IPv4 vs IPv6 support Bad: - using digits as numbers, e.g. nice(1), tail(1) historic use. Recommendation to avoid bad use: -n Joerg
Re: [PATCH 3/6] crypto: cast: convert to use new modes 64-bit helpers
On Sat, Jun 27, 2020 at 10:36:58PM +0300, Dmitry Baryshkov wrote: > + * 3. All advertising materials mentioning features or use of this software > + *must display the following acknowledgement: > + *"This product includes cryptographic software written by > + * Eric Young (e...@cryptsoft.com)" > + *The word 'cryptographic' can be left out if the rouines from the > library > + *being used are not cryptographic related :-). Is the typo in routines necessary? Joreg
Re: libkern: ffs() for arm64
On Mon, Jun 08, 2020 at 11:16:59PM +0200, Christian Weisgerber wrote:
> I blame dlg@ for making me scrutinize the POWER7 instruction set,
> which led me to the clz instruction, which led me to ffs(). I
> wanted to add this to libc, but then realized the futility because
> the compiler already inlines its optimized copy of ffs(). However,
> this optimization is disabled for the kernel with -ffreestanding.
int ffs(int x) {
return __builtin_ffs(x);
}
doesn't work?
Joerg
Re: locale thread support
On Fri, May 22, 2020 at 01:50:44PM +0200, Marc Espie wrote: > uselocale is fine, but it is not on windows, so highly portable code tends to > prefer strtod_l... The problem with uselocale is two fold and why I explicitly decided to not implement it in NetBSD: (1) It can come at a significant performance cost as all locale-aware operations need to access thread-specific memory. While that is moderate fast on x86, other architectures are not so nice. Even on x86, it can easily result a factor of two or three for things like the ctype.h macros. (2) It can easily POLA for code that different threads have differnt locales. There is a lot of existing code written that don't know how to deal with. Add that the explicit *_l functions are the preferred mechanism for implementing the primitives in higher languages and it becomes a no-brainer. Joerg
Re: Clarify drand48() return values
On Thu, Dec 19, 2019 at 04:19:36PM -0800, j...@bitminer.ca wrote: > > Clarify that drand48 returns values not including 1.0. > > Index: src/lib/libc/stdlib/rand48.3 > === > RCS file: /cvs/src/lib/libc/stdlib/rand48.3,v > retrieving revision 1.20 > diff -u -r1.20 rand48.3 > --- src/lib/libc/stdlib/rand48.3 10 Nov 2015 23:48:18 - 1.20 > +++ src/lib/libc/stdlib/rand48.3 20 Dec 2019 00:08:24 - > @@ -101,7 +101,8 @@ > return values of type double. > The full 48 bits of r(n+1) are > loaded into the mantissa of the returned value, with the exponent set > -such that the values produced lie in the interval [0.0, 1.0]. > +such that the values produced lie in the interval (0.0, 1.0] (which > +excludes 1.0 and includes 0.0). > .Pp > .Fn lrand48 > and ...except that your patch says the reverse. Joerg
Re: amd64: i8254_delay(): simpler microsecond->ticks conversion
On Sun, May 19, 2019 at 12:25:04PM -0500, Scott Cheloha wrote: > guenther@ has pointed out in a separate mail that I can make the diff > smaller with a cast and that it's acceptable here. As with the code > it's replacing I've left a comment explaining what we're doing. There is a rather obvious bug in the function for n < 0, but that's older. You should get better assembly by using an intermediate cast to uint64_t anyway, esp. if the compiler can't prove that n is positive. Joerg
Re: signal to process or posix thread
On Fri, Jun 29, 2018 at 04:21:17PM +0200, Alexander Bluhm wrote: > The problem is that POSIX has signals that are sent to processes > and signals sent to individual threads. Our kernel does not support > this properly. Well, not exactly. POSIX has synchronous and asynchronous signals. I.e. SIGFPE after a division by zero or SIGBUS/SIGSEGV are typically synchronous traps thrown by the processing of the instructions of the current thread. This signals are delivered to the current thread. All other signals, i.e. those created as side effect of kill(2) are sent to the process at large. Those signals are handled by the first thread that doesn't have them masked. In that case, it should be put on the pending list of the process and any unmasking operation should check the pending list on whether a signal should be delivered delayed. Joerg
Re: cast __swapXX in _endian.h to help the compiler
On Thu, Jan 11, 2018 at 01:53:00PM +1000, David Gwynne wrote: > this silences the warnings when building dhclient. You might want to check if __builtin_bswap16 and friends exist first and prefer to use them directly. Joerg
Re: use inline functions instead of __statement
On Thu, Jan 04, 2018 at 09:35:36AM +1000, David Gwynne wrote: > these days you can use inline functions to get the same effect, but > it is a more obvious and standard language feature. If you want to go that way, you still should very likely mark the functions as always_inline, otherwise the debugging experience will be a lot more annoying. That said, at least for clang it would be even better to just use the builtin. Joerg
Re: sign of char on arm64
On Thu, Dec 14, 2017 at 12:17:56PM +0100, Mark Kettenis wrote: > Pretty sure Linux uses the same defaults for the signedness of char as > everybody else. But since both signed and unsigned char have to work, > it might very well be that the rust developers decided to ignore this > largely historic inconsistency. I doubt the performance difference is > significant in any way for modern code. The issue is not so much a question of performance, but whether zero or sign extension is used in various places. Joerg
Re: Implement __cxa_thread_atexit
On Mon, Nov 20, 2017 at 10:07:33PM +0100, Mark Kettenis wrote: > > Date: Sun, 19 Nov 2017 23:13:05 +0100 > > From: Joerg Sonnenberger <jo...@bec.de> > > > > On Sun, Nov 19, 2017 at 11:05:31PM +0100, Joerg Sonnenberger wrote: > > > On Sun, Nov 19, 2017 at 10:04:45PM +0100, Mark Kettenis wrote: > > > > Here is an update diff that implements __cxa_thread_atexit which is > > > > emitted by clang (and modern gcc) to implement certain aspects of > > > > C++11 thread_local. > > > > > > Note that without providing __cxa_thread_atexit, gcc will not detect it > > > and try to provide its own. > > > > __cxa_thread_atexit_impl I mean, sorry. > > GCC 7.2 also checks for __cxa_thread_atexit. > > GCC 6.4 and 4.9 only check for __cxa_thread_atexit_impl. The > consequence is that code compiled with ports GCC will indeed use GCC's > implementation instead of the one in libc. That means it doesn't > prevent the unloading of shared libraries. And with the current diff > static linking will fail if __cxa_thread_atexit is used. If ports > people deem fixing this is important, I can follow what FreeBSD did > and put the implementation in a separate file and/or provide an alias. It has also a good chance of breaking static linkage. Providing an alias is likely the easiest solution. Taking from experience :) Joerg
Re: Implement __cxa_thread_atexit
On Sun, Nov 19, 2017 at 11:05:31PM +0100, Joerg Sonnenberger wrote: > On Sun, Nov 19, 2017 at 10:04:45PM +0100, Mark Kettenis wrote: > > Here is an update diff that implements __cxa_thread_atexit which is > > emitted by clang (and modern gcc) to implement certain aspects of > > C++11 thread_local. > > Note that without providing __cxa_thread_atexit, gcc will not detect it > and try to provide its own. __cxa_thread_atexit_impl I mean, sorry. Joerg
Re: Implement __cxa_thread_atexit
On Sun, Nov 19, 2017 at 10:04:45PM +0100, Mark Kettenis wrote: > Here is an update diff that implements __cxa_thread_atexit which is > emitted by clang (and modern gcc) to implement certain aspects of > C++11 thread_local. Note that without providing __cxa_thread_atexit, gcc will not detect it and try to provide its own. Joerg
Re: kq_count earlier!
On Mon, Oct 09, 2017 at 12:27:50PM +0200, Martin Pieuchot wrote: > On 09/10/17(Mon) 12:22, Joerg Sonnenberger wrote: > > On Mon, Oct 09, 2017 at 12:15:46PM +0200, Martin Pieuchot wrote: > > > Diff below is a small cleanup to keep the accounting of events in > > > sync with the number of events on the list. This is a noop for the > > > moment, but it's small & easy part to review of my upcoming diff. > > > > Well, not counting the markers allows skipping the scan when no real > > content is on the list. That's a non-trivial condition if the list is > > scanned by multiple threads and started non-empty. > > I don't understand if you're suggesting something or not. Did you spot > something wrong in the diff I sent? You are removing optimisation potential. Counting only real events is more useful than counting the entries on the list. Joerg
Re: kq_count earlier!
On Mon, Oct 09, 2017 at 12:15:46PM +0200, Martin Pieuchot wrote: > Diff below is a small cleanup to keep the accounting of events in > sync with the number of events on the list. This is a noop for the > moment, but it's small & easy part to review of my upcoming diff. Well, not counting the markers allows skipping the scan when no real content is on the list. That's a non-trivial condition if the list is scanned by multiple threads and started non-empty. Joerg
Re: sin() implementation
On Fri, Sep 29, 2017 at 11:16:24AM +0200, Alexandre Ratchov wrote: > On Wed, Sep 27, 2017 at 03:09:48PM +0200, Joerg Sonnenberger wrote: > > On Wed, Sep 27, 2017 at 08:40:26AM +0200, Alexandre Ratchov wrote: > > > Even on modern amd64s integer arithmetics and bitwise operations are > > > faster (and more precise in many cases) than floating point > > > equivalents. > > > > Can you actually substanciate this claim? > > [OT] > > I'm working on typical signal processing code doing mostly > multiplications, additions and table lookups. For instance, when we do > the following with floats: > > float a, b, x, y; > y = a * x + b; > > we get 24 bits of precision as floats have 24-bit mantissa. If, with > proper typedefs and #ifdefery, we replace floats by ints representing > the same numbers as 1:4:27 fixed-points: > > int a, b, x, y; > y = ((long long)a * x >> 27) + b; > > we get 28 bits of precision, i.e. 4 extra bits of precision compared > to floats. > > I just did a quick test on a i5, gcc 4.2. The fixed-point version > consumes 10% to 50% less CPU depending on the algorithm. To test, I > just run the algorithm during 10 seconds and measure the throughput. You are comparing Apples and Oranges. Just for starters, it is quite common in newer (as in: less than 20 years old) calling conventions to pass the function arguments via registers. It is also quite common that moving data from a floating point register to a general purpose register requires going via the stack. On super scalar architectures this means that the basic input checks can often be done in parallel to the start of the range reduction etc. I'm not saying that libm should always use FP math. All I've been saying is that the code was written under certain assumptions and many of them haven't been valid for a long time. Joerg
Re: sin() implementation
On Wed, Sep 27, 2017 at 08:40:26AM +0200, Alexandre Ratchov wrote: > Even on modern amd64s integer arithmetics and bitwise operations are > faster (and more precise in many cases) than floating point > equivalents. Can you actually substanciate this claim? The basic x87 instructions (FLD, FST, FCOM etc) all run in one cycle with a latency of 2 according to Agner. That's generally not worth the cost of moving from x87 to GP registers. Precision might have been a problem two decades ago when many compilers were too bad at correct parsing of float literals, but that has been fixed in the mean time even without using C99 hex float literals. The short answer is that the original msun code has been optimized for a hardware environment that is substantially different from modern CPUs. Many of the small details are no longer optimal. Joerg
Re: Implement __cxa_thread_atexit
On Fri, Aug 11, 2017 at 04:31:44PM +0200, Mark Kettenis wrote: > The diff below implements __cxa_thread_atexit(). Calls to this > function are emitted by the compiler to schedule running desctructors > for thread_local objects when a thread terminates or calls exit(3). > The Linux implementation prevents unloading of shared libraries that > registered such destructors to prevent things from crashing. This > diff does not implement that functionality yet. I plan to add that > later. I expect this to be a bit of a corner case. Well, if you don't care that much about the corner case, you can directly use the generic fallback implementation in libc++abi. Preventing unloading is the least stupid of all options, the rest basically break one major promise or another. > I've chosen to implement __cxa_thread_atexit() directly instead of > __cxa_thread_atexit_impl(). I think that is cleaner. It means we > don't need to make changes to libc++ for this to start working. It > looks like modern libstdc++ version will detect __cxa_thread_atexit(). Which version did you look at? All cases I have seen check exclusively for *_impl(). That's why I settled down on making it the official interface in NetBSD and providing the more natural __cxa_thread_atexit only as weak alias. Joerg
Re: Fix libexec/ld.so/dlclose regress
On Wed, Aug 02, 2017 at 09:03:30PM +0200, Mark Kettenis wrote:
> Couldn't convince clang not to inline duplicateFun() into bbTest2().
> Splitting things out in a seperate file avoids the issue. Fixes the
> regression test.
Have you tried the combiniation of noinline attribute with
asm volatile("":::"memory")
as non-movable side effect?
Joerg
Re: clang ld.so regress failures
On Wed, Aug 02, 2017 at 12:09:13AM -0400, Ted Unangst wrote: > Mark Kettenis wrote: > > FAIL libexec/ld.so/dlclose/test1/prog3/prog3 > > > > This fails because clang doesn't respect ELF interposition: > > > > http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html > > > > We generally frown upon interposition so I can have some sympathy > > for their position here. Probably not a huge issue in practice. > > But we still want to test the ld.so functionality. > > would this affect, for example, a program's ability to override > malloc/free/etc? i'm trying to understand what's not working (or what will not > work). it sounds like i can override malloc in my program, but clang/llvm will > generate "tight" (not sure of the word) bindings to libc malloc within libc? > although this would probably only manifest within translation units with > inlining? Correct, functions in the same TU can be inlined, even when -fPIC is active. It primarily becomes a problem when using LTO, but I don't think you are that far :) Joerg
Re: clang ld.so regress failures
On Tue, Aug 01, 2017 at 04:46:17PM +0200, Mark Kettenis wrote: > FAIL libexec/ld.so/dlclose/test1/prog3/prog3 > > This fails because clang doesn't respect ELF interposition: > > http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html > > We generally frown upon interposition so I can have some sympathy > for their position here. Probably not a huge issue in practice. > But we still want to test the ld.so functionality. Mark bbLazyFun with attribute noinline? Maybe also add an explicitly memory clobber to it. _dl_debug_state in ld.so is likely only safe because it is not called from the same translation unit, but you might want to add the same there. > FAIL libexec/ld.so/constructor/prog1/prog1 > FAIL libexec/ld.so/constructor/prog2/prog2 > FAIL libexec/ld.so/initfirst/test2/prog1/prog1 > FAIL libexec/ld.so/initfirst/test2/prog2/prog2 > FAIL libexec/ld.so/init-env/prog/prog > > These fail because libc++ doesn't support using stdio in > constructors. Probably a bug: > > https://reviews.llvm.org/D12689 Not stdio, but standard streams. Small but important difference. Using printf and co should be fine here. Joerg
Re: Standard conformance of strtol(3)
On Thu, Jul 06, 2017 at 03:42:19PM +0200, Marc Espie wrote: > 7.20.1.4 (3) If the value of base is zero, the expected form of the subject > sequence is that of an integer constant *as described in 6.4.4.1*, optionally > preceded by a plus or minus sign but not including an integer suffix [...] > > 6.4.4.1 is a grammar > > > integer-constant: > [...] > hexadecimal-constant integer-suffix_opt You have skipped with [...] the part that actually matches "0". So yes, the ISO C grammar does require strtol and friends to handle "0xx" and similar as just "0". Joerg
Re: Make clang accept and use relative filenames for tools
On Mon, May 29, 2017 at 06:54:52PM +0100, Stuart Henderson wrote:
> On 2017/05/29 20:26, Vadim Zhukov wrote:
> > The clang and gcc behave differently regarding executing tools.
> > While gcc simply runs what he said to, clang tries to be clever
> > and always find absolute path for a tool, refusing start otherwise.
> >
> > The actual problem is starting a linker: ports infrastructure
> > expects tools are called by name, not by path, and thus could be
> > overriden via stuff in ${WRKDIR}/bin. This functionality is used,
> > e.g., to implement USE_WXNEEDED port option.
> >
> > But clang calls "/usr/bin/ld", not "ld", and thus ${WRKDIR}/bin/ld
> > misses a chance to do its magic, and binaries are built without
> > OPENBSD_WXNEEDED, and some ports blow up (when compiled using clang).
>
> One thing we _could_ do is pass -fuse-ld=${WRKDIR}/bin/ld when linking ..
Just -B ${WRKDIR}/bin should be enough and cover other tools like as as
needed.
Joerg
Re: clang: ignore -fno-force-addr
On Wed, Apr 19, 2017 at 10:30:43AM -0600, Todd C. Miller wrote: > In general, if -fdo-something is supported I think it should also > accept -fno-do-something. Since this was seen in the wild, patching > llvm makes the most sense. Bonus points if you can get it upstreamed. The positive forms of some harmless / useless GCC options are recognized if they are popular. It was never meant to be exhaustive and there is little motivation for adding to the list just because one person brilliantly decided to pick something from the GCC manual. I'd just drop the option -- it only exists in modern GCC for legacy compat as well. Joerg
Re: CFI directives support in binutils
On Mon, Apr 17, 2017 at 10:45:37PM +0200, Mark Kettenis wrote: > This diff extends the support for CFI in binutils with a few > directives emitted by clang. Most of the code is stolen from > FreeBSD's GPLv2 binutils. Support for the .cfi_sections directive is > incomplete; basically we just ignore it. Our binutils only support > emitting frame info in the .eh_frame section. Debuggers tend to fall > back on .eh_frame if .dwarf_frame is missing, so this shouldn't be a > problem. The primary difference is that you can't easily strip .eh_frame from a binary, so it adds overhead. > This diff is necessary to build/use clang on sparc64 as there > currently isn't an integrated assembler for the sparc64 target in > llvm. It exists, but it is missing parsing for a couple of tricky instructions. Given that some central headers on NetBSD use inline assembler with those, it never was very useful for me to enable IAS as default on sparc64. Joerg
Re: httpd/libtls: TLS client certificate revocation checking
On Sat, Apr 01, 2017 at 07:53:05PM +1030, Jack Burton wrote: > One common example of that happening is when a cert gets revoked because > its private key has been lost/stolen and the user needs a new cert > associated with the same identity. An even more common example is when > a cert expires & gets renewed. If you are using certificate revocation, I think you should do the check as early as possible. That means in httpd in this case. Nothing later in the stack should have to care about expired or revoked certificates -- it just adds complexity and the danger of someone forgetting about it. Which mechanisms to support (i.e. CRLs or OCSP) is a completely different topic. Joerg
Re: httpd/libtls: TLS client certificate revocation checking
On Fri, Mar 31, 2017 at 01:03:44PM -0700, William Ahern wrote: > Basically, anything short of passing through the entire certificate is going > to be severely limiting and frustrating, to the point of uselessness. Passing down the common name is normally enough, but not doing that makes it nearly useless. Speaking from the perspective of using them in the wild. Joerg
Re: SVM instructions
On Wed, Mar 15, 2017 at 09:05:56PM +0100, Mark Kettenis wrote: > Clang only accepts SVM instructions with explicit operands, for > example: > > vmload %rax You might want to look at the aliases e.g. for monitor/mwait. Should be pretty easy to extend as long as we are talkign about pure register operands. Memory operands would be more tricky. Joerg
Re: Linking userland with lld
On Sat, Jan 21, 2017 at 10:58:59AM +0100, Mark Kettenis wrote: > The problem here is that the code uses the SHA1 functions in > libcrypto, but doesn't explicitly link against that library. With our > ancient binutils we don't notice this, because we link against libtls, > which as a DT_NEEDED entry for libcrypto. But lld doesn't fall for > this. And I believe modern binutils don't do this either. Yes, GNU decided at some point that you are only supposed to use symbols from a library you also have a DT_NEEDED entry for. Of course, the dynamic linker doesn't know that, so the link time view doesn't necessarily reflect what the runtime linker is doing. I still have on my TODO list to fix lld, so that the behavior at least is optional. Joerg
Re: Build kernels with -ffreestanding?
On Sat, Dec 24, 2016 at 12:08:35AM +0100, Mark Kettenis wrote: > We can get those optimizations back by doing: > > #define memcpy(d, s, n) __builtin_memcpy((d), (s), (n)) You might still want to put a prototype in, just before the define. Joerg
Re: ld.so: -fno-builtin?
On Fri, Dec 23, 2016 at 11:27:15AM -0800, Philip Guenther wrote: > This is a form we use inside _libc_ so that calls to those functions > generated by gcc will be redirected to aliases with hidden visibility > and thus be local calls, without using the PLT. If that won't work > with clang, then we'll want to figure out some other way to get the > calls to those functions generated by the compiler to be local calls > inside libc. I'm not sure about all possible platforms, but for all I can think of, it is enough if the target is hidden. In that case ld should be using a direct jump/call to the destination without creating a PLT entry. Joerg
Re: ld.so: -fno-builtin?
On Fri, Dec 23, 2016 at 06:43:42PM +0100, Mark Kettenis wrote:
> > Date: Fri, 23 Dec 2016 18:13:45 +0100
> > From: Joerg Sonnenberger <jo...@bec.de>
> >
> > On Thu, Dec 22, 2016 at 10:35:25PM -0800, Philip Guenther wrote:
> > > I'm assuming clang handles asm names like gcc, such that declaring
> > >void *memcpy(void *__restrict, const void *__restrict, __size_t)
> > > __dso_hidden __asm("_dl_memcpy");
> > >
> > > will make even internally generated calls go to _dl_memcpy instead.
> >
> > No. The backend normally has no idea about assembler names. What problem
> > are you trying to solve, really?
>
> Right. The solution gere is probably to rename _dl_memcpy back to
> memcpy. One of the reasons why _dl_memcpy exists is that we wanted to
> prevent exporting ld.so's memcpy implementation such that nothing else
> would accidentally pick it up. But now that we explicitly control
> which symbols we export from ld.so, that risk doesn't exist anymore.
Correct. x86 is more forgiving here than others as it doesn't tend to
pull in anything from libgcc/compiler-rt/whatever, but the same issue
will exist e.g. for the division helper if you care about armv6 etc.
Joerg
Re: ld.so: -fno-builtin?
On Thu, Dec 22, 2016 at 10:35:25PM -0800, Philip Guenther wrote:
> I'm assuming clang handles asm names like gcc, such that declaring
>void *memcpy(void *__restrict, const void *__restrict, __size_t)
> __dso_hidden __asm("_dl_memcpy");
>
> will make even internally generated calls go to _dl_memcpy instead.
No. The backend normally has no idea about assembler names. What problem
are you trying to solve, really?
Joerg
Re: ld.so: -fno-builtin?
On Thu, Dec 22, 2016 at 05:47:05PM +0100, Christian Weisgerber wrote: > Building ld.so with clang on amd64 fails with undefined references > to memset and memcpy. That is odd, since neither function appears > in the source. Apparently clang optimizes the _dl_memset and > _dl_bcopy functions into calls to memset and memcpy, respectively. > > I tentatively propose to add -fno-builtin to fix this. > (Builds, runs, and passes regress with gcc on amd64 and i386.) You are lucky if it fixes the problem, infact, -fno-builtin has quite a chance to make the problem worse. Clang assumes the same set of basic functions to be present even for -ffreestanding environments and can lower e.g. initialisation of local variables to memset/memcpy. Joerg
Re: LLVM: use OpenBSD target code for AArch64
On Fri, Nov 25, 2016 at 12:37:10AM +0100, Patrick Wildt wrote: > This diff makes LLVM do all the OpenBSD stuff for AArch64. > > ok? If you plan to submit this upstream, you should also update the test cases accordingly. Joerg
Re: enforce zero options
On Wed, Oct 12, 2016 at 03:53:17PM +0200, Jan Stary wrote: > I don't get it: why do we need to handle -- > in utils which take no options and no arguments? Are you sure they will never handle options in the future? Joerg
Re: Modernize arm assembly in the kernel
On Wed, Sep 21, 2016 at 10:10:43AM +0200, Mark Kettenis wrote: > 1. In GNU as, .align 0 is equivalent to .align 2, but with clang's >internal assembler .align 0 means "no alignment". It might be even better to use .balign or .p2align. > 2. Using "ldr" to load a constant into a register is strange. It >works with GNU as, but not with clang. It should? See llvm/test/MC/ARM/ldr-pseudo.s. For small constants that fit into an immediate, the mov version is certainly smaller than going via the constant island, but the syntax should be correct. Joerg
Re: C startup code: make crtbegin code safe for clang
On Mon, Aug 01, 2016 at 07:28:34PM +0200, Stefan Kempf wrote: > The constructor and destructor tables are declared as arrays with one > non-NULL element. Walking those until a NULL element is reached looks > like out-of-bound accesses to newer compilers, and they turn the code > into infinite loops (e.g. clang 3.8), because it is undefined behavior. I don't think your code is safe for the more aggressive behavior esp. of newer GCC. Given how much fun I had recently on this, consider just using the NetBSD version of this code. Joerg
Re: exp.3: remove ancient history and some markup tweaks
On Mon, May 30, 2016 at 04:30:10PM +0200, Marc Espie wrote: > On Mon, May 30, 2016 at 03:34:04PM +0200, Joerg Sonnenberger wrote: > > On Mon, May 30, 2016 at 02:16:20PM +0200, Theo Buehler wrote: > > > It may be somewhat interesting to mention why expm1(x) = exp(x) - 1 and > > > log1p(x) = log(1 + x) are provided and what their historical purpose is. > > > However, as mlarkin@ put it: are any of our users of exp(3) going to > > > seriously be asking themselves "hmm, is OpenBSD's exp compatible with > > > BASIC on the HP-71B?" > > > > The wording change also changes the semantics quite a bit. The old > > wording explained where the name came from and what the function does. > > The new wording implies somewhat that the functions are obsolete, which > > is far from true. > > Huh ? > "computes the value ... accurately even for tiny arguments". > > That's quite enough as far as a function description goes. Look at the changed NOTES section. The rest is fine. Joerg
Re: exp.3: remove ancient history and some markup tweaks
On Mon, May 30, 2016 at 02:16:20PM +0200, Theo Buehler wrote: > It may be somewhat interesting to mention why expm1(x) = exp(x) - 1 and > log1p(x) = log(1 + x) are provided and what their historical purpose is. > However, as mlarkin@ put it: are any of our users of exp(3) going to > seriously be asking themselves "hmm, is OpenBSD's exp compatible with > BASIC on the HP-71B?" The wording change also changes the semantics quite a bit. The old wording explained where the name came from and what the function does. The new wording implies somewhat that the functions are obsolete, which is far from true. Joerg
Re: siginfo_t.si_addr should be void*
On Wed, Apr 27, 2016 at 06:04:32PM -0400, i80...@foxquill.com wrote:
> POSIX specifies that siginfo_t.si_addr must be void*. OpenBSD currently
> defines it as caddr_t. This breaks some userspace programs, such as the
> following minimal case:
This
> The following patch builds the base system cleanly on x86_64, and
> resolves the problem.
>
> diff --git a/src/sys/sys/siginfo.h b/src/sys/sys/siginfo.h
> index 814e8f2..1e8365f 100644
> --- a/src/sys/sys/siginfo.h
> +++ b/src/sys/sys/siginfo.h
> @@ -150,7 +150,7 @@ typedef struct {
> } _pdata;
> } _proc;
> struct {/* SIGSEGV, SIGBUS, SIGILL and SIGFPE */
> - caddr_t _addr; /* faulting address */
> + char*_addr; /* faulting address */
> int _trapno;/* illegal trap number */
> } _fault;
> #if 0
and this disagree?
Joerg
Re: Overflowable int -> size_t in grep
On Mon, Dec 07, 2015 at 02:32:50AM -0500, Michael McConville wrote: > Otto Moerbeek wrote: > > On Mon, Dec 07, 2015 at 01:36:22AM -0500, Michael McConville wrote: > > > This isn't a grave issue, but I came across it while exploring integer > > > overflow and think it's worth sharing. > > > > > > grep represents line numbers with an int, which predictably overflows > > > for inputs with >= 2^31 newlines. This is easy to demonstrate using the > > > -n option and a debugging printf. > > > > > > The below diff fixes this, and tunes up a for loop while I'm in there. > > > > how does this fix work on 32-bit platforms? Better use offset_t. > > Good catch, thanks. > > Does this look better? Or is PRId64 preferred for off_t? Neither is correct, off_t should be cast to intmax_t first and then %jd be used. Joerg
Re: unify xmalloc (was Re: [patch] cvs: retire xfree())
On Sun, Nov 08, 2015 at 08:36:52AM +, Nicholas Marriott wrote: > On Sat, Nov 07, 2015 at 08:42:14PM -0500, Ted Unangst wrote: > > Tobias Stoeckmann wrote: > > > Is this okay for ssh and tmux, which are out to be very portable? > > > Nicholas mentioned that malloc is not required to set errno. I've also > > > checked the standard and it's just an extension. Although at worst, > > > the user sees a wrong error message... > > > > Are they portable to not-posix? posix dictates that malloc set errno. > > It is optional in SUSv3: > > RETURN VALUE > > Upon successful completion with size not equal to 0, malloc() shall > return a pointer to the allocated space. If size is 0, either > a null pointer or a unique pointer that can be successfully > passed to free() shall be returned. Otherwise, it shall return > a null pointer ^[CX] [Option Start] and set errno to indicate > the error. [Option End] Not really, that just means that the "and set errno" part is not included in ISO C itself. The markup is a bit confusing, but CX is not an option in the "pick it or not sense". Joerg
Re: __progname in base
On Sat, Nov 07, 2015 at 12:20:42PM +0100, Tobias Stoeckmann wrote:
> Index: bin/mt/mt.c
> ===
> RCS file: /cvs/src/bin/mt/mt.c,v
> retrieving revision 1.36
> diff -u -p -u -p -r1.36 mt.c
> --- bin/mt/mt.c 12 Nov 2013 04:36:02 - 1.36
> +++ bin/mt/mt.c 7 Nov 2015 11:16:25 -
> @@ -88,6 +88,8 @@ int _rmtmtioctop(int fd, struct mtop *c
> struct mtget *_rmtstatus(int fd);
> void _rmtclose(void);
>
> +extern char *__progname;
> +
> char *host = NULL; /* remote host (if any) */
>
> int
> @@ -133,7 +135,6 @@ _rmtclose(void)
> #endif
> }
>
> -char *progname;
> int eject = 0;
>
> int
> @@ -145,12 +146,7 @@ main(int argc, char *argv[])
> char *p, *tape, *realtape, *opts;
> size_t len;
>
> - if ((progname = strrchr(argv[0], '/')))
> - progname++;
> - else
> - progname = argv[0];
> -
> - if (strcmp(progname, "eject") == 0) {
> + if (strcmp(__progname, "eject") == 0) {
> opts = "t";
> eject = 1;
> tape = NULL;
As Ingo recently reminded me, OpenBSD actually did add getprogname() at
some point, which needs need a actually manual forward definition.
Joerg
Re: __progname in base
On Sat, Nov 07, 2015 at 03:32:11PM +0100, Joerg Sonnenberger wrote: > As Ingo recently reminded me, OpenBSD actually did add getprogname() at > some point, which needs need a actually manual forward definition. Too early for writing. It does *not* need such an ugly manual extern declaration. Joerg
Re: [patch] cat's main never return
On Sun, Aug 30, 2015 at 12:10:03AM +0200, Fritjof Bornebusch wrote: If exit(3) is always called, than why not changing the return value to *void*? Because ISO C says that in non-freestanding environment, main should retutrn int. Joerg
Re: kern_tame.c: fix strncmp call
On Sun, Aug 23, 2015 at 03:29:46PM -0700, patrick keshishian wrote:
On 8/23/15, Caspar Schutijser cas...@schutijser.com wrote:
Patch below.
Thanks,
Caspar Schutijser
Index: sys/kern/kern_tame.c
===
RCS file: /cvs/src/sys/kern/kern_tame.c,v
retrieving revision 1.25
diff -u -p -r1.25 kern_tame.c
--- sys/kern/kern_tame.c23 Aug 2015 19:32:20 - 1.25
+++ sys/kern/kern_tame.c23 Aug 2015 21:22:38 -
@@ -423,7 +423,7 @@ tame_namei(struct proc *p, char *origpat
*/
if ((p-p_p-ps_tame _TM_TMPPATH)
(p-p_tame_syscall == SYS_unlink)
- strncmp(path, /tmp/, sizeof(/tmp) - 1) == 0) {
+ strncmp(path, /tmp/, sizeof(/tmp/) - 1) == 0) {
you are confusing sizeof() with strlen(). former counts the byte
required for the terminating NUL.
I don't think the OP is. If you want to check that path starts with
/tmp/, you need to check the first 5 characters. The original code
only checks the first 4. As such, it will also match /tmpfile.
Joerg
Re: qsort.3 big O notation
On Tue, Mar 03, 2015 at 05:02:39PM +0100, frantisek holop wrote: i leave the battle about lg vs log to others, but i prefer 'log' as there is a man page for that and there is none for 'lg'... If anything, it should be log because that is the name of the mathematical function. libm is completely irrelevant in this context. Joerg
Re: ntpd: prefer %z when formatting size_t
On Mon, Feb 09, 2015 at 10:32:55PM -0600, Brent Cook wrote: Pretty trivial conversion. ok? Well, if it is size_t, it should be %zu. Joerg
Re: [PATCH] update zlib to 1.2.8
On Tue, Dec 23, 2014 at 10:54:15PM +0200, Timo Myyrä wrote: I was trying to port notmuch mail indexer but got little stuck with it as it requires newer Zlib version than whats in base. It is easy to patch notmuch, the requirement is rather silly. FYI. Joerg
Re: switch /usr/bin/cpp to tradcpp
On Sat, Aug 09, 2014 at 11:37:02PM +1000, Jonathan Gray wrote: clang only has an integrated preprocessor and does not have a standalone preprocessor or the option of using one. Huh? clang-cpp will certainly act as standalone preprocessor. Joerg
Re: switch /usr/bin/cpp to tradcpp
On Sun, Aug 10, 2014 at 12:29:24AM +1000, Jonathan Gray wrote: On Sat, Aug 09, 2014 at 04:17:51PM +0200, Joerg Sonnenberger wrote: On Sat, Aug 09, 2014 at 11:37:02PM +1000, Jonathan Gray wrote: clang only has an integrated preprocessor and does not have a standalone preprocessor or the option of using one. Huh? clang-cpp will certainly act as standalone preprocessor. Well clang-cpp is just a different driver for clang which unless something has changed recently doesn't implement traditional cpp semantics? It also doesn't seem to be built usually. The lack of traditional is what I meant to say above. There is no separate binary, just a possible symlink. Traditional CPP support is very, very limited, essentially to what is needed for processing asm. That is quite a different question from a standalone cpp mode. Joerg
Re: [PATCH 2/7] fix type string conversion warning
On Mon, Jun 02, 2014 at 12:33:14PM -0400, Ted Unangst wrote: What compiler warns about this? It's perfectly fine to pass a nonconst string to a function that takes a const string. char * vs unsigned char *? Joerg
Re: LLVM warning in dev/ic/uhci.c
On Wed, Dec 04, 2013 at 12:24:50PM +0100, Mark Kettenis wrote: Sorry, but I disagree with LLVM here. It shouldn't complain about static inline functions. Then mark them as unused, just like you would with a static variable you insist on keeping. Joerg
Re: Weard security report
On Wed, Nov 06, 2013 at 10:24:53AM -0500, sven falempin wrote: == /var/db/cloud.json diffs (-OLD +NEW) == --- /dev/null Fri Oct 25 01:30:33 2013 +++ /var/db/cloud.json Thu Oct 17 17:21:15 2013 This just means that the file was created as opposed to empty. Joerg
Re: ksh global PWD env variable
On Sun, Jul 21, 2013 at 10:01:33PM +0200, Alexander Hall wrote: I for one don't see a general interest in knowing ones parents potentially faked wd. You can find out your wd by saner means. There is no way to find the logical path without help from the shell. Joerg
Re: rm(1) static addition
On Sat, Apr 27, 2013 at 09:09:25PM +0200, Franco Fichtner wrote: On backtrace(3) (which is a GNU thing, I know), static functions don't show up with their respective names even though they are in the binary. That's a tad annoying, but I am not aware of any other limitation. Can someone please enlighten me? That's not true in general. backtrace(3) or any other user of the .eh_frame section for unwinding won't see individual records for inlined functions. Static functions are more likely to get inlined, but the same can happen with non-inline functions defined in the same file. Joerg
Re: fun with libtool for masochistic guys
On Thu, Jul 12, 2012 at 12:33:18AM +0200, Marc Espie wrote: On Wed, Jul 11, 2012 at 11:24:37PM +0200, Joerg Sonnenberger wrote: On Wed, Jul 11, 2012 at 03:13:19PM +0200, Marc Espie wrote: On Wed, Jul 11, 2012 at 01:08:43PM +0200, Joerg Sonnenberger wrote: On Wed, Jul 11, 2012 at 10:57:21AM +0200, Marc Espie wrote: 1/ Turns out GNU libtool simply *removes* stuff it doesn't understand while linking. I find that no more buggy than GCC passing all unknown junk to ld... Joerg Is that a joke ? 'cause I can't tell. Nope, I'm pretty serious. Sure enough, either behavior sucks... You should get your priorities straight ! occasionnally, gcc behavior can be a bit annoying, but it's never ever a silent bug ! There is a difference e.g. between using -static and -Wl,-static. Depending on which combination of gcc and ld you are using, that can result in pretty obnoxious bugs too. Joerg
Re: fun with libtool for masochistic guys
On Wed, Jul 11, 2012 at 10:57:21AM +0200, Marc Espie wrote: 1/ Turns out GNU libtool simply *removes* stuff it doesn't understand while linking. I find that no more buggy than GCC passing all unknown junk to ld... Joerg
Re: fun with libtool for masochistic guys
On Wed, Jul 11, 2012 at 03:13:19PM +0200, Marc Espie wrote: On Wed, Jul 11, 2012 at 01:08:43PM +0200, Joerg Sonnenberger wrote: On Wed, Jul 11, 2012 at 10:57:21AM +0200, Marc Espie wrote: 1/ Turns out GNU libtool simply *removes* stuff it doesn't understand while linking. I find that no more buggy than GCC passing all unknown junk to ld... Joerg Is that a joke ? 'cause I can't tell. Nope, I'm pretty serious. Sure enough, either behavior sucks... Joerg
Re: cron: fix incorrect error message
On Tue, May 08, 2012 at 06:19:55PM +0200, Thomas Pfaff wrote: On Tue, 8 May 2012 09:55:53 -0400 Okan Demirmen o...@demirmen.com wrote: Not really a pasto; from putenv(): P = (char **)realloc(lastenv, sizeof(char *) * (cnt + 2)); *puke* Ok? If you want to drop the first cast, you might want to spell it sizeof(*P) as well... Joerg
Re: escape man(1) arguments from glob(3)
On Sun, Nov 20, 2011 at 12:57:40PM +0100, Ingo Schwarze wrote: Hi Joerg, Joerg Sonnenberger wrote on Sun, Nov 20, 2011 at 06:00:16AM +0100: On Sun, Nov 20, 2011 at 02:27:39AM +0100, Ingo Schwarze wrote: Or we need the patch below. It looks a bit messy, but i think it is safe. Invert the logic. Check with strcspn first, if there is a character that needs quoting. This is not the default case after all. If you do, allocate escpage, quote to it and reassign page. Otherwise, just set escpage to NULL. That seemed better at first, but actually, it isn't. In case there are no characters to escape, my code is O(N*M), where N is the length of the name and M is the number of metacharacters. The strcspn function is O(N*M) as well. Besides, M is constant and N is small in all relevant cases, so the difference is a constant times a small effort at worst. Even if there is a speed difference due to economizing N function calls to strchr and one function call to malloc, that is not going to matter in view of the rest of the code. Fix your inefficent strcspn implementation in that case. It's a classic O(N+M) algorithm. My main point is that you require changes all over the place, including copying the string to handle a rare case. With the inverted logic, you do a single pass over the input string for almost all arguments are done. Joerg
Re: escape man(1) arguments from glob(3)
On Sun, Nov 20, 2011 at 02:27:39AM +0100, Ingo Schwarze wrote: Or we need the patch below. It looks a bit messy, but i think it is safe. Thoughts, OKs? Invert the logic. Check with strcspn first, if there is a character that needs quoting. This is not the default case after all. If you do, allocate escpage, quote to it and reassign page. Otherwise, just set escpage to NULL. Joerg
Re: mmap diff for patch(1)
On Fri, Nov 11, 2011 at 10:20:19AM +0100, Otto Moerbeek wrote: On Fri, Nov 11, 2011 at 03:04:28PM +0800, Michael W. Bombardieri wrote: Sorry, let me try that again... Forgot to clean up file descriptor ifd. AFAIK, this works without this diff. What problem are you trying to solve? Some systems reject mmap with size 0. That's what the original chance was all about. Joerg
Re: compat linux pipe2() circus
On Tue, Sep 20, 2011 at 01:41:35AM +0300, Paul Irofti wrote: This time its their pipe2 system call which adds flags to the pipe call. Its the unix-ish way apparently to turn pipes into files on a kernel filesystem, or so they claim. No, the idea is to make it possible to set O_CLOEXEC atomically. Of course, the pipe2 system call as implemented in Linux is kind of messed up, since the flag attribute applies to both sides of the pipe. The use cases of pipes that don't involve exec are limited (using pipes to terminate poll/select loops from signal handles, communication between a fork'd hord of children), so I am kind of waiting for pipe3 to appear... Joerg
Re: wcsdup
On Tue, Jul 05, 2011 at 01:52:06PM -0400, Todd C. Miller wrote:
if ((p = wcsdup(Lfoobar)) == NULL) {
or just split it into two lines. Using the comma operator that way
is correct but likely to confuse some readers. Also, what is that
'L' doing there before the foobar? Is it some sort of wide char
thing I'm not aware of?
Wide character string literal, yes.
Joerg
Simplified RCS keyword expansion
Hi all,
below is a possible replacement for rcs.c's rcs_expand_keywords.
Since my use case doesn't care about time zones, the rcs_set_tz is
missing, but otherwise it should work without further changes.
The memrchr might need to be replaced with an inline loop, but that's
one of the few saner GNU extensions recently...
Most importantly, this actually has a readable version of the $Log$
handling.
Joerg
#if 0
static const struct rcs_kw rcs_expkw[] = {
...
{ Locker, RCS_KW_LOCKER },
};
#endif
static void
buf_puts(BUF *b, const char *str)
{
buf_append(b, str, strlen(str));
}
static BUF *
rcs_expand_keywords(char *rcsfile, struct rcs_delta *rdp, BUF *bp, int mode)
{
BUF *newbuf;
u_char *c, *kw, *fin;
char buf[256];
u_char *line, *line2;
u_int i, j;
int kwtype;
int found;
newbuf = buf_alloc(buf_len(bp));
/*
* Keyword formats:
* $Keyword$
* $Keyword: value$
*/
c = buf_get(bp);
fin = c + buf_len(bp);
/* Copying to newbuf is deferred until the first keyword. */
found = 0;
while (c fin) {
kw = memchr(c, '$', fin - c);
if (kw == NULL)
break;
++kw;
if (found) {
/* Copy everything up to and including the $ */
buf_append(newbuf, c, kw - c);
}
c = kw;
/* c points after the $ now */
if (c == fin)
break;
if (!isalpha(*c)) /* All valid keywords start with a letter */
continue;
for (i = 0; i RCS_NKWORDS; ++i) {
size_t kwlen;
kwlen = strlen(rcs_expkw[i].kw_str);
/*
* kwlen must be less than clen since clen
* includes either a terminating `$' or a `:'.
*/
if (c + kwlen fin
memcmp(c , rcs_expkw[i].kw_str, kwlen) == 0
(c[kwlen] == '$' || c[kwlen] == ':')) {
c += kwlen;
break;
}
}
if (i == RCS_NKWORDS)
continue;
kwtype = rcs_expkw[i].kw_type;
/*
* if the next character is ':' we need to look for
* an '$' before the end of the line to be sure it is
* in fact a keyword.
*/
if (*c == ':') {
for (; c fin; ++c) {
if (*c == '$' || *c == '\n')
break;
}
if (*c != '$') {
if (found)
buf_append(newbuf, kw, c - kw);
continue;
}
}
++c;
if (!found) {
found = 1;
/* Copy everything up to and including the $ */
buf_append(newbuf, buf_get(bp), kw - buf_get(bp));
}
if (mode RCS_KWEXP_NAME) {
buf_puts(newbuf, rcs_expkw[i].kw_str);
if (mode RCS_KWEXP_VAL)
buf_puts(newbuf, : );
}
/* Order matters because of RCS_KW_ID and RCS_KW_HEADER. */
if (mode RCS_KWEXP_VAL) {
if (kwtype RCS_KW_RCSFILE) {
char *tmpf;
if ((kwtype RCS_KW_FULLPATH) ||
(tmpf = strrchr(rcsfile, '/')) == NULL)
buf_puts(newbuf, rcsfile);
else
buf_puts(newbuf, tmpf + 1);
buf_putc(newbuf, ' ');
}
if (kwtype RCS_KW_REVISION) {
rcsnum_tostr(rdp-rd_num, buf, sizeof(buf));
buf_puts(newbuf, buf);
buf_putc(newbuf, ' ');
}
if (kwtype RCS_KW_DATE) {
strftime(buf, sizeof(buf),
%Y/%m/%d %H:%M:%S , rdp-rd_date);
buf_puts(newbuf, buf);
}
if (kwtype RCS_KW_AUTHOR) {
buf_puts(newbuf, rdp-rd_author);
buf_putc(newbuf, ' ');
Re: namespace.h
On Tue, Apr 19, 2011 at 11:15:49PM -0500, Amit Kulkarni wrote: where is a listing of all functions implemented in openbsd's libc? Is src/lib/libc/include/namespace.h consist of functions not implemented or its a relic? namespace.h is used for protecting the libc namespace. A library may overwrite many of the libc entry points and the header is used to prevent that. It is not a full enumeration of the functions implemented in libc. Joerg
Re: Compiling the kernel with pcc
On Tue, Apr 05, 2011 at 11:09:14AM +0200, Pascal Stumpf wrote: Ok, I seem to have misread the standard there, sorry. Anyway, I've done some tests with all three compilers, and gotten three different behaviours: Can you please say explicitly which GCC version you are talking about? The behavior changed with 4.3 to follow the C99 semantic by default, which in turn is what clang and PCC should be implementing. Joerg
Re: http gzip support for ftp
On Fri, Jan 14, 2011 at 06:08:54PM +0100, Marc Espie wrote: On Sun, Jan 09, 2011 at 04:21:51PM -0500, Ted Unangst wrote: Downloading things can go a lot faster if the server and client support http compression. This is easily added to the ftp program's http support. It consists of two parts. Support for deflating the data we receive and support for the chunked transfer the server will use to send data to us. The chunked supported is probably useful in its own right as well. How does it work if you use http to transfer already compressed files ? Does it need special intelligence to avoid compressing things again ? It just asks the server that it may compress the content. The server logic is normally either MIME type specific or configured to exclude certain extensions. Joerg
Re: nc -U -u (Unix datagram socket support)
On Fri, Jan 07, 2011 at 01:32:27PM -0700, Theo de Raadt wrote: I think it is important that people who do use mktemp(3) realize that they must loop over failure (creating a new path each time), and they need to use a do not use the path from elsewhere unless the code that opens it returns success paradigm. mktemp(3) just provides a potentially unique name; the expected gaurantees must be supplied by the caller. It is also important that the caller provides enough XXX to actually have a chance to finish the loop against a motivated concurrent user, especially when using something like /tmp. Joerg
Re: Adding support for Camellia on OpenSSH.
On Mon, Jul 19, 2010 at 09:02:35PM -0400, Ted Unangst wrote: On Mon, Jul 19, 2010 at 8:22 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jul 19, 2010 at 06:37:21PM -0400, STeve Andre' wrote: On Monday 19 July 2010 18:26:15 Ted Unangst wrote: Free software you can't modify is not free software. Algorithm != implementation (== software). That's especially galling for software where there are real security considerations: suppose you find a flaw in the algorithm--you can't fix it? You mean like Debian fixed the usage of uninitialized variables in OpenSSL? In the cryptographic community the need to fix an algorithm is generally considered a good sign to stay away from the algorithm completely. Can you name a case where an algorithm was fixed and the result was actually a stronger algorithm? Avoiding weak keys for example is not a modification of an algorithm, it is just a more specific choice of choosing random keys. I am talking about actually modifying the encryption algorithm. Side note: the complain is also pointless because a modified algorithm wouldn't be interoperable anyway, making the point mood as well. Bullshit. If blowfish had come with such retarded no-modification terms, we wouldn't have the bcrypt password hashing scheme we use today. And where excatly does bcrypt modify the Blowfish algorithm? Of course, it greatly helps to prove your point that the description of the algorithm in the source is generic for any ECB algorithm... Joerg
Re: socket buffers
On Sat, Jul 03, 2010 at 11:54:17AM +0100, Stuart Henderson wrote: Does anyone know offhand the reason why network connections fail if socket buffers are set above 256k? You might have to patch sb_max for that. Joerg
Re: socket buffers
On Sat, Jul 03, 2010 at 05:40:45PM +0200, Claudio Jeker wrote: 35M, that is insane. Either they have machines with infinite memory or you can kill the boxes easily. You don't need 35MB per client connection if interfaces like sendfile(2) are used. All the kernel has to guarantee in that case is copy-on-write for the file content as far as it has been send already. Media distribution server normally don't change files inplace, so the only backpressure this creates is on the VFS cache. Let's assume the server is busy due to a new OpenBSD/Linux/Firefox/whatever release. A lot of clients will try to fetch a small number of distinct files. The memory the kernel has to commit is limited by the size of that active set, not by the number of clients. Joerg
Re: Bug in gcc 3?
On Tue, Jun 01, 2010 at 09:14:53PM +0200, Tim van der Molen wrote: Would this be a bug in gcc or am I overlooking something? == has a higher precendence than += and therefore binds stronger. See operator(7). Joerg
Re: #include sys/types.h in sys/mman.h
On Wed, Feb 24, 2010 at 05:38:14PM -0700, Theo de Raadt wrote: On Wednesday 24 February 2010 15:57:43 Ingo Schwarze wrote: In OpenBSD, we usually include headers in other headers if that is required by a relevant standard, in particular by POSIX. I don't know where you get this idea from. Theo has made it pretty clear in the past that what you said above is not true. Read the man pages. No kidding... if you go and include everything everywhere, and then those headers include themselves too, and some of them recurse even deeper, pretty soon you are pushing half a megabyte of stuff into ccp which still has to find the lines which start with #, and do all that extra IO. It might be surprising, but for any semi-modern version of GCC applying the patch and compiling #include sys/types.h #include sys/mman.h doesn't result in significant IO change compared to the unpatched version. The compiler is smart enough to recognise the normal include guard style and won't touch the file again. So please, don't justify breaking POSIX compliant code by reducing IO. That said, sys/types.h is most likely not what is needed to make sys/mman.h self-contained, but that's a completely separate issue. Joerg
Re: #include sys/types.h in sys/mman.h
On Wed, Feb 24, 2010 at 07:56:27PM -0700, Theo de Raadt wrote: http://www.opengroup.org/onlinepubs/9699919799/ And this is exactly the problem with POSIX. When was that change made? It is the same kind of requirement as ISO C99 has for size_t. The primary header for size_t is stddef.h, but a number of other headers are supposed to provide it as well (like stdlib.h) to be standalone. When was it changed? No idea, the same requirement can be found in SUSv2 (aka UNIX98). Who was asked about it? The Austin Group? Whoever else is part of the necessary ISO/IEC committies? How much backwards compatibility did they break? I'm failing to see what compatibility was broken here... The whole process is run by the same people who refuse to put strlcpy and strlcat into Linux. Given that Linux was pretty much irrelevant at the time... Unfortunately POSIX is a joke. No comment. Joerg
Re: If you are one of the cool kids who cranks kern.bufcachepercent up..
On Sat, Jan 09, 2010 at 02:41:02PM -0800, Philip Guenther wrote: I find your lack of faith in the compiler disturbing. I find your lack of type checking before trolling disturbing. stares at the code Ummm, what? AFAICT, the only difference between the two variants that I can see is that the shift version might behave differently if numvnodes is negative, which can't happen. Can you be less funny and more clear about what type checking issue you see? You have analysed the situation correctly. The problem is that the compiler does not know that the signed numvnodes is never negative, so it creates different code. E.g. on AMD64 it is 6 instructions for the signed division by 2 compared to one instruction for the explicit shift or the unsigned division. Joerg
Re: kernel hacking
On Thu, Dec 10, 2009 at 08:54:30PM +0100, Thomas Pfaff wrote: A few books on this topic in general worth mentioning is Modern Operating Systems by Tanenbaum, Operating Systems: Design and Implementation. The latter one details the MINIX system, though. Modern Operating Systems is mostly of historic value -- the modern is relative to the state of the art of the 1970, early 1980. Joerg
Re: too many cpus
On Mon, Dec 07, 2009 at 12:50:33AM -0500, Ted Unangst wrote: Fortunately, help is on the way. Patch below combines all cpu states into a single line, for that classic top look even on the most impressive of modern hardware. Upstream top (and the version e.g. on Linux, NetBSD etc) use 1 for this, both as command line option and key. Joerg
