Old alignof Macro for C89 Broken as C23 Extension

[Sha0]

Please consider the following offsetof.c file:

~ $ cat offsetof.c 
/*
 * Compiler:

~ $ gcc -v
clang version 19.1.4
Target: aarch64-unknown-linux-android24
Thread model: posix
InstalledDir: /data/data/com.termux/files/usr/bin

 * Error:

 ~ $ gcc -ansi -pedantic -Wall -Wextra -Werror -o offsetof offsetof.c 2>&1
offsetof.c:27:21: error: defining a type within 'offsetof' is a C23 extension [-Werror,-Wc23-extensions]
   27 |     return offsetof(struct { char c; }, c);
      |                     ^~~~~~
/data/data/com.termux/files/usr/lib/clang/19/include/__stddef_offsetof.h:16:43: note: expanded from macro 'offsetof'
   16 | #define offsetof(t, d) __builtin_offsetof(t, d)
      |                                           ^
1 error generated.

 * Why?
 */
#include <stddef.h>

int main(void)
  {
    return offsetof(struct { char c; }, c);
  }

A relevant portion of C89 for stddef.h is:

[...] and

         offsetof( type,  member-designator)

which expands to an integral constant expression that has type size_t,
the value of which is the offset in bytes, to the structure member
(designated by member-designator ), from the beginning of its
structure (designated by type ). The member-designator shall be such
that given

         static  type t;

then the expression &(t.  member-designator ) evaluates to an address
constant.  (If the specified member is a bit-field, the behavior is
undefined.)
[...]

The clang error-message reports a "C23 extension." It is now December, 2024. At least 12 years ago, this "code-snippet" was produced:

