Talk:C data types#rfc 2F0C110

This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

C/C++ High‑importance This article is within the scope of WikiProject C/C++, a collaborative effort to improve the coverage of C and C++ topics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.C/C++Wikipedia:WikiProject C/C++Template:WikiProject C/C++C/C++ High This article has been rated as High-importance on the importance scale. This article falls within the scope of C.

I was annoyed to see that a lot of the useful information on this page has been purged. Please compare: http://en.wikipedia.org/w/index.php?title=C_data_types&diff=prev&oldid=456503038

The reason was because it is available on Wiki-Books... Ok, but where is the link to the info? There are two complete *books* on that page, and I was looking specifically for the different pointer/array/function examples (pointer-to-pointer, pointer-to-array, how modifiers fit into that, etc).

If that sort of information doesn't belong on Wikipedia -- fine. But at least link to more information in WikiBooks if that is why the information is being purged.

68.54.162.15 (talk) 08:33, 30 June 2012 (UTC)[reply]

The following statements are not true:

A corrected statement would read:

• An int can be up to 16 bits long

If no one disagrees within a few days, I'll change those three sentences to similar statements as above and add a reference. --66.41.31.76 (talk) 08:19, 22 September 2008 (UTC)[reply]

No: Those statements are correct. Many C compilers use a 32-bit int nowadays (which is more than 16 bits). The current C standard says (emphasis added):

5.2.4.2.1   Sizes of integer types <limits.h>

The values given below shall be replaced by constant expressions suitable for use in #if preprocessing directives. [...] Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

[...]

• minimum value for an object of type int

  INT_MIN       -32767 // −(2¹⁵ − 1)

• maximum value for an object of type int

  INT_MAX       +32767 // 2¹⁵ − 1

• maximum value for an object of type unsigned int

  UINT_MAX       65535 // 2¹⁶ − 1

Alksentrs (talk) 14:58, 23 September 2008 (UTC)[reply]

I absolutely agree with your response. However, since the definitions of the variables primarily provides clarification to novice programmers, there should be a clear difference stated between the amount of memory allocated and the range of values that are available to the variable.

For example, a novice could read the statement as saying that int x=1 is a value that is too small, and instead a value that is 16 bits, say int x=0x8000 or larger is necessary. With this in mind, I'm assuming one can see how confusion could result, as there is not an explicit divide made between memory allocation and the available range of values for a variable.

Perhaps a separate table should be introduced that explicitly states the range of values available for each of the variable types.
--66.41.31.76 (talk) 06:38, 24 September 2008 (UTC)[reply]

If a novice programmer thinks that 1 is a value that is too low for an int, said person is either stupid or cannot read and listened to someone who is stupid. The reason why the range of integer types is specified is because a computer may not work with binary bits; a computer could in theory, use ternary logic instead of binary logic: to store the range of 16 binary bits using ternary bits would only require 11 bits (and it would have a greater range). The original statements are

• correct
• to the point
• the least confusing it can get without introducing errors or leading new programmers to make even more stupid assumptions about the computer their software will be running on even if they aren't alive when it's being invented.

80.162.60.16 (talk) 12:46, 14 January 2012 (UTC)[reply]

Is not this sentences exclusive?

The only guarantee is that the long long is not smaller than long, which is not smaller than int, which is not smaller than short.

long long signed integer type. At least 64 bits in size.

213.247.248.50 (talk) 02:44, 10 June 2013 (UTC)[reply]

That are two sentences. And they do not contradict each other, they supplement each other. I changed the sentences and hope, they explains it better now. --RokerHRO (talk) 12:41, 9 July 2013 (UTC)[reply]

It needs to be removed. The people defending this know it's wrong because they purposefully misquoted it. It states word for word on page 505 under Annex E of both the C99 and C11 draft,

'ISO/IEC 9899:2011

The contents of the header <limits.h> are given below, in alphabetical order. The minimum magnitudes shown shall be replaced by implementation-defined magnitudes with the same sign.

The values stated below that are simply a template. Common sense, why would the standards committee require there to be a 64-bit data type when most processors don't even have 64-bit registers? All the standard says is that long long shall not be smaller than long, which shall not be smaller than int, which shall not be smaller than short, which shall not be smaller than char. The fact that most modern architectures use short/int/long/long long sizes of 16/32/32/64 does not make it the standard. It's perfectly natural for an 8-bit architecture like an 8080 to use short/int/long/long long sizes of 8/8/16/16. The purpose of wiki isn't to hold the hand of a person who can't understand "x is not smaller than y", it's to provide people with facts.

