Re: Query regarding exec in mandocdb.c

Ted Unangst wrote: > Ingo Schwarze wrote: > > > this could just be memcmp. > > > > I avoided that over quibbles about the argument type (off_t vs. > > size_t), though i admit that database files larger than a Gigabyte > > make no sense at all. > > > > If you consider that an improvement, i'm not

Re: Query regarding exec in mandocdb.c

Ingo Schwarze wrote: > > this could just be memcmp. > > I avoided that over quibbles about the argument type (off_t vs. > size_t), though i admit that database files larger than a Gigabyte > make no sense at all. > > If you consider that an improvement, i'm not opposed to using > memcmp(3). But

Re: Query regarding exec in mandocdb.c

Hi Ted, Ted Unangst wrote on Sat, Aug 26, 2017 at 02:35:01PM -0400: > Ingo Schwarze wrote: >> +if ((cp1 = mmap(NULL, sb1.st_size, PROT_READ, MAP_PRIVATE, >> +fd1, 0)) == NULL) { >> +say(MANDOC_DB, ""); >> +goto err; >> +} >> +if ((cp2 = mmap(NULL,

Re: Query regarding exec in mandocdb.c

Ingo Schwarze wrote: > + if ((cp1 = mmap(NULL, sb1.st_size, PROT_READ, MAP_PRIVATE, > + fd1, 0)) == NULL) { > + say(MANDOC_DB, ""); > + goto err; > + } > + if ((cp2 = mmap(NULL, sb2.st_size, PROT_READ, MAP_PRIVATE, > + fd2, 0)) == NULL) { > +

Re: Query regarding exec in mandocdb.c

Thank you for the replies Ingo and the diffs! George Brown On 26 August 2017 at 17:04, Ingo Schwarze wrote: > Hi George, > > George Brown wrote on Thu, Aug 24, 2017 at 02:01:05PM +0100: > >> In mandocdb.c it appears cmp(1) and rm(1) are executed in a child >> process. It

Re: Query regarding exec in mandocdb.c

Hi George, George Brown wrote on Thu, Aug 24, 2017 at 02:01:05PM +0100: > In mandocdb.c it appears cmp(1) and rm(1) are executed in a child > process. It seems that if the logic from these programs were duplicated > the pledge in mandocdb.c could be further restricted and even not bother > with

re: code duplication

Hi, dera...@openbsd.org wrote: > Then please demonstrate your sensitivity by stopping use of the > OpenBSD project's mailing lists. Oh? Who's the thin-skinned one, now? > Obviously what I'm saying isn't a personal insult. I didn't even know his name, still don't know his e-mail addr, and

Re: re: code duplication

> > P.S. > > There is no good reason to insult Todd > > I don't know him, I might've heard of him once. Needless to say, the > insult obviously wasn't personal. > > > for running spamd(8), which > > is a standard tool and less annoying than some others. > > How do you find 'Hello, spam sender.

re: code duplication

Hi, schwa...@usta.de wrote: > there isn't the one answer that fits all situations. > > The goal in this respect is simplicity and maintainability. Yup. > Often, it is simpler to maintain two copies of similar code. > For example, the libc and kernel implementations of malloc(3) > and malloc(9)

Re: code duplication

Hi, there isn't the one answer that fits all situations. The goal in this respect is simplicity and maintainability. Often, it is simpler to maintain two copies of similar code. For example, the libc and kernel implementations of malloc(3) and malloc(9) are distinct. Reacharound between kernel

Re: Query regarding exec in mandocdb.c

Hi George, George Brown wrote on Thu, Aug 24, 2017 at 02:01:05PM +0100: > In mandocdb.c it appears cmp(1) and rm(1) are executed in a child > process. Indeed, i never really liked that, yet i didn't spend much time thinking about it either. > It seems that if the logic from these programs were

Re: Dumb question about updating snapshots

On 2017/08/26 07:27, Jordon wrote: > > > On Aug 26, 2017, at 4:14 AM, Stuart Henderson wrote: > > > > On 2017-08-26, Bryan Linton wrote: > >> On 2017-08-25 13:09:14, Jordon wrote: > >>> I’ve been running snapshots on my machine

Re: Dumb question about updating snapshots

> On Aug 26, 2017, at 4:14 AM, Stuart Henderson wrote: > > On 2017-08-26, Bryan Linton wrote: >> On 2017-08-25 13:09:14, Jordon wrote: >>> I’ve been running snapshots on my machine for a while now. About once or >>> twice a week

RE: code duplication

Hi, rauldmil...@gmail.com wrote: > On Sat, Aug 26, 2017 at 4:36 AM, wrote: >> The greater the body of code is, the smaller our understanding, or at >> least our ability to grok the code. >> >> Even in the UNIX world, 'duckspeak' code -- just doing what seems right >> without

FU: RE: code duplication

Sorry for the tyop in the subject line, boy will I be glad to get rid of this $#@$%&! webmail poop that doesn't know how to send a proper reply... Of course, to add insult to injury, I can't manually send the messages either, as the openbsd.org mail swerver decides, on connection, that I'm

Re: MediaTek Mt7601

On Fri, Aug 25, 2017 at 01:57:46PM -0700, Heppler, J. Scott wrote: > The wikidevi entry suggests that this may be low-hanging fruit to > add to OpenBSD/FreeBSD/NetBSD. The question I have is whether to give > the MediaTek away and try to purchase on older RealTek or be patient and > wait a few

Re: code replication (was: Re: Query regarding exec in mandocdb.c)

On Sat, Aug 26, 2017 at 4:36 AM, wrote: > The greater the body of code is, the smaller our understanding, or at > least our ability to grok the code. > > Even in the UNIX world, 'duckspeak' code -- just doing what seems right > without realizing the longer-term implications --

Re: Dumb question about updating snapshots

On 2017-08-26, Bryan Linton wrote: > On 2017-08-25 13:09:14, Jordon wrote: >> I’ve been running snapshots on my machine for a while now. About once or >> twice a week I will interrupt the boot with ‘bsd.rd’ and run through the ‘U’ >> process to get the

code replication (was: Re: Query regarding exec in mandocdb.c)

Hi, rauldmil...@gmail.com wrote: > But replication also gives robustness in the face of failure, so it > can also be a security asset. Still an issue, just not a security > problem. (Or, a problem, but for people trying to defeat security.) Yes, but especially in cases of untested, new ways of

Re: Query regarding exec in mandocdb.c

"Replicated similar functionality" is indeed a security issue. It's a security problem, sometimes - the whole buffer overflow being replicated everywhere thing, for example. But replication also gives robustness in the face of failure, so it can also be a security asset. Still an issue, just not