2012/6/12 Xiaofan Chen <[email protected]>:
> On Mon, Jun 11, 2012 at 9:44 PM, Pete Batard <[email protected]> wrote:
>> Tarball archive at
>> https://sourceforge.net/projects/libusbx/files/releases/1.0.12/source/
>>
>> If possible please test the archive and report issues or potential
>> enhancements.
>>
>
> As already mentioned before, there are a few warnings
> under NetBSD but as per Pete we are going to wait for
> some BSD people to chime in to help resolve the warnings.
> I think that is fair.
>
> os/openbsd_usb.c: In function '_sync_control_transfer':
> os/openbsd_usb.c:638:2: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
> os/openbsd_usb.c:639:2: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
> os/openbsd_usb.c:640:2: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
I have similar warnings under Mac OS X when using -fstrict-aliasing in CFLAGS.
$ make
make all-recursive
Making all in libusb
CC libusb_1_0_la-core.lo
CC libusb_1_0_la-descriptor.lo
CC libusb_1_0_la-io.lo
CC libusb_1_0_la-sync.lo
CC libusb_1_0_la-darwin_usb.lo
CC libusb_1_0_la-threads_posix.lo
os/darwin_usb.c: In function 'usb_setup_device_iterator':
os/darwin_usb.c:176: warning: type-punning to incomplete type might
break strict-aliasing rules
os/darwin_usb.c:180: warning: type-punning to incomplete type might
break strict-aliasing rules
os/darwin_usb.c: In function 'usb_get_next_device':
os/darwin_usb.c:226: warning: type-punning to incomplete type might
break strict-aliasing rules
os/darwin_usb.c:235: warning: type-punning to incomplete type might
break strict-aliasing rules
os/darwin_usb.c: In function 'darwin_devices_detached':
os/darwin_usb.c:304: warning: type-punning to incomplete type might
break strict-aliasing rules
os/darwin_usb.c: In function 'darwin_kernel_driver_active':
os/darwin_usb.c:1287: warning: type-punning to incomplete type might
break strict-aliasing rules
CCLD libusb-1.0.la
Making all in doc
make[2]: Nothing to be done for `all'.
According to [1] it is a bug in (Apple) GCC.
-fstrict-aliasing
Allows the compiler to assume the strictest aliasing rules
applicable to the language being compiled. For C (and C++), this
activates optimizations based on the type of expressions. In
particular, an object of one type is assumed never to reside at the
same address as an object of a different type, unless the types are
almost the same. For example, an "unsigned int" can alias an
"int", but not a "void*" or a "double". A character type may alias
any other type.
Pay special attention to code like this:
union a_union {
int i;
double d;
};
int f() {
a_union t;
t.d = 3.0;
return t.i;
}
The practice of reading from a different union member than the one
most recently written to (called "type-punning") is common. Even
with -fstrict-aliasing, type-punning is allowed, provided the
memory is accessed through the union type. So, the code above will
work as expected. However, this code might not:
int f() {
a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}
Every language that wishes to perform language-specific alias
analysis should define a function that computes, given an "tree"
node, an alias set for the node. Nodes in different alias sets are
not allowed to alias. For an example, see the C front-end function
"c_get_alias_set".
Enabled at levels -O2, -O3, -Os, -Oz (APPLE ONLY).
Bye
[1] http://lists.apple.com/archives/xcode-users/2008/Jul/msg00745.html
--
Dr. Ludovic Rousseau
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