So frustrated right now... This error just wasted hours of my time trying to figure out how to make a C compiler for an 8-bit architecture conform to C11 and you guys have known this was wrong for over 4 years. — Preceding unsigned comment added by DaemonR (talk • contribs) 08:42, 9 September 2014 (UTC)[reply]

A C compiler supplying a long long that is 16 bits DOES NOT conform to C11. Annex E of C11 specifically states that the limits shown in the table are minimum values; the implementation-defined values are allowed to be greater than the values in Annex E, but never smaller. Annex E also states that it is subject to section 5.2.4.2.1, which makes it explicitly clear that the implementation-defined magnitudes shall (normative language) be equal to or greater than the values shown. The language in C99 is the same. 24.222.2.222 (talk) —Preceding undated comment added 14:12, 18 August 2016 (UTC)[reply]

It's not true there are 4 basic types; that's just the way you've chosen to introduce them. The C90 standard has more like twelve. You don't mention several other built-in types.

C99 introduces long long, complex and imaginary types, and _Bool.

If you think it's worth covering types properly, I'm happy to help. Akihabara 02:55, 12 July 2005 (UTC)[reply]

static is not discussed, and should be. And isn't const also used by compilers when optimizing? If it isn't (i.e. they detect a lack of change on their own) that is interesting enough to mention, IMHO.

static is not a type qualifier, but a storage class 84.163.217.217 (talk) 17:07, 31 August 2008 (UTC)[reply]

If other basic types beyond the basic 5 are mentioned, the time of their introduction (i.e. C99) should be specified. Most books have char, int, float, double, and sometimes void, and lumping "imaginary" in with them would confuse people.

UNIX has programs (cdecl and c++decl) for converting type declarations to and from English.

There is at least one more type: Boolean!
Although it is not possible to declare a variable of that type, the Boolean-type is essential to C! Without it, it would not be possible to write a decent if-statement.

ALbert Mietus // http:albert.mietus.nl —The preceding unsigned comment was added by 62.177.151.49 (talk) 07:41, 2 April 2007 (UTC).[reply]

No. There is no such type in C. If-statements (and the like) test if the condition is nonzero. --Spoon! 08:07, 2 April 2007 (UTC)[reply]

Boolean was introduced in C99, so yes, it does exist, but in C89 it is true that if statements simply check if the test is non-zero or not. --FrederikHertzum 17:40, 15 May 2007 (UTC)[reply]

Also needs to include struct, union and enum. http://en.wikipedia.org/wiki/C_syntax has some info on these. —Preceding unsigned comment added by 119.224.35.68 (talk) 00:32, 31 January 2010 (UTC)[reply]

The table in the Size section lists the typical size in bytes of a (long double) as "8 or 12". I propose changing this to "8, 12, or 16", as 16 is a very common sizeof(long double), as is the case for standard gcc x86-64 on GNU/Linux. --Kamalmostafa (talk) 22:11, 26 November 2010 (UTC) Custom types with typedef! —Preceding unsigned comment added by 88.165.171.247 (talk) 13:57, 24 March 2011 (UTC)[reply]

There are common keywords used together with variable declarations, this includes "static", "volatile", "extern", "auto", "register". Would be nice if someone knowledgeable about all the quirky details covered all of them! 130.237.57.80 (talk) 15:54, 9 March 2011 (UTC)[reply]

See C syntax. --RokerHRO (talk) 16:57, 12 August 2012 (UTC)[reply]

inttypes.h is said to have been merged to this page. However, this page does not seem to have enough information on inttypes.h at least as much as the original page contained. Please fix this.
Jobin (talk) 05:38, 22 October 2011 (UTC)[reply]

I have removed the redirect from inttypes.h and its an article again. I think it should be fixed too, or the article should be merged with limits.h instead. Christian75 (talk) 06:56, 31 October 2011 (UTC)[reply]

Please explain what exactly is not explained in this article that is not also WP:OR. 1exec1 (talk) 14:37, 31 October 2011 (UTC)[reply]

The old page (and/or the <stdint.h> one) had information about which platforms/compilers provide this header. I think that this would be useful information.

