On 07/08/14 04:04, Christopher Li wrote: > Send again to the list with plain text mode. > >> No, __restrict__ is only applied to various pointer types in the MinGW >> header files (see below). So, I agree that validation/reserved.c is not >> exactly representative of the actual use of __restrict__ (or *any* of the >> keywords come to that), but that does at least provide a minimal test. > > > Let me clarify. I want to have some regression test cover your usage case. > e.g. If I rewrite some part of sparse and breaks __restrict__ but did not break > __restrict, I will have not way of knowing it. So please submit corresponding > test case. Yep, version 2 of patch coming soon. > __restrict__ does not seem like part of the stander C. BTW, did you try > to use gcc -E to find out if __restrict__ expand to any thing like "__restrict"? Yes, the header is using the keyword __restrict__. (I have found that headers tend to use __restrict if they are using macros). >> Having said that, I think I see two tests included for the array declaration >> usage: abstract-array-declarator-static.c and restrict-array.c. >> > I don't see it cover the __restrict__ case as far as I can tell. Yes, I didn't get that you were talking specifically about __restrict__, rather than any one of 'restrict', '__restrict' or '__restrict__'. > Also, do you have run into the case that "__restrict__" was use in abstract > array? None of your grep example show usage in the array. Your patch seems > suggest that is possible. They are very rare in the wild! :-D The only examples I have come across for real are 'posix_spawn()' (see <spawn.h>) and 'regexec()' (<regex.h>). ATB, Ramsay Jones -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html