Rajangiri's Blog

“Array types in C are always one-dimensional”

Surely this is just wrong. I just wrote a little program to check I wasn’t going mad and prove that you can have 2+-dimensional arrays in C. And it works:

[BTW No-one need bother pointing out the lack of variable initialisation!]

#include <stdio.h>

typedef char array[10][10];

void main(void)
{
array test;
int x,y;

for (x=0; x<=9; x++)
{	for (y=0; y<=9; y++)
		printf("%3d ",test[x][y]);
	printf("\n");
}
}

RobertSteed (talk) 16:30, 18 November 2008 (UTC)

Read a bit further down. “C does not have a special provision for declaring multidimensional arrays, but rather relies on recursion within the type system to declare arrays of arrays, which effectively accomplishes the same thing. The index values of the resulting “multidimensional array” can be thought of as increasing in row-major order.” I’m skeptical about this interpretation, but without carefully consulting the standard I’m not prepared to contest it. Dcoetzee 21:29, 18 November 2008 (UTC)

I did read that, and it too is wrong. Again, see my example – that is a multidensional array, in standard C code. It is not an array of arrays.

RobertSteed (talk) —Preceding undated comment was added at 11:26, 19 November 2008 (UTC).

Your example is wrong.

That is an array of arrays.

Consider what sizeof test[x] means. —Preceding unsigned comment added by 216.239.45.4 (talk) 11:41, 1 March 2009 (UTC)

It is a matter of interpretation. However often used, an array in C is veneer (“syntactic sugar)” over plain pointer arithmetic. The way it handles multidimensional arrays is to extend that pointer arithmetic. So, in fact, C does not have any special provision for multidimensiaonal arrays. However, as far as I’m concerned, the same could be said for one-dimensional arrays in C. I see no point in the statement saying “they’re always one-dimensional”. I’m for deleting that. —A D Monroe III (talk) 12:11, 19 November 2008 (UTC)

Me too – you might as well say C doesn’t really have array indexing, since it’s just syntactic sugar for pointer arithmetic and dereferencing. It was designed to support multidimensional arrays in this way. Dcoetzee 20:40, 19 November 2008 (UTC)

The array indexing operator [] is just veneer over pointer arithmetic. Arrays themselves are not. Eric119 (talk) 00:25, 20 November 2008 (UTC)

Eric119 is right; and furthermore, the fact that C arrays are inherently one-dimensional is important for a programmer to understand, as it affects function parameters (for example). — DAGwyn (talk) 17:53, 6 May 2009 (UTC)

As a side note, it is important to see that there is a difference between a 2 dimensional array like char arr[10][10] (which does rely on recursion), and a 2 dimensional array where the first dimension is an array of pointers to the second dimension. A good example of the latter is argv (the 2nd argument to main, the argument vector). The simple 2 dimensional uses less memory, and is generally consecutive in memory – the second uses more memory (the size of the first dimension) and may or may not be consecutive in memory Ajrisi (talk) 13:01, 12 May 2009 (UTC)

POV-based comments regarding object-orientation

The C language doesn’t provide built-in support for object-oriented code (nor in fact for several interesting features), though those can be constructed. There are well-known examples of class-structures in C, e.g., X Window System. It would be nice to reduce the persistent intrusion of POV-based edits in this area. Tedickey (talk) 20:06, 11 December 2008 (UTC)

I did not edit any of the article in regard to this area, but I don’t agree with you. The current version of the article says: Very limited support for object-oriented programming with regard to polymorphism and inheritance. There is no built-in support at all, I would prefer a sentence like: No built-in support for object-oriented programming. This would be more accurate IMHO. It’s the same for generic programming. With C you can do anything you want (C is a very powerful general purpose low-level language), but as C is intentionally “close to the metal”, you doin’t have much help for any high level constructs such as Object Oriented Programming, Generics, Closures, Garbage Collection, etc… It does not mean that you can not develop frameworks in C to support these features. Hervegirod (talk) 12:51, 17 January 2009 (UTC)

Generic programming completely absent

The article says:

• Only rudimentary support for generic programming

despite being a C programmer that have abandoned C++ for the PODs issues, I must say there is no generic programming whatsoever in C, unless the preprocessor is counted; and since the preprocessor provides no type control whatsoever, counting the preprocessor is not justified. … said: Rursus (bork²) 10:43, 17 January 2009 (UTC)

It does support a limited form of generic programming with generic pointers; qsort is a good example. Mike92591 (talk) 21:09, 17 January 2009 (UTC)

