: a system out of swap, it is fairly easy to do whether the system
: uses an overcommit model or not. The user has any number of
: ways of blowing the server up too - for example, by making
: thousands of connections to it or running many huge queries in
: parallel.
:
:If the
On Tue, 13 Jul 1999 15:12:14 -0700 (PDT)
Matthew Dillon dil...@apollo.backplane.com wrote:
The text size of a program is irrelevant, because swap is never
allocated for it. The data and BSS are only relevant when they
are modified.
Bzzt. BSS is relevant when accessed (at
:Jason Thorpe wrote:
:
: On Tue, 13 Jul 1999 14:14:52 -0700 (PDT)
: Matthew Dillon dil...@apollo.backplane.com wrote:
:
: If you don't have the disk necessary for a standard overcommit model
to
: work, you definitely do not have the disk necessary for a
non-overcommit
:
:Yes, you're using your own REAL-LIFE situations, from a large ISP, using
:systems for a few specific server applications, where you have the space
:to put lots of disk, etc.
:
:The things I'm thinking of aren't even necessarily large server
:applcations. NetBSD runs on a CPU that is *often* used
On Tue, 13 Jul 1999, Matthew Dillon wrote:
This is an excellent example of a solution. Another example would be
to implement your own memory management subsystem... that is, your own
shared library which keeps track of memory allocations on a global
basis. I could do one in
On Tue, 13 Jul 1999 15:37:26 -0700 (PDT)
Matthew Dillon dil...@apollo.backplane.com wrote:
When you write embedded systems like these, you do not run any general
purpose binaries at all. You run fully custom binaries and you take
control of the memory management yourself.
:On Tue, 13 Jul 1999 15:12:14 -0700 (PDT)
: Matthew Dillon dil...@apollo.backplane.com wrote:
:
: The text size of a program is irrelevant, because swap is never
: allocated for it. The data and BSS are only relevant when they
: are modified.
:
:Bzzt. BSS is relevant when
On Tue, 13 Jul 1999 15:29:37 -0700 (PDT),
Matthew Dillon dil...@apollo.backplane.com said:
In the same manner any truely critical system server must handle the
resource management itself to deal with all sorts of problem situations,
including memory. You do not need to
:
:On Tue, 13 Jul 1999, Matthew Dillon wrote:
:
: This is an excellent example of a solution. Another example would be
: to implement your own memory management subsystem... that is, your own
: shared library which keeps track of memory allocations on a global
: basis. I could
:
:Heh, really? The camera ships w/ Apache running on it.
:
:-- Jason R. Thorpe thor...@nas.nasa.gov
They obviously have a lot of memory to play with, then. Or they
are crazy. Writing a web server is fairly easy to do. I've
written several, including the one that BEST
: kernel.
: :
: [snip]
: :
: To say that FreeBSD does not support a certain class of system because
: it uses an overcommit model is not correct, because you can trivially
: solve the problem by implementing your own management of memory rather
: then use the
Matthew Dillon dil...@apollo.backplane.com writes:
The text size of a program is irrelevant, because swap is never
allocated for it. The data and BSS are only relevant when they
are modified.
The only thing swap is ever used for is the dynamic allocation of memory.
-BEGIN PGP SIGNED MESSAGE-
So, Matt, I understand that you think that the folks who are want to
turn off overcommit are looking to hang themselves, but how much does
it cost to sell them the rope?
Would adding the sysctl to turn off overcommit be a costly,
time-consuming hunk of work,
On Tue, 13 Jul 1999 15:44:40 -0700 (PDT)
Matthew Dillon dil...@apollo.backplane.com wrote:
So far nobody has been able to justify any good reasons for adding it
to the system. I'm sorry, but just throwing out worst-case theories
is not a good justification, nor is throwing
:So, Matt, I understand that you think that the folks who are want to
:turn off overcommit are looking to hang themselves, but how much does
:it cost to sell them the rope?
:
:Would adding the sysctl to turn off overcommit be a costly,
:time-consuming hunk of work, or a three-line patch? If it's
Matthew Dillon writes:
: ram and 512MB of swap (4MB of swap in use), but the kernel reports over
: 3 GB of VM assigned to processes. That's a fairly lightly loaded machine.
:
:What you say is generally true; however, the problem is that *you*
:are making implicit assumptions about what
So, Matt, I understand that you think that the folks who are want to
turn off overcommit are looking to hang themselves, but how much does
it cost to sell them the rope?
The issue here is that turning off overcommit isn't just a switch.
There are a lot of other things that you're likely to
:
:Well, all I can say is:
:
: I'm sure glad you don't have any influence over the code
: base I run.
:
:-- Jason R. Thorpe thor...@nas.nasa.gov
I'm sure the feeling is mutual. More to the point, I really seriously
doubt that any of the core developers would consider
On Tue, 13 Jul 1999 16:16:07 -0700
Mike Smith m...@smith.net.au wrote:
Matt's point, which he's not making by virtue of talking too much, is
that you can't make a no overcommit system behave like an overcommit
system, and most people are used to the sort of things that the latter
On Tue, 13 Jul 1999 16:24:53 -0700 (PDT)
Matthew Dillon dil...@apollo.backplane.com wrote:
I'm sure the feeling is mutual. More to the point, I really seriously
doubt that any of the core developers would consider this idea either
because it's been rejected in the past and,
:(Mike Smith m...@smith.net.au)
:Matt's point, which he's not making by virtue of talking too much, is
:that you can't make a no overcommit system behave like an overcommit
:system, and most people are used to the sort of things that the latter
:makes practical.
Heh heh.
:On Tue, 13 Jul 1999 16:24:53 -0700 (PDT)
: Matthew Dillon dil...@apollo.backplane.com wrote:
:
: I'm sure the feeling is mutual. More to the point, I really seriously
: doubt that any of the core developers would consider this idea either
: because it's been rejected in the
On Tue, 13 Jul 1999 16:16:07 -0700
Mike Smith m...@smith.net.au wrote:
Matt's point, which he's not making by virtue of talking too much, is
that you can't make a no overcommit system behave like an overcommit
system, and most people are used to the sort of things that the latter
On Tue, 13 Jul 1999 16:29:50 -0700
Mike Smith m...@smith.net.au wrote:
You can make the overcommit or not overcommit option a switch, but
the consumers of the system (may) need to change their behaviour as
well.
I never said they wouldn't have to.
-- Jason R. Thorpe
On Tue, 13 Jul 1999 16:29:50 -0700
Mike Smith m...@smith.net.au wrote:
You can make the overcommit or not overcommit option a switch, but
the consumers of the system (may) need to change their behaviour as
well.
I never said they wouldn't have to.
Making it just a switch does
:
:Well, all I can say is:
:
: I'm sure glad you don't have any influence over the code
: base I run.
:
:-- Jason R. Thorpe thor...@nas.nasa.gov
I'm sure the feeling is mutual. More to the point, I really seriously
doubt that any of the core developers would consider
Matthew Dillon scribbled this message on Jul 13:
FreeBSD's swap subsystem has a basic limitation of 4 swap areas. This
is due to the design of the interleaving algorithms. Increasing this
number is simple, but it results in phenominally more kernel memory
getting wired.
: And disallowing overcommit also does not give applications the *choice*
: of dealing gracefully, because they often cannot deal with the
: situation where they might be refused a reasonable request for memory.
:
:That's objectively false. The application could do something useful
On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
Matthew Dillon dil...@apollo.backplane.com wrote:
You have to consider the probability of an event occuring, not just
the possibility that the event might occur. If the probability is
one in a million years, then it is not something
On Tue, 13 Jul 1999 15:53:43 -0700 (PDT),
Matthew Dillon dil...@apollo.backplane.com said:
... a situation which will never occur if you are managing the memory
through your own custom library. Therefore not relevant.
Hm. It's misunderstanding.
I don't agree with you about
On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
Matthew Dillon dil...@apollo.backplane.com wrote:
You have to consider the probability of an event occuring, not just
the possibility that the event might occur. If the probability is
one in a million years, then it is not
:hmmm... so this means that on my home server where I have:
:Device 1K-blocks UsedAvail Capacity Type
:/dev/od0b 26214431176 23084012%Interleaved
:/dev/da1b 39321631136 361952 8%Interleaved
:/dev/da2b 26214431072 23094412%
:
:On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
: Matthew Dillon dil...@apollo.backplane.com wrote:
:
: You have to consider the probability of an event occuring, not just
: the possibility that the event might occur. If the probability is
: one in a million years, then it is not
-BEGIN PGP SIGNED MESSAGE-
Matthew Dillon wrote:
I said:
:So, Matt, I understand that you think that the folks who are want to
:turn off overcommit are looking to hang themselves, but how much does
:it cost to sell them the rope?
I'm guessing that a simple implementation would be
:Hm. It's misunderstanding.
:
:I don't agree with you about the following point.
:Thus, the situation might happen.
:
:Give me a shell and I can crash any machine. If you are assuming
:hostile users, you cannot assume that your magic overcommit protection
:will save your server.
On Tue, 13 Jul 1999 17:25:21 -0700 (PDT),
Matthew Dillon dil...@apollo.backplane.com said:
With today's modern high capacity disk drives, a properly configured
multi-user system will have enough swap that running it out is difficult
to say the least.
That's wrong.
Please
: On Tue, 13 Jul 1999 17:25:21 -0700 (PDT),
: Matthew Dillon dil...@apollo.backplane.com said:
:
: With today's modern high capacity disk drives, a properly configured
: multi-user system will have enough swap that running it out is difficult
: to say the least.
:
:That's wrong.
On Tue, 13 Jul 1999 17:53:10 -0700 (PDT),
Matthew Dillon dil...@apollo.backplane.com said:
You keep on saying that users can run the system out of swap
easily, and I've tried to point out to you that it isn't quite
as easy as you believe (and I've used a real-life example
:
: Has your simulation ever been kicked by the kernel due to lack of
: swap space?
:
:I already said so. Please at least pretend to read what I wrote
:before replying.
:
:There is a big difference here between a piddling web server and a
:1000-hour simulation. If the web server goes
The point is, the OS should have provided *some* mechanism to insure
that the long-running process wasn't affected. It didn't. That's a
clear failure of the OS to provide a reasonable environment for this
type of computing.
Whether this should be solved by switching to a no-overcommit policy,
: swap. How much swap is on this system, by the way?
:
:I could just as rightfully argue that you're blaming a failure of the
:OS on the sysadmin. Fiddling with limits is all fine and dandy, but
:it's not even close to flexible enough. Consider, for example, the
:specific case of testing a
: I've long felt that the best solution to problems like this is a per-user
:swap space quota. This gives admins a knob to manage the allocation of swap
:space while still allowing overcommit. The downside is that it doesn't provide
:a graceful way for a program to recover from it's
On 14-Jul-99 Jason Thorpe wrote:
On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
Matthew Dillon dil...@apollo.backplane.com wrote:
You have to consider the probability of an event occuring, not just
the possibility that the event might occur. If the probability is
one in a
is there some reason why whether or not to overcommit can't be a kernel
compile time option?
Or that a process can signal its desire to not get SIGKILL by registering
a non-default SIGDANGER (which we'd have to create) handler ala AIX?
] Train travel features AC outlets with no take-off
On Tue, 13 Jul 1999, Matthew Dillon wrote:
There are other ways. For example, even if a user account is resource
limited, root processes (such as sendmail, popper, identd, and so forth)
are not. Attacks against these servers generally result in very high
loads and sometimes
On Tue, 13 Jul 1999, Matthew Dillon wrote:
Jason, I am using real life situations to demonstrate my point. You are
perfectly welcome to use your own REAL-LIFE situations to demonstrate
yours. It is the real-life application that matters, not a worst-case
nightmare theory.
Jon Ribbens wrote:
Yuck. That's a complete abomination. What's the point of it? It's turning
an out-of-memory situation from an easily-detected recoverable temporary
resource shortage which can be worked-around or waited out, into an
unrecoverable fatal error. Do a significant number of
Yuck. That's a complete abomination. What's the point of it? It's turning
Paging Terry Lambert, Terry Lambert - do you read me? It's time for
your annual rant on the topic of memory overcommit. :-)
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in
On Mon, 12 Jul 1999 23:56:29 +0100, Jon Ribbens wrote:
What about it? If an application does not need 100MB, it should not
malloc it. If it does need it, it should malloc it and know that it
is available if the malloc succeeds.
You're rehashing stuff that's been discussed to death. Please
Sheldon Hearn [EMAIL PROTECTED] wrote:
You're rehashing stuff that's been discussed to death. Please look at
the mailing list archives for this mailing list.
I'd love to, could you please be more specific? I can't find anything
relevant searching for 'malloc' or 'overcommit'.
If you're not
Yuck. That's a complete abomination. What's the point of it? It's turning
Paging Terry Lambert, Terry Lambert - do you read me? It's time for
your annual rant on the topic of memory overcommit. :-)
It's not overcommit so much as it is what happens to a process that gets a
page fault when
Jon Ribbens wrote:
If you're not prepared to do that, the long and the short of it is that
FreeBSD _does_ overcommit, we like it that way and neither of these two
facts is likely to change.
I can add it to the list of reasons I don't use it then I guess ;-).
Whatever. The operating
Jon Ribbens wrote:
Yuck. That's a complete abomination. What's the point of it? It's turning
an out-of-memory situation from an easily-detected recoverable temporary
resource shortage which can be worked-around or waited out, into an
unrecoverable fatal error. Do a significant number of
Yuck. That's a complete abomination. What's the point of it? It's turning
Paging Terry Lambert, Terry Lambert - do you read me? It's time for
your annual rant on the topic of memory overcommit. :-)
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers
In message 1336.931774...@zippy.cdrom.com Jordan K. Hubbard writes:
: Paging Terry Lambert, Terry Lambert - do you read me? It's time for
: your annual rant on the topic of memory overcommit. :-)
I thought it was time for his annual rant about how the current
FreeBSD development model is going
Daniel C. Sobral d...@newsguy.com wrote:
That's *not* abomination. How about pre-allocating over 100 Mb for X
Free, for instance?
What about it? If an application does not need 100MB, it should not
malloc it. If it does need it, it should malloc it and know that it
is available if the malloc
On Mon, 12 Jul 1999 23:56:29 +0100, Jon Ribbens wrote:
What about it? If an application does not need 100MB, it should not
malloc it. If it does need it, it should malloc it and know that it
is available if the malloc succeeds.
You're rehashing stuff that's been discussed to death. Please
Sheldon Hearn sheld...@uunet.co.za wrote:
You're rehashing stuff that's been discussed to death. Please look at
the mailing list archives for this mailing list.
I'd love to, could you please be more specific? I can't find anything
relevant searching for 'malloc' or 'overcommit'.
If you're not
On Tue, 13 Jul 1999 00:20:27 +0100, Jon Ribbens wrote:
I'd love to, could you please be more specific? I can't find anything
relevant searching for 'malloc' or 'overcommit'.
My apologies. It was the current mailing list. Search for malloc AND
NULL AND kill, and pick out the swap-related
According to Warner Losh:
I thought it was time for his annual rant about how the current
FreeBSD development model is going to have problems scaling...
No no, I think you're thinking of the write-lock read-lock we should use on
CVS in order to have the Hamiltonian graph without cycle to solve
Yuck. That's a complete abomination. What's the point of it? It's turning
Paging Terry Lambert, Terry Lambert - do you read me? It's time for
your annual rant on the topic of memory overcommit. :-)
It's not overcommit so much as it is what happens to a process that gets a
page fault when
Jon Ribbens wrote:
Daniel C. Sobral d...@newsguy.com wrote:
That's *not* abomination. How about pre-allocating over 100 Mb for X
Free, for instance?
What about it? If an application does not need 100MB, it should not
malloc it. If it does need it, it should malloc it and know that it
Jon Ribbens wrote:
If you're not prepared to do that, the long and the short of it is that
FreeBSD _does_ overcommit, we like it that way and neither of these two
facts is likely to change.
I can add it to the list of reasons I don't use it then I guess ;-).
Whatever. The operating
Ollivier Robert wrote:
Oh I forgot the one about having a veto system for I don't remember what...
Veto based locking for the fs.
--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org
I'm one of those bad things that happen to good people.
To
On Tue, 13 Jul 1999, Daniel C. Sobral wrote:
Jon Ribbens wrote:
Daniel C. Sobral d...@newsguy.com wrote:
That's *not* abomination. How about pre-allocating over 100 Mb for X
Free, for instance?
What about it? If an application does not need 100MB, it should not
malloc it. If it
Assar Westerlund wrote:
And besides, I really don't think this is a grep function but actually
is useful for programs that don't have any strategy for handling out
of memory errors and might as well die (with a descriptive error
message, of course). Let's call it emalloc and let's
"Daniel C. Sobral" [EMAIL PROTECTED] wrote:
OTOH, though, FreeBSD's malloc() is very unlikely to return an out
of memory error.
Why is that?
What happens if the process hits its resource limits?
Cheers
Jon
--
\/ Jon Ribbens / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL
Jon Ribbens wrote:
"Daniel C. Sobral" [EMAIL PROTECTED] wrote:
OTOH, though, FreeBSD's malloc() is very unlikely to return an out
of memory error.
Why is that?
Because memory (as in *real* memory, either RAM or swap) is
allocated on-demand. So you can allocate any amount of virtual
"Daniel C. Sobral" [EMAIL PROTECTED] wrote:
OTOH, though, FreeBSD's malloc() is very unlikely to return an out
of memory error.
Why is that?
Because memory (as in *real* memory, either RAM or swap) is
allocated on-demand. So you can allocate any amount of virtual
memory that the
Jon Ribbens [EMAIL PROTECTED] writes:
"Daniel C. Sobral" [EMAIL PROTECTED] wrote:
OTOH, though, FreeBSD's malloc() is very unlikely to return an out
of memory error.
Why is that?
Because FreeBSD overcommits memory. You can allocate (almost) as much
memory as you want regardless of how much
Assar Westerlund wrote:
And besides, I really don't think this is a grep function but actually
is useful for programs that don't have any strategy for handling out
of memory errors and might as well die (with a descriptive error
message, of course). Let's call it emalloc and let's
Daniel C. Sobral d...@newsguy.com wrote:
OTOH, though, FreeBSD's malloc() is very unlikely to return an out
of memory error.
Why is that?
What happens if the process hits its resource limits?
Cheers
Jon
--
\/ Jon Ribbens / j...@oaktree.co.uk
To Unsubscribe: send mail to
Jon Ribbens wrote:
Daniel C. Sobral d...@newsguy.com wrote:
OTOH, though, FreeBSD's malloc() is very unlikely to return an out
of memory error.
Why is that?
Because memory (as in *real* memory, either RAM or swap) is
allocated on-demand. So you can allocate any amount of virtual
memory
Daniel C. Sobral d...@newsguy.com wrote:
OTOH, though, FreeBSD's malloc() is very unlikely to return an out
of memory error.
Why is that?
Because memory (as in *real* memory, either RAM or swap) is
allocated on-demand. So you can allocate any amount of virtual
memory that the
Jon Ribbens j...@oaktree.co.uk writes:
Daniel C. Sobral d...@newsguy.com wrote:
OTOH, though, FreeBSD's malloc() is very unlikely to return an out
of memory error.
Why is that?
Because FreeBSD overcommits memory. You can allocate (almost) as much
memory as you want regardless of how much
In message 19990712022424.a1...@oaktree.co.uk Jon Ribbens writes:
: No, if the *process* hits its *administrative* resource limits.
: i.e. setrlimit(2).
That should (and I believe does) make malloc fail.
Warner
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers
On Wed, 7 Jul 1999, Jamie Howard wrote:
The FreeBSD, NetBSD, and OpenBSD manpage for grep says this:
Grep understands two different versions of regular expression
syntax: ``basic'' and ``extended.'' In GNU grep, there is
no difference in available functionality
Dag-Erling Smorgrav wrote:
Assar Westerlund [EMAIL PROTECTED] writes:
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
+ realpat = grep_malloc(strlen(pattern) + sizeof("^(")
+ + sizeof(")$") + 1);
Why not just use asprintf?
Doesn't matter, thsis code
On Wed, 7 Jul 1999, Jamie Howard wrote:
The FreeBSD, NetBSD, and OpenBSD manpage for grep says this:
Grep understands two different versions of regular expression
syntax: ``basic'' and ``extended.'' In GNU grep, there is
no difference in available functionality using
Dag-Erling Smorgrav wrote:
Assar Westerlund as...@sics.se writes:
Dag-Erling Smorgrav d...@flood.ping.uio.no writes:
+ realpat = grep_malloc(strlen(pattern) + sizeof(^()
+ + sizeof()$) + 1);
Why not just use asprintf?
Doesn't matter, thsis code is
On 07 Jul 1999 20:57:16 +0200
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote:
Don't use err() indiscriminately after a malloc() failure; malloc()
doesn't set errno.
This is a bug in malloc(3), is it not?
-- Jason R. Thorpe [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL
[accidentally b0rked the cc: line; apologies to those who get this twice]
Jason Thorpe [EMAIL PROTECTED] writes:
On 07 Jul 1999 20:57:16 +0200
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote:
Don't use err() indiscriminately after a malloc() failure; malloc()
doesn't set errno.
This is a
On 7 Jul 1999, Dag-Erling Smorgrav wrote:
BTW, I assume you've read this:
URL:http://www.opengroup.org/onlinepubs/007908799/xcu/grep.html
Of course, my copy of the printout is all marked up. :)
I see you switched to using extended regexps by default, and made -E a
no-op; this breaks
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
- if ((realpat = malloc(strlen(pattern) + sizeof("^(") +
- sizeof(")$") + 1)) == NULL)
- err(1, "malloc");
+ realpat = grep_malloc(strlen(pattern) + sizeof("^(")
+
Assar Westerlund [EMAIL PROTECTED] writes:
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
+ realpat = grep_malloc(strlen(pattern) + sizeof("^(")
+ + sizeof(")$") + 1);
Why not just use asprintf?
Doesn't matter, thsis code is gone in the latest version. You
Jamie Howard howar...@wam.umd.edu writes:
Due to the number of fixes I have received over the past few days, I
decided to put together a new release of grep. It was either this or
watch _Titanic_ on Cinemax.
A clear-cut choice.
I changed it so that even when called as grep or with -G, it
Jamie Howard howar...@wam.umd.edu writes:
Ahh, this is a good idea. I have not yet replaced GNU grep on my system
with this so it has not yet occurred to me that there might be issues with
that.
I tried it; it works fine except for the lack of -w. Haven't tried 0.3
yet.
A good test is to
Jamie Howard howar...@wam.umd.edu writes:
I incorporated a huge patch from Dag-Erling Smorgrav [...]
Here's more :)
BTW, I assume you've read this:
URL:http://www.opengroup.org/onlinepubs/007908799/xcu/grep.html
I see you switched to using extended regexps by default, and made -E a
no-op;
On 07 Jul 1999 20:57:16 +0200
Dag-Erling Smorgrav d...@flood.ping.uio.no wrote:
Don't use err() indiscriminately after a malloc() failure; malloc()
doesn't set errno.
This is a bug in malloc(3), is it not?
-- Jason R. Thorpe thor...@nas.nasa.gov
To Unsubscribe: send mail to
[accidentally b0rked the cc: line; apologies to those who get this twice]
Jason Thorpe thor...@nas.nasa.gov writes:
On 07 Jul 1999 20:57:16 +0200
Dag-Erling Smorgrav d...@flood.ping.uio.no wrote:
Don't use err() indiscriminately after a malloc() failure; malloc()
doesn't set errno.
Dag-Erling Smorgrav d...@flood.ping.uio.no writes:
Jamie Howard howar...@wam.umd.edu writes:
I incorporated a huge patch from Dag-Erling Smorgrav [...]
Here's more :)
Following up on myself, I introduced a bug in the previous round of
patches; here's a corrected patch against 0.3.
(the bug
On 7 Jul 1999, Dag-Erling Smorgrav wrote:
BTW, I assume you've read this:
URL:http://www.opengroup.org/onlinepubs/007908799/xcu/grep.html
Of course, my copy of the printout is all marked up. :)
I see you switched to using extended regexps by default, and made -E a
no-op; this breaks
Jamie Howard howar...@wam.umd.edu writes:
On 7 Jul 1999, Dag-Erling Smorgrav wrote:
I see you switched to using extended regexps by default, and made -E a
no-op; this breaks the ports collection, so I changed it back.
The FreeBSD, NetBSD, and OpenBSD manpage for grep says this:
Dag-Erling Smorgrav d...@flood.ping.uio.no writes:
- if ((realpat = malloc(strlen(pattern) + sizeof(^() +
- sizeof()$) + 1)) == NULL)
- err(1, malloc);
+ realpat = grep_malloc(strlen(pattern) + sizeof(^()
+
Assar Westerlund as...@sics.se writes:
Dag-Erling Smorgrav d...@flood.ping.uio.no writes:
+ realpat = grep_malloc(strlen(pattern) + sizeof(^()
+ + sizeof()$) + 1);
Why not just use asprintf?
Doesn't matter, thsis code is gone in the latest version. You
Dag-Erling Smorgrav d...@flood.ping.uio.no writes:
And besides, I really don't think this is a grep function but actually
is useful for programs that don't have any strategy for handling out
of memory errors and might as well die (with a descriptive error
message, of course). Let's call
Dag-Erling Smorgrav d...@flood.ping.uio.no wrote:
Don't use err() indiscriminately after a malloc() failure; malloc()
doesn't set errno.
When I looked at malloc(3) I decided that it relied on sbrk(2) to set
errno if it returned 0. Is this wrong? i.e. can it return 0 without
a failed syscall?
On Tue, 6 Jul 1999, Sheldon Hearn wrote:
The reason I'm suggesting using a port rather than having the code
imported into the base system is that it allows people to "opt in" to
testing it, rather than forcing it down people's throats. The idea is
that, when it's proved itself as a port,
On Mon, 05 Jul 1999 21:14:36 -0400, Jamie Howard wrote:
It would be really swank if someone were to go over what I have and make
sure it is correct. I know I was blowing $ before, and I think that is
correct now.
Hi Jamie,
One way to make it easier for people to test drive your software
One way to make it easier for people to test drive your software under
FreeBSD is to create a port for the software (FreeBSD-style port, not
NetBSD-style port).
very rough port available at http://gulf.uvic.ca/~jburkhol/grep.shar
--
To Unsubscribe: send mail to majord...@freebsd.org
with
301 - 400 of 404 matches
Mail list logo