• https://ideone.com/wL6wm
• (linked to from the https://www.iso-9899.info/wiki/Code_snippets page)

It uses an alignof macro shared by Mr. Chris M. Thomasson in Usenet (probably the comp.lang.c section) from before that time, which is something like:

#define alignof(type) (offsetof(struct {char c; type t;}, t))

I suspect that similar macros have been in use for much, much longer, but I could be mistaken.

If we are invoking clang in a C89 mode and we interpret the quotation above as authoritative, then I perceive that the type used within the offsetof macro in the code-file (shared far above) meets the "static type t;" condition and I do not perceive a C23 extension being relevant to such old usage.

Is this an opportunity for improvement?

[AaronBallman]

It's a bit of a complicated situation; traditional offsetof only allowed defining a new type if everything aligned properly, not as a general mechanism. Consider this traditional definition of the macro: #define offsetof(TYPE, MEMBER) ((unsigned long) &((TYPE*)0)->MEMBER) and now consider it in the presence of commas, as in: https://godbolt.org/z/8oq8ejeY5

C23 made it more clear that specifying a type name which contains a comma (not between matching parens) is explicitly UB. Because Clang implements offsetof via __builtin_offsetof, we can support defining a type there: https://godbolt.org/z/e4P5YdWMP However, it is technically an extension to do so.

The command line you're passing includes -pedantic and the purpose of that is to diagnose extensions. Hence, this gets diagnosed as an extension now.

Note, the alignof macro you pointed out has the same problem in the presence of commas as the old-style offsetof macro does: https://godbolt.org/z/1YbqGjr5b

I don't think there's much to be done here, so closing the issue as not a bug. However, if you want to continue the discussion, feel free to reopen the issue with more thoughts.

[Sha0]

@AaronBallman: Thank you for your reply. I'm disappointed in the decision.

The implementation of offsetof is opaque to the programmer. The programmer expects to invoke the implementation in C89 mode and get C89-specified behaviour. I disagree that a C23 extension has any relevance to C89. I recommend warning users that Clang does not fully support C89, in order to lower expectations that it'll permit ancient code to compile without "pollution" from modernity.

I suspect that any programmer who has never run afoul of offsetof and commas due to an implementation's failure to #define offsetof in such a way as to meet C89 (à la __builtin_xxx, for example) is not a programmer of the old code that's worked for many years and so is unlikely to be impacted. I suspect that programmers who have run afoul of this are using semi-colons in their struct-declarations.

[AaronBallman]

The implementation of offsetof is opaque to the programmer. The programmer expects to invoke the implementation in C89 mode and get C89-specified behaviour.

This was UB in C89 too, so it was an extension there as well (when it worked at all) and should have been diagnosed under -pedantic. The diagnostic says "is a C23 extension" only because this was clarified in C23; otherwise it would have read "is a Clang extension" instead. For example, only one compiler manages to handle commas in the type definition within offsetof: https://godbolt.org/z/3bW6aG6EM

I recommend warning users that Clang does not fully support C89

To be clear, Clang does fully support C89, this improved strict conformance mode which you opted into explicitly by passing -pedantic.

I suspect that programmers who have run afoul of this are using semi-colons in their struct-declarations.

I agree, but the point to -pedantic is for the programmer to be alerted to use of extensions and accepting a type definition in offsetof is an extension.

[Sha0]

@AaronBallman: Thank you for your reply.

I could be missing an important detail, somewhere...

I'm not using commas in the code that has run afoul of this issue. I think we're in agreement that if a programmer tries to use a comma within the arguments to a function-like macro, they had better go back and use a semi-colon, instead. Hopefully I understand correctly that "supporting commas in the types used with offsetof" is the C89 UB that you've just noted in your previous response.

If we can lay the "commas" situation to rest and consider only the "defining a type within 'offsetof' is a[n] [...] extension" aspect, I suppose this could be where I'm missing something. To the best of my knowledge, I've provided a quotation from C89 in the original post. I do not yet perceive any UB nor need for an extension.

Here is the relevant code:

offsetof(struct { char c; }, c);

Applying the C89 quotation, we'd then interpret:

• type: struct { char c; }
• member-designator: c

The quotation also permits us to interpret further that for:

static struct { char c; } t;

the following expression needs to yield an address constant:

&(t.c)

Otherwise, the behaviour is undefined by violation of "shall."

Given that this all works out for the specific example, I fail to perceive any C89 UB nor a need for an extension. That is, it seems to be well-defined, unless I am missing another detail. The name of the header is "stddef.h", which I've always imagined represents the words "standard definitions."

I suspect that if Clang is using an extension in this context, it is doing so contrary to what a C89 programmer would expect: that no extension is required for this well-defined C89. I wouldn't expect to invoke an extension for any other well-defined code, either. I'm sure there are advantages to using the extension in the implementation, but a distinct disadvantage would seem to be that correct C89 code is not supported without the extension, which is why I've recommended lowering expectations for Clang and C89.

I haven't read C23, but is it not simply the case that:

• in C23, "defining a type in a function-like macro argument" gets a different consideration than in C89, or perhaps specifically in the context of offsetof
• Clang uses an extension in the definition of offsetof
• Clang uses that same definition in both C89 and C23, for the sake of simplicity
• the result is an anachronism against C89 (and the root of my complaint)

Please consider this code:

~ $ cat ana.c
/*
 * Compiler:

~ $ gcc -v
clang version 19.1.4
Target: aarch64-unknown-linux-android24
Thread model: posix
InstalledDir: /data/data/com.termux/files/usr/bin

 * No error:

 ~ $ gcc -ansi -pedantic -Wall -Wextra -Werror -o ana ana.c 2>&1
*/
#include <stddef.h>

#define make_a_struct(macro_arg1, macro_arg2) macro_arg1 macro_arg2

int main(void)
  {
    make_a_struct(struct { char c; }, s);

    return (char *) &s.c - (char *) &s;
  }

Here again we have a type definition appearing in a function-like macro's argument. This does not appear to invoke any extension. Why should it "suddenly," for offsetof?

Perhaps it would be very difficult to rework the "extension-usage" logic to include a special case? For example, "OK, we're using the __builtin_offsetof extension, but we're in C89 where no extension is expected, but we don't want to have 1 C89 offsetof versus everyone else's offsetof, so we're going to special-case this and lie about it as not involving an extension." Or perhaps stddef.h could check for C89 mode and use a more "historical" definition for offsetof? Ultimately, I still believe the implementation details should be opaque to the C89 programmer, so the "lie" would be acceptable.

If I've missed some part of C89 which makes the code explicitly UB, I'd be grateful for enlightenment and apologetic about my ignorance.

Thank you for your kind engagement in discussion about this issue, @AaronBallman.

[AaronBallman]

I'm not using commas in the code that has run afoul of this issue. I think we're in agreement that if a programmer tries to use a comma within the arguments to a function-like macro, they had better go back and use a semi-colon, instead. Hopefully I understand correctly that "supporting commas in the types used with offsetof" is the C89 UB that you've just noted in your previous response.

The situation isn't necessarily clear-cut and you could argue it either way (in an ideal world, I think we'd only issue the diagnostic in the case where there's a comma not between matching parentheses). The reason it's UB is where this gets messy because it doesn't fit the usual UB situations (standard explicitly says "undefined behavior", violation of a "shall", etc). In general, you can define a type where one is spelled unless otherwise noted, and older standards modes did not note anything special about offsetof. C89 (and other versions of the standard) have wording that says:

The member-designator shall be such that given static type t; then the expression &(t.member-designator) evaluates to an address constant.

which further reinforces the idea that the type could be defined inline. e.g., static struct S { int x, y; } t; is valid code. However, defining a type in offsetof in general is not possible due to the comma problem; you can only define a type if you manage to do it just right. So there was a bug in the specification in that we forgot to limit the types you can define; it's UB by omission.

DR496 covered this with the questions:

• Does C intend to permit defining a new type as the type operand?
• If C does intend to permit defining a new type in offsetof expressions, does it intend to permit defining arbitrarily complex types such as the one below?

to which the committee responded:

Although the committee believes that allowing this for unions was originally intended, there was no opinion expressed that allowing new type declarations was intended. So the answers to questions in the first two bullet points are yes, and to the third, no, and the fourth is moot.
There was no intent to allow new types to be declared in an offsetof expression.

Now, in C23 and later, you can define a type only if it does not contain a comma. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm was adopted in C23 and made it UB to ever define a type in offsetof. DE-137 then relaxed this to only types with commas during NB comment resolution for C23, because that more closely matched existing practice.

So the end result is: WG14 doesn't want people defining new types in offsetof; it was never intended to be allowed. But because the non-comma case happened so much in practice before the standard was clarified, we didn't want to require a lot of correct-by-accident user code to get diagnosed as being incorrect, so we blessed a corner case of the feature.

So, back to Clang's diagnostic behavior: we could go the extra mile and try to silence the diagnostic in cases where no comma is present, but that's a fairly substantial undertaking for a very nominal behavior change that only shows up in pedantic mode. The trouble is: Clang doesn't distinguish between struct S { int x; int y; } and struct S { int x, y; }: https://godbolt.org/z/oE41WY6Ez So instead, we decided to diagnose as an extension in all cases. Even if it was trivial to silence the diagnostic unless there's a comma present in a declaration group, it still doesn't actually fully solve the problem because commas can appear in other places as well, like struct S { [[maybe_unused, deprecated]] int y; }.

[Sha0]

@AaronBallman: Thank you for kindly pointing out DR496. It's clear that if an anachronism was indeed committed against C89, it was performed by the committee in their response and so would merely be carried through by Clang. It seems that if a C89 programmer wishes to avoid such anachronisms, an older implementation ought to be used: one closer to that era. I won't request further discussion about this. Thanks again.

For the record, I'll point out the following, though:

Observation: In the original post, we find -ansi being used. According to the man page:

[...]
Same as -std=c89.
[...]

Specifically, I'll note that's c89 and not c90.

Observation: DR496 was raised against C11. 2011 - 1989 = 22 years.

Observation: DR496 was raised in 2016. 2016 - 1989 = 27 years.

Observation: DR496 refers to an earlier article which includes:

Pre-DR: offsetof
================

offsetof is defined in 7.17#3 as
[...]

Observation: That article self-identifies as "Pre-DR". That article also refers to offsetof being defined in section 7.17. Both of these facts are clear, in the quotation above.

My current understanding is that C89's offsetof is defined in section 4.1.5, although I could be mistaken. I conclude that the author of the "pre-DR" article was either not aware of C89 or was not referring to it, in their article. I do not find a clear date in the article. Maybe the author was considering C90 (I haven't accessed that standard) or C99 (I'm familiar with that standard) or C11 (I'm partially familiar with that standard).