qsort is not an example of generic programming, rather of first-class functions implemented using function pointers. Adrianwn (talk) 06:44, 6 March 2010 (UTC)

open standard

It is kind of curious to see C# in the open standard article, but not C.

Is there a reason for that ?

If not, could someone who knows a bit about the subject add it there ?

Current C standards apparently don’t meet the criteria. Generally, you have to buy a copy, and that’s cheaper for some national-body versions than for others. I don’t know whether the next C standard (C1x) will qualify as an “open standard.” — DAGwyn (talk) 17:58, 6 May 2009 (UTC)

Image copyright problem with File:Kr c prog lang.jpg

The image File:Kr c prog lang.jpg is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here. In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page. Please check

• That there is a non-free use rationale on the image’s description page for the use in this article.
• That this article is linked to from the image description page.

This is an automated notice by FairuseBot. For assistance on the image use policy, see Wikipedia:Media copyright questions. –13:49, 8 February 2009 (UTC)

Pointer alignment

Regarding my addition reverted in rev. 274795659, is not the reference to the WG14 year 2005 draft of the C standard sufficient to substantiate my re-phrasing of the actual paragraph 7 of section 6.3.2.3? —ilgiz (talk) 23:55, 3 March 2009 (UTC)

• The editor who reverted seemed to think that your description was not faithful to the standard.

It is difficult for me to understand your paragraph; you say that the C standard requires such-and-such, but it is not clear whom it requires it of. Is it something a C implementation must make sure happens, or something a programmer must construct his program to conform to? It’s not easy to tell from your text, unless one already knows what you’re trying to say.

Also, it is not clear to me that the issue is one that ought to be discussed in this article at all. It is not my any measure a central property of the C programming language how it deals with unaligned pointer casts. Language lawyers and professional programmers who care about the theoretical limits of portability need to know these things, but they need to know many more details than a general encyclopedia article can reasonably provide anyway. Everyone else will probably go “huh?” no matter how well this is explained. –Henning Makholm (talk) 01:06, 4 March 2009 (UTC)

• I read your comment as a concern that it is up to the C compiler implementation to go into necessary details of targeted CPUs. But I think the standard had to be adjusted so that it would apply universally. You may already know that some CPUs require word access to occur by an aligned boundary and that the compilers targeted to such CPUs provide ways to adjust the code to the CPU specifics. For example, armcc offers the following measures:

1. stack variable alignment on a boundary of multiple of 8,
2. the __packed qualifier that would make the compiler access adjacent words and combine them into a result,
3. the __align(n) keyword that forces alignment on a multiple of “n”.

I think that following the pointer alignment restriction I found in the C standard draft would allow to write portable code. For example, to make the anti-example portable,

char *external_buffer = "abcdef";
uint32_t *internal_data;

internal_data = (uint32_t *)external_buffer;  // UNDEFINED BEHAVIOUR if "the resulting pointer is not correctly aligned"
// Also, *internal_data results in different values on big- and little-endian CPUs.

I would write:

char *external_buffer = "abcdef";

// Apparently, it goes without saying that automatic and static variables are guaranteed to be correctly aligned
uint32_t internal_data1;
uint32_t *internal_data = &internal_data1;

// Alternatively, section 7.20.3 "Memory management functions" guarantees that malloc() returns an address of a super-aligned block
// uint32_t *internal_data = malloc(sizeof(uint32_t)); 

// assuming the network order of the external data and that the protocol stipulates a 4-byte field in the beginning
*internal_data = (((((uint32_t)(external_buffer[0]) << 8) | external_buffer[1]) << 8) | external_buffer[2]) << 8) | external_buffer[3];

It is good that the article can be an educational material. I do not mind if it also presents minor details reflected in the C standard. —ilgiz (talk) 16:12, 4 March 2009 (UTC)

• I think there are several misconceptions in the above. The C standard does not currently include any specific object-alignment aids, and implementations are always required to align the standard types so that they work (which is one reason structs can have internal padding).

It is certainly true that a few target-specific applications need some additional form of alignment control, for example aligning DMA buffers with memory cache lines; in such cases, compilers for those targets virtually always provide nonstandard extensions to do the job.

Alignment of word pointers on sub-word boundaries cannot be supported on many platforms without a high run-time cost for using that facility, and since it is rarely useful (only for picking fields out of a packed record image, which may also have endian issues) the C standards committee has been reluctant to require it be supported by all implementations. — DAGwyn (talk) 18:10, 6 May 2009 (UTC)

