__np_anyptrlt

Random832: re your edit summary: "We don't really need to care if this is meaningful for pointers not to the same object, as long as it doesn't, say, trap". I'm not sure what you mean here - memmove is defined for such pointers, and this is used in memmove. --Netocrat 03:58, 21 March 2006 (UTC)

Yeah, but which direction memcpy iterates in doesn't matter unless they are unequal pointers to the same array. The problem with the bare comparison itself is that it results in undefined behavior, which could be much worse than just returning an arbitrary value. --Random832 04:08, 21 March 2006 (UTC)

In other words, we don't need 4000:0002 to compare less than 5000:0001, if the implementation only generates these values for pointers into different objects. So an x86 implementation could do offset-only comparison for relational operators and reserve the possibly slightly more expensive segment-offset comparison for the equality operator. We just need it not to crash when passed 4000:0002,5000:0001.

Comprehensive and cross-referenced

Let's not add anything to the page until it can be referenced back to where's it's being used (I've moved a lot of stuff in to this talk page based on that).

I've reverted 'size_t and all headers where it is declared' to 'string.h' on this basis too.

For ease of linking here (see e.g. how memmove links to __np_anyptrlt), let's keep braces out of the section headings too, or provide an anchor in the heading. --Netocrat 06:39, 21 March 2006 (UTC)

Future content

I've temporarily moved this in here since I don't think anything should be added to the page until used elsewhere. --Netocrat 06:39, 21 March 2006 (UTC)

__np_morecore (n)

A macro or function that returns a pointer to at least n bytes of new memory. This identifier occurs in the implementation of:

• realloc

__np_lesscore (p)

A macro or function that, if applicable, releases a pointer obtained from __np_morecore back to the operating system. This identifier occurs in the implementation of:

• realloc

__np_fildesc_t

A typedef other than an array type which contains the information that is needed to identify a file to the operating system. This identifier occurs in the implementation of:

possible fix for linking problem

Why not use _NP instead of __np? --Random832 04:24, 22 March 2006 (UTC)

Uppercase is often reserved for macros only. Let's stick to that convention. When an identifier is (or could be) a typedef, function or variable name, let's make it lowercase (__np) and when necessarily a macro, use uppercase (_NP). I've added this to the article under "Naming conventions". If we're all agreed, let's add it to as a general style convention at Clc:Policies and Conventions. --Netocrat 20:32, 22 March 2006 (UTC)

all-uppercase is reserved for macros - there's no reason we can't use _NP_identifier for functions and _NP_IDENTIFIER for macros. _NP keeps us in the reserved namespace and fixes the linking problem. --Random832 05:58, 23 March 2006 (UTC)

There's no reason other than aesthetics - I find the mixed caps of _NP_identifier unappealing. I'd prefer to go with easier-on-the-eye than easier linking - they'll be read more often than written. --Netocrat 10:19, 30 March 2006 (BST)

Description of article edit 22 March 2006

__STDC_VERSION__

I moved this in from the article where the wording was:

In C89, __STDC_VERSION__ can be defined any way. We define it here to be undefined in that case, so it can be reliably used to check for the implemented revision of the standard. BTW: Even though C89 could in theory be detected portably using e.g. SIZEMAX, this macro is of fundamental importance, so it shall be here.

Here's why: it doesn't fit the purpose of this page, which is to comprehensively list identifiers encapsulating non-portabilities (and possibly inconsistencies between versions of the Standard). This identifier is defined by the Standard in all but the first version though, and it's not prefixed by __np or _NC or any other non-portable indicator. --Netocrat 20:32, 22 March 2006 (UTC)

Granularity

I also moved this in from the article (in the non-consistent identifiers description):

This solution also provides finer granularity where applicable, say, to support an implementation that provides incomplete c99 features.

Here's why: it's not yet clear that this is necessary; add it in if/when it becomes so (in keeping with the philosophy that this page should be comprehensive and cross-referenced - if it's not used yet, add it as an idea to this talk page, not the article itself). --Netocrat 20:32, 22 March 2006 (UTC)

Which vs that

I've generally change 'which' to 'that' as I find it clearer to use 'that' where possible and to reserve 'which' for differentiating alternatives e.g. in a question. --Netocrat 20:32, 22 March 2006 (UTC)

Avoiding redundancy

I've moved the description of __np_anyptrlt to memmove to avoid redundancy but haven't done it for the others since it's clear they'll be used elsewhere and we'd only need to move the description back again later. --Netocrat 20:32, 22 March 2006 (UTC)

NC_RESTRICT

Wouldn't it make more sense to define it to an empty expansion on implementations that don't support restrict? --Random832 19:32, 4 May 2006 (BST)

If you mean replace #undef _NC_RESTRICT with #define _NC_RESTRICT, that does seem more logical. Better that #ifdef _NC_RESTRICT evaluate true even when the macro is empty. --Netocrat 05:42, 5 May 2006 (BST)