Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: C naming conventions Date: Tue, 13 Sep 2022 05:18:35 -0700 Organization: A noiseless patient Spider Lines: 63 Message-ID: <86a673piw4.fsf@linuxsc.com> References: <3e090bd4-4274-467b-8cf7-6d36c3ab9dc9n@googlegroups.com> <86edwgptqk.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader01.eternal-september.org; posting-host="92872b52a6f682cd3838888a35637fbb"; logging-data="2719958"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18TK5tKP7OuQM29k5cApRWdqAw00lC1Gis=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:A51tmPWAhzeobtCqDBxa6K+6fkM= sha1:miIp2zW9hRPK8KH1aM4HW6PWlAw= Xref: csiph.com comp.lang.c:167664 kegs@provalid.com (Kent Dickey) writes: > In article <86edwgptqk.fsf@linuxsc.com>, > Tim Rentsch wrote: > >> kegs@provalid.com (Kent Dickey) writes: [..largely condensed..] >>> All structs are created by STRUCT(Sample_structure) where STRUCT is: >>> #define STRUCT(a) typedef struct a ## _st a; struct a ## _st >> >> It is a little bit safer if STRUCT(a) were defined >> >> #define STRUCT(a) \ >> struct a ## _st; typedef struct a ## _st a; struct a ## _st >> >> The reasons are somewhat esoteric. But since the leading >> declaration is hidden inside a macro, it seems better to use the >> safer form. > > What are the reasons? It's not obvious to me what it is, but I would > guess it's some sort of namespace conflict you're trying to avoid. It's common to think of 'typedef struct some_tag SomeTypeName;' as doing two things, namely, introducing a new structure tag, and giving an alternate name to a struct type having that tag. What actually happens is not exactly that. The point of putting in the leading 'struct a ## _st;' is to ensure that a new tag is introduced into the relevant scope, rather than possibly reusing an existing structure tag defined in an outer scope. Basically the point of having 'struct a ## _st;' is to make sure that the following 'typedef struct a ## _st a;' behaves the way people expect it to behave, and not be blindsided by different behavior when the structure tag accidentally matches a tag defined in an outer scope. >> [...] > > My rules are a pushback against needless abstraction. [...] Whether an abstraction is needless is a subjective question. It seems to me that (some of) the rules you proprose effectively prevent any abstraction in some cases, whether it is "needless" or not. >> [...] > > I'm trying to put some protective pads on to avoid C's many > pitfalls, and make it easy to browse code, even without complex > tools. [...] I'm not sure what kinds of tools you count as "complex tools". Do you mean to avoid using any of the standard utilities that were part of Unix 40+ years ago? To me it seems silly to design rules assuming such a primitive environment (that is, one where the common Unix utilities of circa 1980 were not present). One question for you: looking over your own code, what would you say is a rough distribution of function lengths? What is the range of lengths, what is the average length, what is the median length? If you can get exact numbers, so much the better, but rough guesses (assuming they are informed guesses) are fine.