• Re: “in such cases compilers for those targets virtually always provide _nonstandard_ extensions to do the job”, I only touched on the case when a programmer casts a pointer of granularity 1 to another pointer of higher granularity. I suggested that this often stems from unawareness of the C compiler varieties and targets and of the C standard’s section 6.3.2.3, par. 7 that prohibits such casts. I suggested that the cast should be replaced by allocating a properly aligned buffer of the higher granularity and by populating its content. Optionally, I suggested that it might make sense to combine the content transfer with the network-to-host order conversion.

Re: aligning hardware buffers, I am not experienced with this much. If the problem is in creating a buffer with a certain granularity that exceeds the particular C compiler/target’s notion of super-alignment in malloc(), it is still possible to allocate a sufficiently large buffer and calculate the low and high addresses satisfying the required granularity. This would keep the code C standard compliant as it would not depend on non-standard keywords.

Re: impossibility of casting “sub-word” addresses to “word” pointers within C standard, this agrees with the above reference to section 6.3.2.3 par. 7. I understand that certain compilers do provide non-standard keywords such as __packed that tell the compiler to generate 2 word accesses, combine the results into one temporary word by rotating/masking these results and resolve *wordP into that temporary word. I am just saying that instead of relying on non-standard features and C preprocessor branching by target, it is possible to write portable bare C code by picking “sub-words” explicitly and putting them into a “word”-aligned buffer. —ilgiz (talk) 22:17, 8 May 2009 (UTC)

Array-pointer interchangeability

Should the main article mention that the types of the following 3 expressions are different?

  &arr[0]
  arr
  &arr

As a consequence of the recursive application of the derived type/element type relation described in 6.2.5 Types, par. 20 of WG14 N1124, &arr[1] and &arr + 1 will point to different areas if arr has more than 1 element. —ilgiz (talk) 17:04, 2 April 2009 (UTC)

• I don’t think the article should try to explore such details; it’s not a programming tutorial. — DAGwyn (talk) 18:12, 6 May 2009 (UTC)

About this phrase->

“Despite this apparent equivalence between array and pointer variables, there is still a distinction to be made between them. Even though the name of an array is, in most expression contexts, converted into a pointer (to its first element), this pointer does not itself occupy any storage, unlike a pointer variable. Consequently, what an array “points to” cannot be changed,” […]”

IMHO, I think that text in bold is not a good indication of distinction between array and pointer, because the same restriction applies to const pointers (these also we can`t change what they points to), as in:

int *const MyPointer;

So in my opinion, text in bold should be deleted from article. Also, can it be that array variable REALLY is just read-only pointer ? (as in my given example). —Preceding unsigned comment added by 84.32.222.96 (talk) 20:38, 12 November 2009 (UTC)

• No storage for the array address means compile time calculation of its offsets. The const modifier of the pointer may be circumvented at run time by casting. Modifying array offsets at run time would require interfering with the generated code and temporary storage. —ilgiz (talk) 21:33, 12 November 2009 (UTC)
  • Thanks, for explanation about pointer const modifier circumvention. Now i am totally confused. Whats the point of having const modifier if we can bypass it by just casting ? Huh. IMHO, this may be design flaw in C. This may mean that:

1. C don`t needs const modifier for pointers at all. OR

2. C should be changed such that const modifier may not be bypassed by simply casting const pointer to non-const pointer before address assigment.

It`s a pitty that such flaw exists. —Preceding unsigned comment added by 84.32.222.96 (talk) 09:37, 13 November 2009 (UTC)

• Number (2) is already in place. I believe a warning may be emitted by a C compiler when const-ness is cast away. The point in allowing a bypass is to work around the older code unaware of const modifiers when it interleaves with the new code. The proper fix would involve massive changes to the older code. —ilgiz (talk) 16:48, 13 November 2009 (UTC)

The const keyword is meant to be part of the contract between the function provider and the client. As such, it is designed to inform the client that there is a promise that a variable or parameter will not be modified by the function. However, since the variable may actually be provided by the function writer (especially if it is an opaque structure), it is reasonable to allow it to modify the variable as part of its internal operation. Thus the possibility of “casting const-ness away” provided by the language. C was designed with the principle that the programmer knows what he is doing, and therefore it should provide features to allow him to do useful things instead of hindering him. By the same token, the programmer must explicitly override the default behavior in order to do this. — Loadmaster (talk) 00:07, 14 November 2009 (UTC)