Talk:Aliasing (computing)

Compiler optimization

This should mention the problem with aliasing WRT performance and compiler optimization. In particular, this function:

foo(int & a, int & b) {
  ...
}

won't be as optimizable as

foo(int & a, int b)

because of aliasing. I know I've seen examples of this, but don't have time to write this up now.

The statement:

 allows impressive increases in performance

is without citation. I can find no reliable data to support such a statement. Words like "impressive" are emotive. "impressive to who??" 202.80.43.31 (talk) 22:07, 11 February 2008 (UTC)[reply]

an example in C to explain things in more detail ?

Here is an example how code might break, and what kind of optimizations are possible:

file t1.c:

#include <stdio.h>

unsigned short *test(unsigned int *a);

int main(void)
{
    unsigned int a;
    unsigned short *b;

    b=test(&a);
    a=0;

    *b=5; /* This _MIGHT_ change the value of a !*/

    a+=5;

    printf("a == %d\n",a);
    return 0;
}

When the compiler looks at *b=5 it cannot know if b points to a.
With "strict aliasing", the compiler will decide that b cannot point to a, because b does point to a variable, which has a different type than a. This allows the compiler to translate the C code into assembler code, which will look something like this:

   1 call test, with address of a, result is in b
   2 set memory location to which b points to 5
   3 set a to 5
   4 call printf
   5 return 0

Because an optimizing compiler assumes that the *b=5 statement will not change the value of a, it knows that the statement a+=5 will be the same as a=5 and simply will compile it that way.

Now if you actually supply an implementation for the test function in a file called "t2.c" like this:

unsigned short *test(unsigned int *a)
{
    return (unsigned short *)a;
}

and then compile an application out of t1.c and t2.c, then a compiler which assumes strict aliasing and optimizes according to that will compile an application which will print

a == 5

To try out use a recent GCC compiler and execute

  gcc -O2 -c t1.c
  gcc -O2 -c t2.c
  gcc -o t t1.o t2.o

The resulting executable will behave exactly like described.

If you compile with

  gcc -O2 -fno-strict-aliasing -c t1.c
  gcc -O2 -fno-strict-aliasing -c t2.c
  gcc -o t t1.o t2.o

the compiler will not make any assumptions about the *b=5 statement and print

  a == 10

Note: This is of course only true on Little Endian architectures like Intel or AMD CPUs! On Big Endian architectures (like PowerPC), you might get a == 327685 (if "unsigned int" is a 32 bit integer)! 92.194.112.136 (talk) 13:08, 25 October 2008 (UTC)[reply]

Array bounds checking is (not) aliasing?

I would argue that accessing elements outside the allocated array range doesn't count as aliasing, since it invokes undefined or implementation-specific behaviour. Aliasing is considered when legal language constructions lead to the same memory being addressed with two or more variables. I don't have any references at hand to back up my claims, but neither has the article.... 213.134.167.76 (talk) 18:06, 7 December 2008 (UTC)[reply]

Aliased pointers (C Example)

The link pointed by "See the C example of the xor swap algorithm" needs to be corrected to http://wiki.riteme.site/wiki/Xor_swap_algorithm#Code_example, and also the example was corrected so that it does not fail anymore. Maybe we should write an example here itself, instead of linking out to another page? Naveen Kumar Molleti (talk) 09:55, 21 December 2009 (UTC)[reply]

Reference to Compromised URL

Is it just me, or has this site been hacked?

http://www.cellperformance.com/

It redirects to a fraudulent (viral) site:

http://anti-virus-secure-scanner.com/

Also, it seems the site's lease is going to expire soon anyways:

http://whois.domaintools.com/cellperformance.com

This will be posted in each of the following discussions at: http://wiki.riteme.site/wiki/Comparison_of_Java_and_C++ http://wiki.riteme.site/wiki/Aliasing_(computing) http://wiki.riteme.site/wiki/Restrict

76.64.33.246 (talk) 06:11, 2 January 2009 (UTC)[reply]

Standards Reference

I found the following sentence misleading: "To enable such optimizations in a predictable manner, the ISO standard for the C programming language (including its newer C99 edition, see section 6.5, paragraph 7) specifies that it is illegal (with some exceptions) for pointers of different types to reference the same memory location."

My understanding of the standard indicates that it's not illegal for pointers of different types to reference the stame memory location. However, it is illegal to dereference a pointer of the wrong type. Frequently, programs temporarily cast pointers to void* temporarily. — Preceding unsigned comment added by BrianJThomas (talk • contribs) 00:56, 14 June 2011 (UTC)[reply]

That is correct -- the specification talks about accessing memory locations. I've updated the page. --AbstractNonsense (talk) 15:43, 14 June 2016 (UTC)[reply]

Merge proposal

There's a May proposal to merge Pointer aliasing here; seems like a synonym, so seems reasonable. This is the better-developed page. Klbrain (talk) 13:11, 18 November 2020 (UTC)[reply]

Do not merge. This article does not have one single citation. What would we merge? The Aliasing article already has a section on pointer aliasing as well. Change it to a redirect.--Frobozz1 (talk) 22:32, 29 March 2021 (UTC)[reply]