Observation: The committee appears to first respond about type declarations after a meeting in October, 2017. 2017 - 1989 = 28 years.

Observation: The committee summarizes the relevant portion of the October, 2017 meeting and includes:

[...] there was no opinion expressed that allowing new type declarations was intended. [...]

Indeed: 28 years after C89, I might be surprised if the intentions were accessible to this later iteration of the committee. I'll note how this is different than this fictitious alternative:

[...] opinions were expressed that allowing new type declarations was never intended. [...]

The committee then appears to take a leap that's more consistent with that fictitious alternative, in the observation of this response:

[...]
  There was no intent to allow new types to
  be declared in an offsetof expression.
[...]

Observation: The "pre-DR" article correctly points outs about type "definitions":

[...] It appears to meet the requirements of the standard, and in C [...] types may be defined in casts and sizeof.
[...]

(I believe that "declared" and "declaration" would have been more appropriate terms to use than "defined" and "definition" in both the "pre-DR" and DR496, but the committee interpretation of the report is clear.)

(I will add to that the operands of the conditional operator as an interesting case.)

Mr. Thomasson (mentioned earlier) kindly shared this link:

• https://pastebin.com/f37a23918

Observation: The date of the linked-to article is visible as May 29th, 2009. 2016 - 2009 = 7 years before DR496.

Here is a link for an article I created:

