Path: csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail From: cross@spitfire.i.gajendra.net (Dan Cross) Newsgroups: comp.lang.c Subject: Re: Small challenge: sort names Date: Sat, 11 Apr 2026 19:59:39 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: <10re97b$4pb$2@reader1.panix.com> References: <10r4h6o$396qn$1@dont-email.me> <20260409025901.00002bc6@yahoo.com> <10r8fr5$37g$1@reader1.panix.com> <86eckla45k.fsf@linuxsc.com> Injection-Date: Sat, 11 Apr 2026 19:59:39 -0000 (UTC) Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="4907"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Xref: csiph.com comp.lang.c:397493 In article <86eckla45k.fsf@linuxsc.com>, Tim Rentsch wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: > >> In article <20260409025901.00002bc6@yahoo.com>, >> Michael S wrote: >> >>> On Wed, 08 Apr 2026 23:35:35 GMT >>> scott@slp53.sl.home (Scott Lurndal) wrote: >>> >>>> Michael S writes: >>>> >>>>> On Wed, 08 Apr 2026 21:04:56 GMT >>>>> scott@slp53.sl.home (Scott Lurndal) wrote: >>>>> >>>>>>> [snip] >>>>>> >>>>>> Idiomatically, I might have written >>>>>> >>>>>> size_t >>>>>> countchar(const char *str, char match) >>>>>> { >>>>>> size_t count = 0u; >>>>>> for(; *str != '\0'; str++) count += (*str == match); >>>>>> return count; >>>>>> } >>>>> >>>>> I'd change it to >>>>> >>>>> size_t >>>>> countchar(const char *str, char match) >>>>> { >>>>> size_t count = 0; >>>>> for(; *str != 0; str++) count += (*str == match); >>>>> return count; >>>>> } >>>> >>>> Personally, I prefer to properly identify integer constants >>>> with the appropriate type annotation. I always explicitly >>>> check against NULL rather than using !ptr, for example. I >>>> never use an unadorned integer for a character constant, >>>> rather using either 'c' for printables, the legal escapes >>>> (e.g. \n) and for any non-printable, the appropriate >>>> octal escape. >>>> >>>> Perhaps some of this is pedantic. I worked with a system >>>> where the null pointer constant was not the value zero, so >>>> I'm aware that !ptr may not actually do the right thing in >>>> such cases. >>> >>> Which is irrelevant in this specific case. >>> BTW, I think that (ptr != 0) is guaranteed to work even on systems >>> with null pointers not being numerically zero. But I am not >>> certain about it. What I am certain is that on the right side of >>> assignment to pointer 0 always acts the same as NULL. >>> But that's too irrelevant for our case. >> >> It's easy enough to verify looking at a canonical source. >> Section 6.3.2.3 coupled with 6.5.9 of C18 suggest this is >> guaranteed to work. >> >>> As to being pedantic w.r.t. '\0', may be you acquired this habit >>> because of C++? If I am not mistaken, in C++ '\0' has type char >>> and due to that (or because of, which is IMHO, more appropriate >>> wording) can in some contexts lead to results different from 0, >>> with differences as huge as call to completely different procedure. >>> It does not happen in C where we have no misfeature of type based >>> static polymorphism. >> >> '\0' is indeed a `char` in C++. But I don't think that really >> changes the point, which is more about semantics. Why NOT use a >> relevant character constant instead of `0`? It's not whether >> one can or not, or whether it's semantically equivalent, or >> whether C's `char` type is really an integer in a trenchcoat: >> it's using the appropriate constant to match the domain: in this >> case, matching character data. > >There's no reason to use a constant at all; just write '*str'. >This writing isn't just idiomatic -- it's integral to how the >language was designed, not only for string termination but also >the rules for null pointers and how expressions work in the >context of for(), if(), and while(). Writing != 0 or != '\0' is >a holdover from being used to writing Pascal (or any number of >other earlier languages). This is subjective, and _a_ response from a different school of thought may be that `*str` is not a boolean type, and thus should not be used in a boolean context. You may disagree; I may occasionally disagree myself, but again, it's subjective. >When in Rome, do as the Romans do. This is the critical part. Many Unix and Unix-like kernels, for instance, have style guides that demand comparison against an appropriately type constants, along with other style rules about the placement of braces, use of whitespace, indentation, and so on. If one works in those kernels, one doesn't really have a lot of choice: one must do what the Romans in that instance of Rome do, regardless of personal preference. - Dan C.