gcc memcpy "knows" about types that are supposed to be actually already
aligned and triggers alignment errors doing the memcpy itself.
"Fix" this by changing it to a bcopy(). In this case, we had:
struct timeval *tp;
struct timeval tv1;
memcpy(&tv1,tp,sizeof(tv1));
.. and since gcc *knows* that a pointer to a timeval is longword aligned
and that tv1 is longword aligned, then it can use an inline that assumes
alignment. The following works too:
cp = (char *)tp;
memcpy(&tv1,cp,sizeof(tv1));
Simply casting (char *)tp for the memcpy doesn't work. :-(
This affected different 64 bit platforms in different ways and depends
a lot on gcc as well. I've seen this on alpha and ia64 at least, although
alpha isn't doing it right now.
o Fix zero payloading, unbreak ping -s 0.
o Increase socket recieve buffer, ping -s 65467 is working now.
Submitted by: anti-magic sweep based on kris's patch
Reviewed by: bde, silence on -audit
MFC after: 2 months
It does not help modern compilers, and some may take some hit from it.
(I also found several functions that listed *every* of its 10 local vars with
"register" -- just how many free registers do people think machines have?)
right; after a single packet was dropped it beeped after every
transmission.
Change its implementation to only output a bell when there is an
increase in the maximum value of the number of packets that were
sent but not yet received. This has the benefit that even for very
long round-trip times, ping -A will do roughly the right thing
after a few inital false-positives.
Reviewed by: ru
COPTS towards the end of final CFLAGS so that it can be used to
override Makefile and other defaults. Using it in Makefiles risks
having options set using it clobbered when somebody uses it on the
command line.
Approved by: bde
Avoid using parenthesis enclosure macros (.Pq and .Po/.Pc) with plain text.
Not only this slows down the mdoc(7) processing significantly, but it also
has an undesired (in this case) effect of disabling hyphenation within the
entire enclosed block.
The original code was certainly broken; it knows that whereto is
to be used for a sockaddr_in, so it should be declared as such.
To support multiple protocols, there is also a sockaddr_storage
struct that can be used; I don't think struct sockaddr is supposed
to be used anywhere other than for casts and pointers.
Submitted by: Ian Dowse <iedowse@maths.tcd.ie>
MFC after: 3 weeks
This one is strange and goes against my rusty compiler knowledge.
The global declaration
struct sockaddr whereto;
produces for both i386 && alpha:
.comm whereto,16,1
which means common storage, byte aligned. Ahem. I though structs
were supposed to be ALDOUBLE always? I mean, w/o pragma packed?
Later on, this address is coerced to:
to = (struct sockaddr_in *)&whereto;
Up until now, we've been fine on alpha because the address
just ended up aligned to a 4 byte boundary. Lately, though,
it end up as:
0000000120027b0f B whereto
And, tra la, you get unaligned access faults. The solution I picked, in
lieu of understanding what the compiler was doing, is to put whereto
as a union of a sockaddr and sockaddr_in. That's more formally correct
if somewhat awkward looking.
user runs with privilege, allowing the sending of icmp packets with
larger size (up to 48k, the default receive buffer size in ping),
which is useful for network driver development testing, as well
as experimentation with fragmentation.
Reviewed by: wpaul
add an upper limit to -t
match the types of return values and the variables they are stuffed in
make the man page and usage() a little more consistantly ugly
less obfuscation.
Submitted by: adrian, billf