• https://ideone.com/wL6wm

Observation: The date of that article is visible by hovering over the "13 years ago" text (at this time that I type this comment) to yield "2012-03-16 01:28:44 CET". 2016 - 2012 = 4 years before DR496. The code itself claims 2011. 2016 - 2011 = 5 years before DR496.

Observation: It seems that both Mark Wooding and Eric Sosman imagined the appearance of the type to be legitimate, in 2009:

• https://www.thecodingforums.com/threads/portable-method-of-getting-alignment-of-an-arbitrary-type.673934/

Mark Wooding:

[...]
#define alignof(type) offsetof(struct { char a__; type b__; }, b__)
[...]

Eric Sosman:

[...]
#define ALIGNOF(type) offsetof(struct{char p; type t;},t)
[...]

Without knowing who in the committee was present and qualified to discuss the intentions of C89 28 years after the year it is named for, I can only guess about the aforementioned "leap" to denying the intention for types to be declared in the controversial context. This response was to a DR for C11 (not C89, not C90, not C99). The "undefined by omission" has been retrofitted, since a plain interpretation appears to cover the needed ground: a structure type suitable for the constraints of (a) the 'static' example and (b) an address constant and (c) not a bit-field. I know of no implementation from before this DR496 that did not yield the results I'd expect from my interpretation of C89. (But I could be ignorant of such implementations.) Discussion of unions and commas and sub-objects distracts from the point of greatest concern.

This appears to be yet another case of previously portable code being hindered by modernity, even when explicitly requesting an antique treatment. I remain disappointed, but I respect the position that Clang seems to have: to follow guidance from the committee. Clang is not the appropriate tool that I need for my C89 goals, but is probably appropriate for many C89 goals for many people.

Have a pleasant day.

[AaronBallman]

Observation: In the original post, we find -ansi being used. According to the man page:

[...]
Same as -std=c89.
[...]

Specifically, I'll note that's c89 and not c90.

Hoo boy, more fun situations to explain. :-D ANSI C, C89, and C90 are the same language. ANSI C (formally, ANSI X3.159-1989) differs from ISO C (formally, ISO/IEC 9899:1990) in formatting only; there are different clause numbers due to ISO required clauses, some text got rearranged, etc. Folks refer to C89 and C90 interchangeably thanks to the publication dates; ANSI C was published in 1989 while ISO C didn't get published until 1990. (The -ansi flag is an ancient holdover from when Clang was a drop-in replacement for GCC in terms of the driver; it is an alias for -std=c89:

llvm-project/clang/lib/Driver/ToolChains/Clang.cpp

Line 6533 in 10bef36

if (Std->getOption().matches(options::OPT_ansi))

) We do a terrible job of documenting this though.

Indeed: 28 years after C89, I might be surprised if the intentions were accessible to this later iteration of the committee.

I was not on WG14 when DR496 was discussed, but I'd note that I know several members who worked on C89 were present. To wit: Tom Plum, Tom MacDonald, Clark Nelson, Larry Jones, Douglas Gwyn, and Hugh Redelmeier were all present for both C89 and C11. Also, the committee keeps a long history of meeting minutes so we can refer back to what previous committees decided to try to tease out what was and wasn't discussed and how decisions were made. Finally, the committee used to keep a rationale document that explained why changes were made (sadly, that document stopped being kept after C99 due to the expense of trying to keep it updated appropriately and I don't have a copy of what was there for C89). So while I understand your surprise, the C committee does tend to have a fairly long memory.

This appears to be yet another case of previously portable code being hindered by modernity, even when explicitly requesting an antique treatment.

Yeah, there's a tension there, for sure. From the perspective of the standards committee, C89 doesn't exist. There is only C23 and a working draft for some future potential revision of the C standard. Everything before C23 simply does not exist. However, implementations live in the real world and have to be practical about things. :-) So we continue to support older language standard modes and try to keep them as close to the original intent as possible. However, we don't reimplement the language with every release of the standard, so newer standards often have influence over the behavior in older standards modes. This is especially true when considering things like defect reports where the usual rule of thumb is that those correct mistakes in older language modes, not just change behaviors moving forward.

I remain disappointed, but I respect the position that Clang seems to have: to follow guidance from the committee. Clang is not the appropriate tool that I need for my C89 goals, but is probably appropriate for many C89 goals for many people.

I'm sorry for the disappointment. FWIW, there are ways around this, including passing -Wno-c23-extensions, not passing -pedantic, or if you wanted something that wasn't such a heavy hammer, we could split this specific diagnostic into its own warning group so you can disable just this diagnostic without losing the other extension warnings.

[Sha0]

