When reading the code I had to stop, say "ok, what does *these*
modifications of strl*() do? Pull out grep. Oh, not in add/, maybe above
in ../lib/? Yep. So what do they do? Comments above them are misleading,
guess I'll have to read the code. Oh, they just test strl* against the
size and return the result of the test. Now I can continue to read the
code I was.
The uses of s_strl*() then test that result and errx()'s.
Lets think about the "optimized" code I am removing:
In general the compiler pushes the three args to strl* onto the stack and calls
s_strl*. s_strl* has to indirectly access 3 args from the stack. Then push
them on the stack a 2nd time for the real strl* call. s_strl* then pops the
return from strl* off the stack; or moves it from the register it was returned
in, to the register where tests can happen. s_strl* then pops the three
arguments to strl*. Perform the test, push the result of the test, or move it
from the result register to the return value register. The caller to s_strl*
now has to either pop the return value of s_strl* or move it from the return
value register to the test register. The caller then pops the three args to
s_strl* off the stack (the same args that s_strl* itself had to pop off after
the real call to strl*). The s_strl* caller then performs a simular test to
what has already been done, and conditionally jumps. By doing things this way, we've given the compiler optimizer less to work with.
Also, please don't forget the that call to s_strl* has possibly jumped to code
not in the cache due to being far away from the calling code, thus causing a
pipeline stall.
So where is the "optimization" from s_strl*?
It isn't code clarity.
It isn't code execution speed. It isn't code size either.
in the signal handlers which may pose a risk when executable by untrusted
users.
Submitted by: Przemyslaw Frasunek <venglin@freebsd.lublin.pl>
MFC After: 3 days
correct the error-checking that was there. With the old code, an error
return from getpwuid(daemon_user) could turn the lpd process into a very
effective fork-bomb...
Reviewed by: freebsd-audit freebsd-print (a little...)
MFC after: 6 days
blown over by the Hurricane and had a house dropped on you by the Tornado.
Now it's time to have your parade rained on by... the Typhoon!
This commit adds driver support for 3Com 3cR990 10/100 ethernet
adapters based on the Typhoon I and Typhoon II chipsets. This is actually
a port of the OpenBSD driver with many hacks by me.
No Virginia, there isn't any support for the hardware crypto yet. However
there is support for TCP/IP checksum offload and VLANs.
Special thanks go to Jason Wright, Aaron Campbell and Theo de Raadt for
squeezing enough info out of 3Com to get this written, and for doing
most of the hard work.
Manual page is included. Compiled as a module and included in GENERIC.
- Declare mtabhead as an extern in mounttab.h and define it only in
mounttab.c.
- Remove shared global `verbose' and instead pass it as a parameter.
- Remove the `mtabp' argument to read_mtab(). It served no purpose
whatsoever, although read_mtab() did use it as a temporary local
variable.
- Don't check for impossible conditions when parsing mounttab, and
do detect zero-length fields.
- Correctly test for strtoul() failures - just testing ERANGE is wrong.
- Include a field name in syslog errors, and avoid passing NULL to
a syslog %s field.
- Don't test if arrays are NULL.
- If there are duplicates when writing out mounttab, keep the last
entry instead of the first, as it will have a later timestamp.
- Fix a few formatting issues.
Update rpc.umntall and umount to match the mounttab interface changes.
- Remove unnecessary and unused local variables.
- Include useful information in error and warning messages.
- Fix the logic for expiring mounttab entries.
- Remove calls to getaddrinfo - the results were not used.
- Simplify some string handling by using snprintf.
- Fix usage.
than the long-standing -w option in NetBSD, so change it before anyone in
FreeBSD gets used to it. For now, -w is still accepted, but prints out
some warnings via syslog.
MFC after: 1 week
Problem 1 is that the config entry hangup flag is zeroed only at
CONNECT_ACTIVE_IND in msghdl.c. If any (other) call is disconnected
after EV_MDO and before CONNECT_ACTIVE_IND, the cleanup routine will
disconnect the in-progress dialout as well, if its hangup flag is
nonzero (which it is likely to be) after the previous incarnation of the
cfg entry. Patch-1 fixes this by clearing the hangup flag as soon as a
cfg entry is reserved for the call.
Submitted by: Juha-Matti Liukkonen <jml@cubical.fi>
Problem 2 is that doing a local hangup (eg. by writing "H" to the
dialout device) to a call which is already disconnected results in isdnd
moving the cfg entry to an illegal state, from which there is no
recovery. This is tricky because there is no way to synchronize local
hangup with the remote end (ie. the callee can always hang up at an
inconvenient time)! Hence, patch-2 alters fsm.c's EV_DRQ state table
such that the local hangup request is processed or ignored in most
states, even for disconnected calls.
Submitted by: Juha-Matti Liukkonen <jml@cubical.fi>
Don't set BINMODE to 500. This is not a setuid program.
Note: the dpt utilities have never been attached to the world and
haven't been compilable for a year or two.
- Lose any stray host bits that a user may have entered when providing
a network number and netmask to the `-a' option for IPv6. This is
corresponding to 1.79 that is for IPv4 only.
MFC after: 1 week