BTW, is there any reason to write inttypes.h and not <inttypes.h> as in the standard? (In the standard, this is important, because inttypes.h denotes a filename, while the <inttypes.h> header doesn't need to be implemented as a file.) Vincent Lefèvre (talk) 13:37, 12 August 2012 (UTC)[reply]

There is a move discussion in progress which affects this page. Please participate at Talk:C standard library - Requested move and not in this talk page section. Thank you. —RM bot 09:40, 8 November 2011 (UTC)[reply]

It is not mentioned here at all. :-( Even if you cannot declare objects of type void, this type is used to build-up other types, e.g. pointer or function types. --RokerHRO (talk) 21:47, 26 March 2012 (UTC)[reply]

The C Standard says (6.2.5p19 Types)

The void type comprises an empty set of values; it is an incomplete object type that cannot be completed.

— Preceding unsigned comment added by 81.186.243.41 (talk) 15:37, 26 January 2013 (UTC)[reply]

The ISO C standard describes 3 categories of types:

1. object types
2. function types
3. incomplete types

Than it describes the arithmetical types (_Bool, integer and floating point types), the derived types (arrays, structures, unions, pointer and function) and finally the so-called "type modifier" (const, volatile, restrict, _Atomic).

Unfortunately there is no clear structure or categorization in the ISO standard. Perhaps there is one in other notable C books, if yes we should use one. What do you think? --RokerHRO (talk) 13:46, 10 June 2015 (UTC)[reply]

You propose to structure the article based on the ISO standard and then say it has no clear structure or organization. Why would you want to follow something that lacks structure and organization? How would you follow something that lacks structure and organization? ... Then you mention following books without identifying one ... What is the point of your suggestions? What is the value of following any external doc? Start with the value of making a change then introduce the details of implementation. And if the value is that you like, then that's not compelling. How would the change benefit everyone? not just you. Stevebroshar (talk) 13:31, 10 May 2025 (UTC)[reply]

Type with "anam" were added. But I found nothing about it after a quick search. It seems to be bullshit. A source would be appreciated, otherwise I think that this weird potential type should be removed. — Preceding unsigned comment added by RyDroid (talk • contribs) 17:31, 20 November 2016 (UTC)[reply]

Obvious vandalism. I've reverted the changes from this IP address. Vincent Lefèvre (talk) 17:52, 20 November 2016 (UTC)[reply]

It may not be standard C but is it worth talking about it anyway? It is a type of 24 bits for some embedded systems. — Preceding unsigned comment added by 69.70.87.250 (talk) 19:41, 10 August 2017 (UTC)[reply]

I don't think it is worth mentioning uncommon extensions. BTW, this way of defining a new integer type is very ugly. A 24-bit type on such a system should have been named int24_t. Vincent Lefèvre (talk) 21:31, 10 August 2017 (UTC)[reply]

There are still some types not mentioned in the article which would merit it IMHO like off_t and time_t, which are at the same time

• present in the POSIX standard (see pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html)
• deeply rooted in tradition (look at the 33-year old SysVr2.0_32000/src/uts/ns32000/sys/types.h in archive.org/download/ATTUNIXSystemVRelease4Version2/SysVr2.0_32000.tgz)
• used by Linux, a system of high real-world notability (as in git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/include/linux/types.h)

--212.185.199.2 (talk) 15:31, 12 February 2018 (UTC)[reply]

The draft for C2x includes requiring 2's complement. The future is now. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf

Maybe this should be noted in the section about int ranges. Wqwt (talk) 07:28, 15 October 2021 (UTC)[reply]

@Johann-Tobias Schäg I have reverted your edit about the signed integer sizes. What was written was correct, since as the note (C data types#cite note-restr-5) says this is exactly the range guaranteed by the C standard. Twos complement is not guaranteed but is drafted for C2x. Wqwt (talk) 08:18, 9 August 2022 (UTC)[reply]

BTW, I think that it should be decided what to do when C23 is published. I suppose that the ranges will be updated. But for historical purpose, the alternative signed number representations and the old minimal ranges should still be given somewhere (perhaps in a more concise form). — Vincent Lefèvre (talk) 13:22, 9 August 2022 (UTC)[reply]

In the table that lists and describes the data types, couldn’t there be a column with examples of data types so newcomers to C don’t get confused or mix any of them up? Like, obviously a char would be only a single character like ‘c’, ‘S’, ‘3’, or ‘#’. But a float, is it strictly a ~number~ in the decimal place (0.75), or can it be greater (6.432)? See what I mean? 98.216.67.148 (talk) 02:14, 1 October 2022 (UTC)[reply]

This article was the subject of an educational assignment supported by Wikipedia Ambassadors through the India Education Program.

The above message was substituted from {{IEP assignment}} by PrimeBOT (talk) on 19:58, 1 February 2023 (UTC)[reply]

The article should really include additional historical context about why these types are specified the way they are, as modern readers may not be familiar with the multiplicity of byte widths, word lengths, and sign representations that existed in the 1980s when X3J11 was trying to specify a set of data types that was common to historic PDP-11 and microcomputer implementations, 32-bit and 36-bit mainframes, and supercomputers. By comparison, many newer languages provide only bit-precise types (and have no support for, e.g., 9-bit characters, because 36-bit architectures are now historical relics). 207.180.169.36 (talk) 18:41, 19 November 2023 (UTC)[reply]

YES PLEASE! Also, publish the name of the bloke who defined a char to possibly be negative! Need to 'praise' him every-singe-day! — Preceding unsigned comment added by 115.70.29.185 (talk) 16:18, 4 March 2024 (UTC)[reply]

Yes, I saw the open-std pdf saying that LONG_MIN equals to -2147483647. But this PDF is a draft (and a draft can contains errors). The minimum value of a n bits signed integer (signed bit excluded) is in decimal - 2^n, so -2147483648, not -2147483647. I don't care what the open-std pdf says, it's wrong in my opinion. If you set the minimum value to -2147483647 and not to -2147483648, then you have one too many binary values, which is 10000000 00000000, what would you do with such a binary ? have two zeros one positive and one negative ? if so why not three or four ? come on, I hope you are not stupid people.. . So this open-std pdf doesn't seem to be without error, thus wikipedia shouldn't use it as a primary source of information. — Preceding unsigned comment added by 163.5.23.68 (talk) 17:05, 13 March 2024 (UTC)[reply]

See ones' complement arithmetic, which was until recently a permissible representation for signed integers. 207.180.169.36 (talk) 04:28, 14 March 2024 (UTC)[reply]

Moreover, the PDF does not say that "LONG_MIN equals to -2147483647", just that LONG_MIN is greater than or equal to the given value in magnitude, with the same sign, that is, in the case of LONG_MIN: LONG_MIN ⩽ -2147483647. The value -2147483648 satisfies this inequality. — Vincent Lefèvre (talk) 12:35, 14 March 2024 (UTC)[reply]

The chart of types sizes lists 'int' as 16 bit (between -32,767 and 32,767), in almost all places int is 32 bits (I have never seen it as 16 bit but I assume it is in older versions?).

If it is really mostly 16 bit, I think a comment "32 bit on some systems" or something like this can be added, or even change it to "16/32" (and change the explanation accordingly) Eylon Shachmon (talk) 01:41, 18 April 2024 (UTC)[reply]

That column is titled "Minimum size" so 16 is correct. Dexxor (talk) 09:40, 18 April 2024 (UTC)[reply]

I was just wondering which section of the Standard specifies the minimum values of the unsigned integer types to be $0$?

The closest I could find was §6.2.6.2 Integer types on [page 41](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf#page=60) of the C23 working draft, which says:

> If there are $N$ value bits, each bit shall represent a differentt value of $2$ between $1$ and $2^{N-1}$.

Is this the correct section? 115.188.121.25 (talk) 03:40, 18 June 2024 (UTC)[reply]

Yes, the minimum value of the unsigned integer types is implied by the specified representation of such a type. If all the value bits in the representation are 0s, then the value is necessarily 0. And obviously, negative values are not possible. Therefore, the minimum value is 0. — Vincent Lefèvre (talk) 08:48, 21 June 2024 (UTC)[reply]

The table only shows the minimal size of each type, which is rather unhelpful (and also confused the google summery answer into saying it is the size), potentially add a column for "normal size" or something like it (or maximum size if such a thing exists)

Eylon Shachmon (talk) 15:23, 29 November 2024 (UTC)[reply]

I don't think that one can say that there is a "normal size" (or usual size), even for 64-bit platforms: 64-bit data models. — Vincent Lefèvre (talk) 23:25, 29 November 2024 (UTC)[reply]

WRT "In the C programming language, data types constitute the semantics and characteristics of storage of data elements. They are expressed in the language syntax in form of declarations for memory locations or variables. Data types also determine the types of operations or methods of processing of data elements."

There's an article for data type, rather than saying what a data type is, just link to it.

This is basically a list article even though it's not titled that way. I think the intro should be something like: This article lists the data types of the C programming language. It should be titled like "List of C data types" Stevebroshar (talk) 13:42, 10 May 2025 (UTC)[reply]

I am seeking requests for comments on the alignment of the pointer asterisk on this page. This was previously discussed at Wikipedia talk:WikiProject Computer science#C/C++ pointer asterisk and null checks on "standardising code style" across Wikipedia, but essentially no meaningful conclusion was reached: other editors only dismissed the idea of standardising the code. For this reason, I am taking it directly to the talk page to discuss whether we should use left-alignment or right-alignment of pointers.

• Left-alignment: Type* a;
  • Proponents of left-alignment will argue that the implication is that a is of type T*.
• Right-alignment: Type *a;
  • Proponents of right-alignment will argue that the implication is that *a is of type T.

Left-alignment is seemingly most popular in C++, while right-alignment is seen in older C code (don't quote me on this, this is a rough estimate, but anecdotally I have seen a more even split between left and right alignments in C code).

I personally support using left-alignment, for the following reasons:

• The page is about data types. Pointers are indeed a type in C, the parser will read int* x; (or int *x;) as x having type int*.
• Continuity with C++, where left-alignment dominates. While C is obviously distinct from C++, the contents of this page just as well apply to C++ and are relevant to it. Whereas in C, there is a more event split between left and right alignment, so nothing would be lost really.
• There are cases where right-alignment can imply essentially meaningless statements. For example, void *x would imply *x is of type void, but void does not have any storage in memory and represents an absence. The use of void* in C is to represent a pointer that may point to any type.
• There are places where the alignment of the pointer is potentially misleading. Take, for example:

struct Link {
    void *data; // data of this link
    struct Link *next; // next link; EMPTY_LIST if there is none
};

This could easily be interpreted as sizeof(Link) consisting of sizeof(void) (meaningless) and sizeof(Link), rather than sizeof(void*) + sizeof(Link*), which is far clearer due to the attachment of the pointer. This example may be more contrived, but I think that it nonetheless is still worthy of consideration for the reader. Obviously it is fair to assume the reader has some competency in programming, but I do think clarity is best and there is nothing lost in clarity by using left alignment, rather than divergence from some existing standards (such as Linux kernel style or K&R which to be honest has some very out-of-date practices). 24.50.56.74 (talk) 17:10, 22 October 2025 (UTC)[reply]

• Oppose - I think leave code style up to local article-level consensus and organic what comes out of references. I do not think that one convention should or could be enforced from outside -- we don't know all the circumstances and the feasibility of making it happen -- and I'm kind of against making yet more MOS. I also have seen retroactive changes elsewhere (i.e. capitalisation guidelines changing at MOS:JOBTITLE) and it just never gets changed everywhere -- certainly I was not going to undertake it -- and new edits occasionally go the other way since ordinary authors seem unlikely to know of the external MOS so do not reliably conform. This one just seems not an issue needing wiki-wide guideline or having the WP:CONSENSUS nor external dominance to be a wiki-wide MOS, but maybe an Essay level article for consideration. Cheers

Markbassett (talk) 21:10, 22 October 2025 (UTC)[reply]

It sounds like you are responding to the concept of proposing standardisation of code style, but this is not a proposal to standardise coding conventions, it is a request for comments on whether to align the asterisk left or right. 2605:8D80:1391:EE1E:39B2:8822:ED56:E98E (talk) 15:25, 23 October 2025 (UTC)[reply]

• Bad RfC Five minutes earlier, the same IP user started a very similar (only two paragraphs differ) RfC at Talk:Pointer (computer programming)#RFC on Pointer alignment in examples, and earlier than that, a related one at Talk:C (programming language)#RFC on Placement of opening bracket, which has since been closed. I will copy here some of my comments from that RfC:
  When you write your own C programs, you can lay it out however you like. If you are at a university, they may teach you one way; another university might teach a different way. Neither of them is wrong. The only time that it "matters" is when you work for a company that has house style rules and you're sharing code with a programming team.
  To this I will add that we should not be seeking to prescribe one way over another. --Redrose64 🌹 (talk) 05:56, 24 October 2025 (UTC)[reply]

  What is your point? No one is claiming that placing the asterisk differently affects the resulting compiled program. The argument being made here is about clarity to the reader. 24.114.61.148 (talk) 15:36, 24 October 2025 (UTC)[reply]

• Oppose – Wikipedia is not a code repo with a clear maintainer, and how to standardize pointer alignment across the wiki will just lead to flame wars with no end. Per this, and per your own words, I have seen a more even split between left and right alignments in C code, I see no need for this. NasssaNser 04:33, 26 October 2025 (UTC)[reply]

  This is not an RfC on standardisation, this is an RfC on where to apply it on this page specifically. There are other RfCs on where to place it on other pages, but it is by no means standardising code across Wikipedia. Before trying to quote me I have seen a more even split between left and right alignments in C code, did you even bother to read it? If so you would not claim this RfC is about how to standardize pointer alignment across the wiki. 2605:8D80:6C28:F33C:8C47:F9A6:F925:9A94 (talk) 15:42, 26 October 2025 (UTC)[reply]

  I have read this, yes, but as noted by Redrose64 you have opened another RFC with almost identical content at Talk:Pointer (computer programming)#RFC on Pointer alignment in examples, which makes me think you are actually intending to standardize this across the wiki.

  As a side note, I prefer Type *a, but that's unrelated to my argument. NasssaNser 02:42, 27 October 2025 (UTC)[reply]

  Also, before opening your next RFC on pointer style on the next page, you can just be bold and reformat the code yourself. I will not revert these. NasssaNser 02:47, 27 October 2025 (UTC)[reply]

• To put this RFC in context, there was a suggestion in Wikipedia talk:WikiProject Computer science#C/C++ pointer asterisk and null checks : an WP:ENGVAR style approach where the styling is decided on a per-article level is the way to go here. So, my opinion is that if a style is decided for this page (which is about the C language), the usual style Type *a; for C code should be used. — Vincent Lefèvre (talk) 17:52, 26 October 2025 (UTC)[reply]

  I do not think reader clarity is worth sacrificing for dogmatic orthodoxy to a prescribed coding style, even assuming right-alignment were more prevalent in C. Left-alignment emphasises the pointer quality of the symbol, and is more intuitive to the reader, seeing as this is an article about data types in C (which includes pointers, and indeed compilers recognise pointer types) rather than a style guide on C pointer placement or a page debating whether int* a is parsed as typeof(a) = int* or typeof(*a) = int. 2605:8D80:1391:3A80:9DA9:B1EB:F02B:E (talk) 01:02, 27 October 2025 (UTC)[reply]

  Considering no one else seems to be interested in participating in the talk page, I will give you another day or two before I proceed with these changes. 2605:8D80:1395:18AF:C01:9946:449F:5185 (talk) 22:38, 31 October 2025 (UTC)[reply]

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following list: Maths, science, and technology When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

There have been lengthy disputes (as seen in the above, however apparently as there was no RfC tag it did not count) about how to format the code examples here, particularly pointer alignment.

Should left or right pointer alignment be applied here? Should the example for a "birthday" be capitalised (i.e. struct Birthday or struct birthday)?

This is NOT an RfC about "standardising style across Wikipedia".

Pinging previously involved parties: @Vincent Lefèvre @Taylor Riastradh Campbell ~2025-36699-87 (talk) 21:04, 15 December 2025 (UTC)[reply]

As this was already discussed extensively before, it is appropriate to immediately begin an RfC.

I personally support using left-alignment, for the following reasons:

• The page is about data types. Pointers are indeed a type in C, the parser will read int* x; (or int *x;) as x having type int*.
• Continuity with C++, where left-alignment dominates. While C is obviously distinct from C++, the contents of this page just as well apply to C++ and are relevant to it. Whereas in C, there is a more event split between left and right alignment, so nothing would be lost really.
• There are cases where right-alignment can imply essentially meaningless statements. For example, void *x would imply *x is of type void, but void does not have any storage in memory and represents an absence. The use of void* in C is to represent a pointer that may point to any type.
• There are places where the alignment of the pointer is potentially misleading. Take, for example:

struct Link {
    void *data; // data of this link
    struct Link *next; // next link; EMPTY_LIST if there is none
};

This could easily be interpreted as sizeof(Link) consisting of sizeof(void) (meaningless) and sizeof(Link), rather than sizeof(void*) + sizeof(Link*), which is far clearer due to the attachment of the pointer. This example may be more contrived, but I think that it nonetheless is still worthy of consideration for the reader. Obviously it is fair to assume the reader has some competency in programming, but I do think clarity is best and there is nothing lost in clarity by using left alignment, rather than divergence from some existing standards (such as Linux kernel style or K&R which to be honest has some very out-of-date practices).

~2025-36699-87 (talk) 21:18, 15 December 2025 (UTC)[reply]

You should not be editing the article in relation to this discussion.

The edit in question is this one [1] with the message:

LinkedList is a clearer name than just "node", and the page had a capitalised B prior and this was also shown in the article itself which writes struct Birthday before the code snippet.

There are two points.

LinkedList is a clearer name than just "node"

Personally, I think LinkedList is less clear, and more suited for a struct that contains the head of a list, along with some auxiliary data, like the length. The structure represents a node so calling it a node makes sense to me. That being said, this is a minuscule part of the article that should probably just be removed.

the page had a capitalised B prior and this was also shown in the article itself which writes struct Birthday before the code snippet.

Here you are simply being dishonest. The birthday struct was added in 2011 [2] and from what I can see it was lowercase until this September 2025 [3] when you changed in. It just took time for people to notice the edit and when it was reverted one uppercase "B" was left behind. Please be honest. — xo Ergur (talk) 08:24, 17 December 2025 (UTC)[reply]

Keep as is: Personally, I would use neither style, but I see no reason to change it. These changes are awash. In a year someone will change it back et c., further wasting everyone's time. — xo Ergur (talk) 21:37, 15 December 2025 (UTC)[reply]

They were originally one way before this change, when I made updates to the page, which is why I would like to have it restored. There are also certain practices that stick out like a sore thumb (such as struct birthday being lower case, when this does things like make it harder to distinguish it at a glance whether this is a type or a variable), etc. ~2025-36699-87 (talk) 21:48, 15 December 2025 (UTC)[reply]

To me, struct Birthday doesn't look like C. This is all personal preference and you should just get used to looking at other people's preference. Right now, you are wasting everyone's time (including yours). — xo Ergur (talk) 11:08, 16 December 2025 (UTC)[reply]

To me, struct Birthday doesn't look like C. What does it look like instead? Right now, you are wasting everyone's time (including yours). I don't know what these kinds of comments are intended to accomplish, because it certainly is not going to shut down this conversation. ~2025-36699-87 (talk) 17:52, 16 December 2025 (UTC)[reply]

What does it look like instead?

How is this question relevant to the discussion? Why does it have to look like anything? The point is it doesn't look like C to me.

And that's the thing; It's just personal preference. The most you can appeal to is style guides and how it is done in bigger projects. Looking at some structs in the citations provided by @Taylor Riastradh Campbell, I only see structs with lowercase names. — xo Ergur (talk) 07:53, 17 December 2025 (UTC)[reply]

Keep as is: Well established style, no reason to change it. — Vincent Lefèvre (talk) 01:31, 16 December 2025 (UTC)[reply]

You agreed that struct Birthday would remain as is and would not be lowercased, and yet changed this too. You also reverted {{code}} to {{mono}} despite the fact that INT_MAX, INT_MIN, are not raw text but macros in code. ~2025-36699-87 (talk) 04:30, 16 December 2025 (UTC)[reply]

Keep as is: This anonymous editor's idiosyncratic style preferences have been noted. This is a huge waste of everyone's time. It has no basis in the actual structure of the C syntax,^[1] which leads to misleading interpretation of declarations like int* x, y; (in C, x is a pointer and y is an integer; if it were C# the story would be different, but this is an article about C). The anonymous editor has provided no citations about actual usage or style recommendations in practice, in contrast to the usage in the modern C23 standard^[2][3] and major active modern C software projects like the Linux kernel.^[4][5][6][7]

Side note: Several IP addresses and temporary accounts (24.50.56.74, 2605:8D80:6C28:F33C:8C47:F9A6:F925:9A94, 2605:8D80:5825:1532:5DE4:1E00:1EF2:C0F3, 2605:8D80:5825:1532:D58:188C:5434:D54, ~2025-40797-91, ~2025-36699-87) have been pushing essentially the same changes, for the past several months, making comments as if they are the same person, overriding discussions in the talk page, litigating on WP:DNR, and receiving criticism for abuse of process, personal attacks, and edit warring and copyright violations. Is this all the same person? Taylor Riastradh Campbell (talk) 03:03, 16 December 2025 (UTC)[reply]

Yes, it is the same person, me. I've never hid this fact. I don't know what any of that stuff has to do with this. Do you suppose I have anything to be afraid of by bringing this up? Wikipedia isn't a political election and if you think digging out past conflicts I've been involved in will produce some sort of hit piece, then I am afraid you are mistaken. And bringing up WP:DNR to imply that I am a "vandal" or "troll" is precisely why I accused you of deceptive behaviour. You also tried to allege that I engaged in edit wars based on what was supposedly on my talk page, while conveniently ignoring that these were predicated on misunderstandings. Do you think bringing up the copyrighted material incident on Java Platform Module System has any weight on my image? Or did you bring this up only to try and humiliate me? ~2025-36699-87 (talk) 04:29, 16 December 2025 (UTC)[reply]

There are reasons people frown on multiple variable declarations per line, and are frowned upon in code.^[8] In reasoning for these it is brought up explicitly that this is because of int* x, y; being interpreted as int* x, int y. As for your claim that there is no basis in the structure of C's syntax, this is unequivocally untrue as compilers parse T *x; as x having a pointer-to-T type, or T*.^[9] They do NOT parse it as *x having type T, which would imply void *x; has type void and stores void in memory.

And what's this gospelisation of the Linux kernel's style guide? By that logic we ought to indent code with eight spaces.^[10] ~2025-36699-87 (talk) 04:47, 16 December 2025 (UTC) ~2025-36699-87 (talk) 04:47, 16 December 2025 (UTC)[reply]

By that logic we ought to indent code with eight spaces.

We could, in fact, indent code with eight spaces, and it would be a perfectly fine style choice.

We could even cite the Linux (or BSD) style guide to support that choice. (But citing a C++ style guide—actually, the personal style guide of C++'s creator—to argue for C style choices might miss the mark.)

De gustibus non disputandum est: only with gusto can taste be argued. Taylor Riastradh Campbell (talk) 14:51, 16 December 2025 (UTC)[reply]

I see that you addressed the fact that I cited one of Bjarne's writings yet conveniently omitted the overwhelming majority of that paragraph. ~2025-36699-87 (talk) 17:56, 16 December 2025 (UTC)[reply]

You're not entitled to other editors' time at your whim, and this molehill is already mountainous heights. But, if this is the molehill you want to die on, I'll humour you with your own reference, which also, incidentally, uniformly uses T *x; style.

The source you cited (which is a defunct vendor's compiler manual, but it matches the modern C standard well enough, so it's not wrong) shows that the sequence of tokens T * x , * y ; breaks down into a type-specifier T followed by an init-declarator-list of two pointer declarators * x and * y. That is, in the grammar you cited, the asterisk is grouped with the variable, not with the type.

As for the notion that after void *x; the expression *x would have type void which must be nonsensical, well, you're right: dereferencing x in that case is nonsensical—so it is forbidden. The type is nevertheless called “pointer to void” in the modern C standard,^[2]: 40 and this reading of T *x; suggesting that *x has type T is exactly how C was designed according to the designer Dennis Ritchie:^[1]: 7

Analogical reasoning led to a declaration syntax for names mirroring that of the expression syntax in which the names typically appear. Thus, int i, *pi, **ppi; declare an integer, a pointer to an integer, a pointer to a pointer to an integer. The syntax of these declarations reflects the observation that i, *pi, and **ppi all yield an int type when used in an expression. Similarly, int f(), *f(), (*f)(); declare a function returning an integer, a function returning a pointer to an integer, a pointer to a function returning an integer.

You and Bjarne Stroustrup may have different opinions about whether this was a good design, and you are welcome to take a different approach in C++ or C# or other languages. Other options like int * x; and int*x; also appear in the wild. But Wikipedia isn't the forum for imposing your personal style preferences on the world. Taylor Riastradh Campbell (talk) 03:45, 17 December 2025 (UTC)[reply]

Very well then, perhaps that applies on this page. But seeing as in your own words you are welcome to take a different approach in C++ or C# or other languages, these same arguments are limited to the scope of C, and do not apply to other languages. And for that reason, pages like Pointer (computer programming) and Union type, which talk about general programming concepts and not "pointers in C" and "unions in C", are not constrained to these. ~2025-36699-87 (talk) 05:12, 17 December 2025 (UTC)[reply]

• @~2025-36699-87: You state as there was no RfC tag it did not count - what would you call this edit then? --Redrose64 🌹 (talk) 23:04, 17 December 2025 (UTC)[reply]