[email protected] wrote:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194823
Bug ID: 194823
Summary: "bsdgrep -E { /dev/null" core dumps
Product: Base System
Version: 9.3-RELEASE
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: [email protected]
Reporter: [email protected]
On my 9.3-RELEASE machine, 'bsdgrep -E { /dev/null' core-dumps.
Noticed on an amd64 machine:
FreeBSD xxx.pix.net 9.3-RELEASE-p3 FreeBSD 9.3-RELEASE-p3 #0: Mon Oct 20
15:08:33 UTC 2014
[email protected]:/usr/obj/usr/src/sys/GENERIC amd64
Also happens on a mips64 machine, running HEAD:
FreeBSD xxx.pix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r273585M: Mon Oct 27
19:49:36 UTC 2014 [email protected]:/usr/obj/usr/src/sys/ERL mips
And on a sparc64 machine, running 10.1-ish code:
FreeBSD xxx.pix.net 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #1 r273165: Thu Oct
16 19:30:46 UTC 2014 [email protected]:/usr/obj/usr/src/sys/GENERIC sparc64
i could be wrong
but i dont' think unix strives to make base binaries bloated to such
effect that when used incorrectly there is never an error message or
quick C header exit (core dumps being a kernel option)
your supposed to strive to use it correctly, not strive to find ways to
use it incorrectly
how big and slow and complicated will all the binaries be if they must
stop and check for every possible mis-use ?
many use fscanf to when reading args. that's easy to "core dump"
but using microsoft outlook to import args is "hardly an option"
sure there is some in-between. but an expectation to hack an IEEE app
which could effect (thousands of people?) every time you find out how
not to use it - it just shouldn't be done. it needs to be looked at by
IEE. you realize that right? it can't be hacked. doing so would be
negligent.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
