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
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
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, "&mmap");
>> +goto err;
>> +}
>> +if ((cp2 = mmap(NULL,
Ingo Schwarze wrote:
> + if ((cp1 = mmap(NULL, sb1.st_size, PROT_READ, MAP_PRIVATE,
> + fd1, 0)) == NULL) {
> + say(MANDOC_DB, "&mmap");
> + goto err;
> + }
> + if ((cp2 = mmap(NULL, sb2.st_size, PROT_READ, MAP_PRIVATE,
> + fd2, 0)) == NULL) {
> +
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 seems that if the logic
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 f
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
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 -- is unfortunately ve
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 do
"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
[now I'm subscribed, might as well respond to some recent stuff from the
archives...]
321.geo...@gmail.com wrote:
> 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 furt
11 matches
Mail list logo
