[solved] issue with opaque-type, struct tag_name not implemented - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: March 09, 2022, 10:53:01 am
content: So I have about 7000 lines of C code where something like the following stuff is massively used.Code:typedef struct my_sc_t opaque_t; /* inform the compiler of something to define later*/typedef opaque_t* p_opaque_t; /* and whatever it will be, let's prepare its pointer-type */typedef struct my_sc_t /* this line makes the trick */{p_opaque_t p_next;} my_t;typedef my_t* p_my_t;Everything is elegant and fine with all of my C compilers and the code passes all the QA, it really looks good and nice and makes me feel good, etc, except that when I try to compile on a Japanese SH4 C compiler provided by the customer, the compiler surprisingly stops at this line.Code:typedef struct my_sc_ton the email -don't worry, it's C89- he wrote, so I don't seriously know why the compiler has to cry up like a baby complaining that this line is nothing but "syntax error" (really?), with no way, no magic flag to override this crazy behavior, and whatever you do it will still refuses to continue.Why!?! holy crap,struct tag_nameshould be *standard feature*. Isn't it?The general syntax for a struct declaration in C should beCode:struct tag_name{...and such a struct declaration may also appear in the context of a typedef declaration, where ok, "tag_name" is *optional* in some contexts - so the manual says - but does it mean not implemented at all?Code:typedef struct tag_name /* this is optional, in my case the CC-parser doesn't understand it at all */{I am lost here, and as workaround I am doing the dirtiest thing everCode:typedef void* p_opaque_t; /* horrible dirty, please don't look at this line */typedef struct{p_opaque_t p_next;} my_t;plus some wild casting here and there along the lines of the source code.I prepared a patch with this but I seriously feel embarrassed.I mean, now by applying the patch the code is still back compiling and working, but I am looking at my shoes ... because ... I don't really know a better way to fix this, and I have the feeling that no matter how much effort you invest to polish your shoes, once again "a wild dirty hack is saving your day".edit:solved, missing feature updated to the C-compiler

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 09, 2022, 05:48:12 pm
content: The compiler seems a bit nasty, but why don't you just write:Code:typedef struct my_sc_t opaque_t; /* inform the compiler of something to define later*/typedef opaque_t* p_opaque_t; /* and whatever it will be, let's prepare its pointer-type */struct my_sc_t /* this line makes the trick */{p_opaque_t p_next;};typedef struct my_sc_t my_t;typedef my_t* p_my_t;Which I guess should pass alright with this compiler?

author: magic
author_rank: Super Contributor
timestamp: March 09, 2022, 07:18:10 pm
content: Code like this convinces me that Linus is right about typedefsI suppose it's all legal C and whatnot, but why?

author: TheCalligrapher
author_rank: Regular Contributor
timestamp: March 10, 2022, 12:41:17 am
content: Quote from: DiTBho on March 09, 2022, 10:53:01 amThere's nothing wrong with that code neither in C89 nor in any other iteration of C standard. On top of that, the code is perfectly valid in C++ as well.If some compiler complains, there must be something very wrong with the compiler.---It is not clear though why it declares multiple names for the same thing. `opaque_t` and `my_t` are the same. `p_opaque_t` and `p_my_t` are the same.

author: DiTBho
author_rank: Super Contributor
timestamp: March 10, 2022, 08:43:13 am
content: Quote from: SiliconWizard on March 09, 2022, 05:48:12 pmBecause this works for the compiler, but not for the ICE which needs to see types

author: magic
author_rank: Super Contributor
timestamp: March 10, 2022, 09:15:44 am
content: Then you've got a problem because the code posted by SiliconWizard is equivalent, so it seems like you are stuck between to shitty tools which misunderstand different aspects of the languageMaybe the solution is to drop this madness of having three different names for the exact same type.Pro tip 1:Making your clients useopaque_tdoesn't hide the type's implementation from them. They still know it's the same type asstruct my_sc_tbecause your header says so. C permits them to do everything with that type that they can do with the struct itself.Pro tip 2:Simply omitting the struct's definition from the header restricts your clients to doing exactly one thing with the struct: storing pointers to it and passing them around. They can't even create their ownstruct my_sc_tbecause they don't know the type's size, let alone its layout.

author: DiTBho
author_rank: Super Contributor
timestamp: March 10, 2022, 09:25:52 am
content: Quote from: magic on March 09, 2022, 07:18:10 pmI like Linus, seriously I love that guy's idea and efforts, but regarding typedefs ... Linus is rather myYin and Yang.He has a completely opposite view to my ICE's needs, that also describes how obviously opposite or contrary forces may actually be complementaryCode:Linus = - meOh, that's why I don't touch the kernel too muchCode:Linus + me = 0(A) + (- A) = 0the reworked code may vaporize(edit: humor, but it's true ... also, I am not qualified to touch the kernel)

author: DiTBho
author_rank: Super Contributor
timestamp: March 10, 2022, 09:55:52 am
content: Quote from: magic on March 10, 2022, 09:15:44 amDéjà vusurprisingly, that's precisely what the Japanese dude wrote me -yes, but- he showed me a piece of code similar to the one posted by SiliconWizard -the code is equivalent, so what's the problem? why do you need a typedef struct with tag_name?- he asked rather perplexed.Misunderstanding different aspects of the language && misunderstanding different needs of the debugging tools, that's precisely the problem hereYesterday I spent the whole day trying my new Carbon bike, and thought that pro-ICEs are somehow like Carbon frame bikes, they cost a lot of money, but they offer insanely great performance.Mine is cheap, but Aero Carbon Bikes can't go on dirt roads, they need some care for properly work, as well as some pro-ICEs need some special care about the source code to properly work.Some pro-ICEs are able to directly understand the C code even without any host support (so they can be used in production, for QA), that means there is a kind of C-interpreter in their firmware, that's also why I do care to write the source code in a very clean way, otherwise the ICE doesn't understand it, and a human being (do you guess who?) needs to waste his time fixing stuff instead of enjoying his carbon bike.I remember some years ago a colleague in Osaka must have "forgotten" (let's say "forgot") to add a token to the parse module, or something. I don't remember, but I remember that for I couple of hours I was tempted to kick the desk because it didn't work with nested-structs and I had to split them.Kind of crazy situation when the workaround is that you first you define a type-struct, than you define a new type-struct and you use the previous definition, otherwise the tool doesn't understand things like this:Code:typedef struct{struct /* now it's fix, but this didn't work for the ICE, because it didn't understand nested struct, O_M__G__! */As result, I had to rework the code to save my day. Something like 30 lines of patch, and it didn't too so long, but it was rather annoying.Anyway, yesterday night I asked the teams behind the Japanese C compiler (which fortunately is a division inside the same company) to kindly add the tag_name, because it's a "C standard feature".And they questioned a lot. Why? what? Can you tell, umm? ... So very likely tomorrow we will have on a Skype micro conference, where, since I don't speak Japanese, I will repeat my email and look at my shoes.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 10, 2022, 05:52:45 pm
content: Quote from: DiTBho on March 10, 2022, 08:43:13 amGood lord, but the typedef's are still there!

author: Siwastaja
author_rank: Super Contributor
timestamp: March 10, 2022, 07:25:05 pm
content: Quote from: magic on March 09, 2022, 07:18:10 pmIt's worth noting that Linus Torvalds thinks that people who reinvent the pointer syntax and bake it into the typedef should be shothttps://yarchive.net/comp/linux/typedefs.html

author: DiTBho
author_rank: Super Contributor
timestamp: March 10, 2022, 09:22:07 pm
content: Quote from: Siwastaja on March 10, 2022, 07:25:05 pmI just hope that for the Japanese ofHigashiyodogawait is not an ideological issue like Linus's, otherwise it's the right time that I change my job and I start preparing Aerobie AeroPress coffees for the cos-players in TokyoWe will see tomorrow ...

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 11, 2022, 03:12:19 am
content: Quote from: Siwastaja on March 10, 2022, 07:25:05 pmI don't much like pointers "hidden" in type definitions either.But structures not typedef'ed? That's insane. (But if I read correctly, Linus was not so harsh against this.)The fact C has some kind of "dangling" type system with structs and unions and enums just each living in their own tag world is a legacy of early C, but does not make much sense IMHO.The only reason I've been using struct tags is when I need forward definition (including recursive definitions of structs), since there's no way around that in C.Data types are an abstraction per se. And whatever type you use, you need to know what there is behind it anyway to use it properly, in most cases. The exception is with "opaque" types - in which case, you need to use typedef anyway if you want to make them look really "opaque". (Like, who cares if the type is actually a struct or not if it's meant to be opaque?)The point that typedefs "hide" data types is not a silly one, but it's questionable. But as it's very much in the coding style category and has a largely subjective side, it's probably not really useful to debate it.

author: magic
author_rank: Super Contributor
timestamp: March 11, 2022, 05:49:01 am
content: It makes sense in libraries where people would endlessly ask questions about what the members of the struct are and why accessing them doesn't seem to work. Telling them to use fuckoffitsasecret_t in the first place gets the message acrossSubjecting yourself to this in a monolithic project like Linux is simply masochistic.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 11, 2022, 07:58:43 am
content: Quote from: SiliconWizard on March 11, 2022, 03:12:19 amThe reason for this seems to be simply matter of preference - and encouraging similar style across the whole project. Not a strong rule.Some people prefer to use a typedef and add some made-up suffix to tell them it's a struct (like _struct or _s). If you think about it, this doesn't make a lot of sense, you could just use the bare language and the struct keyword!Though, I typedef all my non-single-use structs, with the usual _t suffix. It's just what I'm used to. The keyword struct in the middle of the code just looks weird to me. But if I had to read more linux kernel code, I'm sure I'd get used to it in no time.

author: DiTBho
author_rank: Super Contributor
timestamp: March 11, 2022, 10:50:07 am
content: QuoteYup. Me too.

author: DiTBho
author_rank: Super Contributor
timestamp: March 11, 2022, 10:55:24 am
content: Quote from: magic on March 11, 2022, 05:49:01 amFor programmers who were young in the 80's, nowadays you can just look at the line of code on the IDE, ask with one click-over, and it will tell you!

author: DiTBho
author_rank: Super Contributor
timestamp: March 12, 2022, 11:35:25 am
content: -We will add the struct tag_name to our SH4 C compiler- the promise they made today after 2 hours of conference yesterday.It wasn't a piece of cake to convince them, but it's kind of victory for a celebration day, and I am so happy that I no more need to apply dirty patches to sources.Yeess

author: Nominal Animal
author_rank: Super Contributor
timestamp: March 13, 2022, 03:45:33 pm
content: If one looks at the Linux Kernel Mailing List for GCC issues, one will see that there were quite a lot of cases where the kernel developers, too, had to convince the GCC folks to either guarantee a specific behaviour, or provide a compiler option to do so.This is exactly what I mean when I say it is the practical use cases that override the standards, and not vice versa. (The C standard itself, all the way up to C99, only described what compilers had already widely implemented; it is only since C11 that the standard started suggesting what compilers should implement.)Sure, here the compiler isn't standards compliant in the first place, but the same demands of real-world code applies.It would be very nice if the language was fully specified and standards-driven, with a reference implementation and all –– that would change the situation completely –– but for C, that just isn't possible due to the vast amount of existing code.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 13, 2022, 06:03:40 pm
content: Quote from: DiTBho on March 12, 2022, 11:35:25 amI guess I hadn't fully understood the issue there, explaining my earlier answer. Either you description was not clear or I just assumed something because the actual issue was just not "believable".So, I assumed that this compiler choked on using struct tags *in the context of a typedef*, but not outside of a typedef, which looked nasty but more believable as a compiler bug. Thus my answer. What led me to this assumption was, sure, that not supporting struct tags at all was kinda unbelievable, but your example code didn't show any struct definition outside of a typedef.So not supporting struct tags at all? They were there for the longest time, even in original C, I think?Quote from: DiTBho on March 12, 2022, 11:35:25 amIt's obvious they wouldn't like any change, that's probably an already old compiler that has probably worked "well enough" for a long time, so they'd be reluctant.Still, that one missing "feature" is absolutely unbelievable.

author: DiTBho
author_rank: Super Contributor
timestamp: March 13, 2022, 09:47:31 pm
content: Quote from: SiliconWizard on March 13, 2022, 06:03:40 pmTheir C parser is able to understand "typedef struct {" but not "typedef struct tag_name {". They assumed "tag_name" was optional, so the rule is missing in their parser.struct tag_nameis supported by their C compiler, but not by my ICE because we do not support tag_name space, we need type_space for our analyses, so I had to find a solution, which is ugly and only partially supported by my ICE, but hey? better than nothing.As far as I understood, theirSH4 C compilerwas created in 2011, tested for two years and committed as stable. They said they never needed to support "typedef struct tag_name" before my code, but as now they want "QA" code and they buy some software stuff from my company plus other debugging tools, it is in their best interest to support the missing functionality.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 13, 2022, 10:53:26 pm
content: Ah, so I understood correctly after all. And this was a mix of issues between their compilers and your own tools.So in that case, does declaring the struct as I wrote not work with both?Code:struct <tag> { ... };typedef struct <tag> <type>;

author: DiTBho
author_rank: Super Contributor
timestamp: March 13, 2022, 11:27:28 pm
content: Quote from: SiliconWizard on March 13, 2022, 10:53:26 pmIt works for the Japanese SH4 C compiler but my ICE only considerstype-space, notpure tag-space, if something begins with "struct" without being preceded by "typedef" then it's ignored; therefore in your second line, "tag" is unknown.

author: DiTBho
author_rank: Super Contributor
timestamp: March 13, 2022, 11:41:55 pm
content: Querying the ICE over the serial line(1), it saysCode:typedef struct <tag> <type>;<type> isopaque, still to be defined, which means it's recognized it as "opaque" and it's waiting for its definition, which unfortunately it won't never find because it doesn't understand "struct tag".Code:struct <tag> { ... }; // this line is ignored an not understoodI can even break-in, and manually teach the ICE about the tag through the debug channel, but the whole process should be automatic, so this is not acceptable.(1) yes, I can *debug* the debugger

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 14, 2022, 03:54:23 am
content: I see, so it looks like your ICE is as "buggy" (read: limited) as the SH4 compiler.

author: DiTBho
author_rank: Super Contributor
timestamp: March 14, 2022, 09:57:31 am
content: Quote from: SiliconWizard on March 14, 2022, 03:54:23 amThe differences are- "struct without typedef" is bad habit and it's banned in several debugging plans- "typedef tag" is supported ( the tag is a property in the type-space ) and used by several analysis toolsso they omitted "typedef tag" because they thought it was "optional", while we omit "struct without typedef" because it's useless, bad, not used during analyses, and supporting it would over-complicate the ICE firmware.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 15, 2022, 02:06:41 am
content: So you say. =)But however you look at it, you're not supporting C fully in your own tool, and the compiler is not either. And both limitations unfortunately (and somewhat funnily) are orthogonal.Now I suppose this is some in-house tool that is not actually used outside of your company? In which case, that's a different story for this reason. But otherwise...

author: newbrain
author_rank: Super Contributor
timestamp: March 15, 2022, 06:40:11 am
content: Quote from: DiTBho on March 13, 2022, 09:47:31 pmThis is insane.The standard is available for a modest sum (and the drafts are free).There is plenty of conformance test suites.And maybe they even want money for that compiler.How can you trust its results when even the basic language features are misunderstood?With the risk of stereotyping, I am quite surprised that this a Japanese firm: whenever I worked with Japanese people, both internal and external, they were extremely competent, thorough and precise.I can understand that your ICE, an in-house built tool IIUC, which is not a compiler, might miss some stuff here and there.

author: DiTBho
author_rank: Super Contributor
timestamp: March 15, 2022, 07:34:37 am
content: Quote from: newbrain on March 15, 2022, 06:40:11 amI'm not naive enough to trust a C compiler without my own verification - their C compiler has been tested and is in great shape for what really matters: Gcc does not even support their DSP fuse-ISA, while the code generation of their C compiler is excellent! So don't overdo it now, no doubt "typedef struct tag" is a missing feature, but honestly rarely used and defined as "optional", so it's an "ops, we must have forgotten a branch in the parser table", and it makes perfect sense that I was not considered during their test cases.

author: DiTBho
author_rank: Super Contributor
timestamp: March 15, 2022, 07:36:51 am
content: Quote from: newbrain on March 15, 2022, 06:40:11 amI've seen far worse, a C compiler made by TI, where sizeof(char) returns 2.*THIS* was/is crazy

author: magic
author_rank: Super Contributor
timestamp: March 15, 2022, 07:48:30 am
content: Well, we have seen OP07 from TI which has more flicker noise than AD/LT subs, NE5532 from TI which has more THD than any other, TL072H from TI which is not a JFET opamp in the first place...Starts to look like there is a pattern here

author: DiTBho
author_rank: Super Contributor
timestamp: March 15, 2022, 08:03:16 am
content: Quote from: newbrain on March 15, 2022, 06:40:11 amumm, herenobody said those guys are not competent. You cannot judge people so fast!We are talking about experimental things, it's too easy to speak about a compiler you just download from the web, and you get compiled with "./configure blablabla ; make ; make install". They *designed*, *implemented*, an *tested* it from scratch, and the story is easy: there was/is simply a radical different philosophy about the use of "structs"Pretty like Linus vs others.In two hours of micro-conference with a crappy microphone on a crappy Skype internet connection (plus my Japanese that honestly sucks, and my English that is quite idiomatic and gesticulated) the two delegates from the engineering department figured out my needs, talked to the management department and planned that the missing feature will be likely added in a couple of days.-We know how to fix it, and we will quickly!- All of this in 2 hours!!! Not weeks or months.That's what makes them extremely efficient and competent!

author: newbrain
author_rank: Super Contributor
timestamp: March 15, 2022, 08:10:46 am
content: I'm still not convinced.QuotePhilosophy? We are talking about basic language constructs.This is literally the second example in the chapter "6.9 Typedef" of K&R's book - from the 1978 original one, same in the revised ANSI version:Code:typedef struct tnode { /* the basic node */char *word; /* points to the text */int count; /* number of occurrences */struct tnode *left; /* left child */struct tnode *right; /* the right child */} TREENODE, *TREEPTR;How can they maintain that it's rarely used?So, it's an "experimental" compiler from 10 years ago - good luck!

author: DiTBho
author_rank: Super Contributor
timestamp: March 15, 2022, 08:18:06 am
content: Quote from: newbrain on March 15, 2022, 08:10:46 amPhilosophy!People like Linuxneverwrites "typedef struct tag", as well as all the software they wrote to test the compiler never used "typedef struct tag". Always "struct tag".It's radically different in terms of mental approach.

author: DiTBho
author_rank: Super Contributor
timestamp: March 15, 2022, 08:30:04 am
content: For me they did well to resume an old project that has remained dormant.It is a great opportunity, a nice thing for these dark days.edit:Ok, guys, I won't tell more

author: newbrain
author_rank: Super Contributor
timestamp: March 15, 2022, 08:58:25 am
content: Quote from: DiTBho on March 15, 2022, 08:18:06 amI was not aware Linux managed to gain sentience. Itreallyis more advanced than Windows.I'm sorry, but the mental approach of the user does not exonerate (and should not bind) a compiler writer. The language definition does.QuoteSorry, but this is.In that vein, also int i= 5; is optional. Or the else part of an if. Or the default label in a switch().I think we'll have to keep disagreeing (not the first, probably not the last time), but this makes for interesting discussions.

author: magic
author_rank: Super Contributor
timestamp: March 15, 2022, 09:11:22 am
content: On Wikipedia, factual accuracy is oftentimes optionalAnd where did you even find such information there?

author: DiTBho
author_rank: Super Contributor
timestamp: March 15, 2022, 10:16:53 am
content: Quote from: newbrain on March 15, 2022, 08:58:25 amnot even if it were your turn to fix things.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 15, 2022, 11:05:44 am
content: One could think that a new compiler would be tested with at least the examples given in the language standard.But of course, if the compiler is mostly for "internal use", then nothing prevents just not supporting some of the language features, if they are not used within that company.

author: DiTBho
author_rank: Super Contributor
timestamp: March 15, 2022, 12:40:30 pm
content: Quote from: Siwastaja on March 15, 2022, 11:05:44 amPrecisely!

author: DiTBho
author_rank: Super Contributor
timestamp: March 15, 2022, 12:41:52 pm
content: Quote from: magic on March 15, 2022, 09:11:22 amYup, no doubt about-What will happen with your ICE with typedef struct XYZ { ... } XYZ;? - asked a senior dude during the micro-conference.Who? What?For the Wikipedia you are free to choose both the tag-name and the type-nameCode:typedef struct tag_name{} type_name;and it doesn't discourage you from choosingtype_name = tag_name, which is the senior's question: what will happen in this case?Code:typedef struct myxyz // <---------- collision? or will it work?{} myxyz; // <---------- collision? or will it work?His doubt was solid because, at the open brace, his old C compiler registers myxyz as a structure tag name, and then when myxyz appears a second time, you get a syntax error, clarified as "redeclaration error", so he was curious to understand how our ICE behaves in that case.Crucial question -although it is not a problem for the modern c compiler, it's not recommended ...- I replied-yes, but what about your ICE in this specific case?- he frowning askedThe screen was forming an expression of disapproval, typically by turning down the corners of the mouth -well, ... it depends- I glossed, and we got five second of reciprocal awkwardness.His colleague then asked me why I am using "typedef struct tag type" in the first place, since, he pointed point out , one should *typedef something* when its data is inaccessible (opaque), or when the data is not supposed to be edited by hand, and in both cases they will probably only use the type in one header, in which case you can omit the tag (which is nothing but a true struct-name).And they don't like to use the tag in "typedef struct tag" because seniors still fear that every name you add to the global namespace increases the chance of a collision.Now, back to his question, I got a quick flashback on the standard workaround for the above trouble (to avoid collision), which an article on Dr. Dobb's Journal described as the simple trick of making the structure tag name a minor modification of the typedef name, most typically by putting a word e.g. "tc" or "sc" in front.Code:typedef struct tc_myxyz // <---------- thanks to this trick{} myxyz; // <---------- no more collisionWe are talking about 1989-1995, there was kind of inertia to adapt to the standard, and this is what programmers do with ancient C compilers where using the same name causes a name collision.Standard C begins with C89 and modern C compilers separate the structure and typename name spaces, the workaround is no longer necessary, but some-people is still used to use it.And, sometimes that's not what you get with some tools; for example our ICE ... in performance analysis keeps structure tags, union tags, and typedefs in the same namespace to save precious RAM, so in this case it will report collision-errors.

author: newbrain
author_rank: Super Contributor
timestamp: March 15, 2022, 01:31:17 pm
content: Just as a single data point, I eyeballed* the ~150 repos that make up our product (just a part of a bigger thing), something in the ballpark of 10 MLOC.The use oftypedef struct struct_tag {accounts for about 30% of the typedefs.It's there both in legacy and in recent code.But yes, an internal tool is less constrained than a publicly available one. I understood it was something they bought.Out of curiosity, is the behaviour the same fortypedef enum tag {ortypedef union tag {?If so, maybe you should pressure them to make sure it's fully corrected.*OpenGrok helped me. Unfortunately it does not support regexp in search, at least in our installation.

author: DiTBho
author_rank: Super Contributor
timestamp: March 15, 2022, 03:18:18 pm
content: A lot of the firmware I analyzed and reworked, use void* to bypass the problem.When you cannot recursively use struct*, you use void* inside the struct.It's ugly and requires casting, but it's what I have observed in the last 10 years.Someone calls that "void*" as "beaver", never understood whyThey say "use the beaver pointer", like in star wars they say "use the force", or something.I don't know what a beaver is supposed to do, so I don't know why they say so, perhaps because a beaver builds dams with mud, branches and stones, so, because the beaver survives with an hack that should be solid engendering, but actually it works.It's an idiomatic urban dictionary used by some hackers of the deep internet underground, probably a joke or something.Anyway, if this is a true hack, articles about SmallC are plenty of examples about that.Next time your C compiler doesn't support typedef struct tag, remember you can always "use the beaver"(damn, now I want a t-shirt with that meme!!! I want it!)Quote from: newbrain on March 15, 2022, 01:31:17 pmtypedef enumtag andtypedef union tagare supported and work well.No problem at all.

author: DiTBho
author_rank: Super Contributor
timestamp: March 15, 2022, 09:50:03 pm
content: One of my Dr. Dobb's Journal. Perhaps The best one.But it's not the one with the trick I mentioned above.

author: newbrain
author_rank: Super Contributor
timestamp: March 15, 2022, 10:59:37 pm
content: Quote from: DiTBho on March 15, 2022, 03:18:18 pmBizarrer and bizarrer.Why single out structs then?It would seem to be the exact same kind of parse tree, it's the same use case, especially with unions, and, most important, it's the frigging same tag namespace that got the 'senior' so worried!I must admit you are a mine of odd stuff.You should print that T-shirt with one of the many online services!

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 15, 2022, 11:05:42 pm
content: If they just singled out struct tags in this context, then it's definitely either just that they *forgot* to implement this... or, that they *intentionally* didn't implement it because, as they stated, they thought it was "optional" and they decided not to implement it as such, in order to make the product "leaner" so to speak, which would be a typically japanese attitude actually.What is unfortunate is that they didn't read the standard, or could not make sense of it, and of course, the bizarre factor is why did they think tags were not optional for unions and enums?

author: DiTBho
author_rank: Super Contributor
timestamp: March 15, 2022, 11:39:44 pm
content: Quote from: SiliconWizard on March 15, 2022, 11:05:42 pmThis one!Considered optional.A sort of "if it's optional, then will be implemented if we have the will and the time, otherwise skipped".And nobody noticed before me because they *use the beaver*

author: DiTBho
author_rank: Super Contributor
timestamp: March 16, 2022, 12:12:06 am
content: Quote from: SiliconWizard on March 15, 2022, 11:05:42 pmSeniors are so worried about collisions that those other two tags have never been used seriously internally the company.Literally I can't find anything but only test-cases, to test their C compiler, that use those two supported tags. Not a firmware, or something. It intrigued me and I wrote a couple of simple-demos and everything works with them, but it's not even mentioned anywhere except in a couple of test-cases.It's more likely the reason was that they started implementing them, but then ran out of time and skipped the struct-tag function completely (to be done later ... then forgotten forever)Who knowsedit:Before being presented on theDr. Dobb's Journal magazinein the 90s, the first versions ofSmallCwere full of similar oddities with tags, firstly banned to simplify stuff (name-collisions was a real issue), then un-banned because each kind of typedef must have its personal space, and ... the C compiler code got fixed, improved and extended, and finally polished when they understood that Small-C was important for tiny computers in a manner somewhat analogous to the importance of GCC for larger computers.Anyway, nowadays, it's time for llvm / clang ... I am afraid that stuff is only good for veterans and sweet memories

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 16, 2022, 05:51:51 pm
content: I still stick to GCC rather than LLVM for a number of reasons. But that's another story.