On 27/11/13 13:10, Wade Richards wrote:
Also, the deeper you get into the optimized code, the harder it is to
issue meaningful source-level warnings. E.g. when the compiler optimizes:
static int decimate(x) { return x/10; }
int foo() {
int a=INT_MAX;
int b;
for(i=0; i<100; ++i) { b=max
One of the links Mark posted earlier addresses the "The compiler should issue
warnings" issue. The short answer is because of macro expansion and other
code-rearranging optimizations (inlining functions, loop unrolling, pulling
expressions out of a loop, etc.), undefined code appears and is rem
__
Type your response ABOVE THIS LINE to reply
Re: [SECURITY] [DSA 2805-1] sup-mail security update
Snel.com | Nov 27, 2013 10:45PM CET
Thank you for subm
On 26/11/13 11:37, Mark Haase wrote:
Compiler developers, for better or worse, reserve the right to do
whatever they want with undefined behavior, and it's up to the person
writing the C code to not include undefined behavior in their own program.
That's a fallacy. The fact that a compiler does
On Wed Nov 27, 2013 at 09:04:49, Paul Wise wrote:
> On Wed, Nov 27, 2013 at 6:44 AM, Stefan Roas wrote:
>
> > Such code has never been valid and any assumption anyone may falsely have
> > on such code is outright wrong. Such code may do anything, which includes
> > nothing so IMHO it's perfectly o
On Tue, Nov 26 2013, Paul Wise wrote:
> On Wed, Nov 27, 2013 at 6:44 AM, Stefan Roas wrote:
>
>> Such code has never been valid and any assumption anyone may falsely have
>> on such code is outright wrong. Such code may do anything, which includes
>> nothing so IMHO it's perfectly ok for the optim
On 13Nov27:2356+1100, Scott Ferguson wrote:
> On 27/11/13 23:37, David L. Craig wrote:
> > On 13Nov27:1423+1100, Scott Ferguson wrote:
> >
> >> On 27/11/13 13:49, David L. Craig wrote:
> >
> >>> On 13Nov26:1545-0500, David L. Craig wrote:
> >>>
> On 13Nov26:1437-0500, Mark Haase wrote:
> >>>
7 matches
Mail list logo