Hoo boy, more fun situations to explain. :-D ANSI C, C89, and C90 are the same language. [...] there are different clause numbers [...]

Yes, I'm aware of this relationship between C89 and C90, as well as that c89 is somewhat of a misnomer that supports a legacy. Not everyone might be aware of this, though, so this is a good explanation to have for the record.

I suppose I was trying to hint that it's possible that the "pre-DR" author and DR496 author might be far removed from C89, time-wise. I have no evidence that they are, but the C90 clause-numbering (if that's what it was, since I haven't personally accessed the C90 document) or at least C99 clause-numbering permits the possibility.

[...] Clark Nelson, Larry Jones, Douglas Gwyn, [...] for [...] C11. [...]

OK. These names ring bells. I'm still curious about relevance for the October, 2017 meeting, but oh well.

[...] From the perspective of the standards committee, C89 doesn't exist. [...]

Yes, I'm aware of this. It's part of the rationale for my claim that:

[...] It seems that if a C89 programmer wishes to avoid such anachronisms, an older implementation ought to be used: one closer to that era. [...]

Regarding work-arounds:

[...] there are ways around this, [...] we could split this specific diagnostic [...]

Given the position of Clang following DR results as authoritative on previous iterations of the language and given that I seem to be a lonely voice about this issue, I think the effort already put forth in this discussion is already abundant. I would sooner forfeit Clang as an appropriate tool or #define probably_portable_offsetof[...] than burden Clang any further.

The code that led to this was intended to be extremely portable and I had compiled it with a variety of implementations (old and new) and added strictness-checking wherever my knowledge permitted. I encountered this surprise solely with Clang. Now a full explanation has been established, in this issue.

Thanks again.

Also, as promised: I apologize for my ignorance of DR496. It's a surprise.

[AaronBallman]

[...] there are ways around this, [...] we could split this specific diagnostic [...]

Given the position of Clang following DR results as authoritative on previous iterations of the language and given that I seem to be a lonely voice about this issue, I think the effort already put forth in this discussion is already abundant. I would sooner forfeit Clang as an appropriate tool or #define probably_portable_offsetof[...] than burden Clang any further.

FWIW, nothing about this has been a burden! It's been a really good discussion and trying to make sure we both are on the same page, and I've appreciated it. Also, "lonely voice" is really hard to judge given that most folks won't ever file an issue to begin with. My default assumption is that for every issue we get, there's 100-1000 more people hitting the same issue who just didn't feel comfortable/know where to report it. That diagnostic is fairly recent, so you might not have as lonely a voice as you might think.

The code that led to this was intended to be extremely portable and I had compiled it with a variety of implementations (old and new) and added strictness-checking wherever my knowledge permitted. I encountered this surprise solely with Clang. Now a full explanation has been established, in this issue.

Thanks again.

Also, as promised: I apologize for my ignorance of DR496. It's a surprise.

There may still be an approach which can help for maximal portability. Would something along these lines help: https://godbolt.org/z/698z6KMaE ?

[Sha0]

Good day again, @AaronBallman.

Thank you for sharing this kind consideration. You demonstrate a refreshing attitude of interest in supporting users; an attitude which I perceive to be gaining rarity in some venues, sadly.

So far, the only special-casing I've needed to do with the "intended to be extremely portable" code is that a popular compiler for DOS has feof and ferror macros, so they cannot easily be used as identifiers, such as for members of a struct. I was really hoping to avoid introducing code to deal with implementation-quirks because the goal was to stick to C89 (because that would seem to yield the maximum portability, given its age). For your suggestions of adding implementation-specific helpers, I agree that this will permit the code to compile across a wider variety of implementations, but then the project "admits" that C89 wasn't "good enough" and would carry some amount of disappointment, for me.

Unfortunately, I'm not yet familiar with __extension__, in Clang, but I'll read about it. Thanks.

In my opinion, one of C89's shortcomings was that "alignment" was referred-to, but there wasn't an operator for it; unlike sizeof for "size." (C11 achieved this, for the sake of unfamiliar readers.) But then at least the macros shared here did seem to be "good enough" for some purposes in C89; providing relief for that shortcoming. Alas, DR496 implies that they weren't "good enough," all along. (I find that dubious, but "official is official" and I doubt that my qualifications rise to those of committee-members in October, 2017.)

The ugly work-around (for the Clang result in the original post) that I actually did use before raising this issue was to "manually" establish cumbersome alignof_XXX wrapper-structs for every type. That work-around also subverts a goal of having every tagged type represented in another context, since otherwise infinite recursion results: alignof_alignof_XXX and so on. Perhaps another creative solution is waiting to be revealed, somehow.