Subject: Re: gcc optimizer bug in netbsd-1-6 on alpha (gcc 2.95.3 20010315 (release) (NetBSD nb3))
To: None <tech-toolchain@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 08/15/2003 17:21:17
>> We want the better optimizations that "new C" enables more than we
>> want the semantics of "traditional C".
Is this an ex cathedra pronouncement?
>> Thus, anything that depends on "traditional C" should be fixed.
Or struct sockaddrs. You can finesse many uses (eg, the stuff coming
back from getaddrinfo()) by declaring that the _real_ object type is
the AF-specific one, and the struct sockaddr * is just an intermediate
type (which as I read the explanation is OK as long as its alignment
requirements are no stricter than any AF-specific version). But how do
you propose to deal with code that uses struct sockaddr, or struct
sockaddr_storage, and references the sa_family/sa_len (resp.
ss_family/ss_len) members to decide which AF-specific struct to treat
it as? Must code that does an accept() first check the address family
of the socket so it can know which AF's AF-specific sockaddr to cast to
struct sockaddr * for the second argument to accept()? A whole lot of
code that uses sockaddr_storage is now broken by fiat, even though it
was written correctly according to the API as it existed up until this
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML firstname.lastname@example.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B