Re: encapsulating directory operations

Liste des GroupesRevenir à cl c 
Sujet : Re: encapsulating directory operations
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.lang.c
Date : 20. May 2025, 17:19:47
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <100ia33$2ae8t$1@dont-email.me>
References : 1 2 3 4 5
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
On 20/05/2025 15:47, Paul Edwards wrote:
"David Brown" <david.brown@hesbynett.no> wrote in message
news:100hs85$27qbn$1@dont-email.me...
On 20/05/2025 11:36, Paul Edwards wrote:
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87ecwj1vy9.fsf@nosuchdomain.example.com...
"Paul Edwards" <mutazilah@gmail.com> writes:
>
>
And C90 (etc) could potentially be extended to include a folder.h
>
C90 will never be extended.  It was made obsolete by C99, which was
made
obsolete by C11, which was made obsolete by C23.  You're free to invent
your own language based on C90 if you like, but C went in a different
direction decades ago.
>
That depends on your definition of "C". Ritchie is no longer here to
adjudicate whether something close to C90 - in the spirit of the
original C, is the true successor to his language, and which one is
a complete and utter joke of no relation to anything he designed.
>
>
Once C was standardised - first by ANSI, then immediately afterwards by
ISO - the "definition of C" became clear.
 Yes, I agree with that.
Then why do think that something might depend on someone's "definition of C" ?  The definition of C is clear - it is what the international standard says it is.  You can have other C-like languages, but they are not C.

 
The language is covered by an
international standard, so "C" is the language defined by that standard.
   Thus "C" means "C23" at the moment - each newly published C standard
"cancels and replaces" the previous version.
 I don't agree with this.
You don't get to have an opinion on facts.  What I said is /fact/ - you can look at what it says in each new version of the C standards.  This is also normal practice for ISO standards.
You can have an opinion as to whether or not you like the ISO practices, but not on what those practices are.

I'm sure the ISO committee is keen
to "cancel" the previous work.
 But I have a different opinion.
 I doubt that I am alone. I'm probably in a minority, but so what?
 
Again, you don't get to have an opinion on what the ISO committees practices are - you only get to have an opinion on whether or not you like them.  It is good to be clear on that difference.
Now, you are certainly not alone in wanting to use older versions of the C standards despite them being "cancelled and replaced" by newer versions.  And I think it is very common in the C world to appreciate that in practice, old versions are well supported by tools.  (I typically write new projects to new standards, but I am very glad that tools still actively support old standards.)

Ritchie's opinion hasn't
had any connection to the "definition of C" since 1989.  I don't know if
he ever expressed a public opinion on C99, or the plans for C11.  I
would, however, be astounded if he had considered it "a complete and
utter joke of no relation to anything he designed".
 Well, in the 1990s I had some work colleagues who were
incensed that I had converted some K&R C code to C90,
and called it "nancy C". I pointed out that Ritchie himself
had endorsed the standard, and they still didn't budge,
saying that he had become deranged or something like that.
 
They were justified in thinking that "Richie himself endorsed the standard" is a totally irrelevant argument.  They would be wrong if they said he had "become deranged".
While there are some people who, for reasons that still escape me, prefer C90 over C99 when given a free choice (i.e., not required by toolchain limitations, project standards, etc.), I do not think many people consider K&R C to be superior to C90.

 From another corner I still deal with people who insist
that everything should be written in assembler.
 
Some things /are/ better written in assembler.  Not many things, but some things.

And in another corner, there are people who claim that I
am at fault for not making "my" compiler (a slight variation
of gcc 3.2.3) run in under 16 MiB of memory.
 
Now you are stretching credulity.

I understand where these people are coming from.
 And I can see the alternative described by that Jeff article
I referenced.
 
Few people click on random links.  If you have something to say, say it.

But my starting position is that I (sort of) can't personally
fault the C90 standard, and the assembler code produced
by a typical C compiler is exemplary, and that this is the
basis for the lingua franca of programming.
 
(And while I don't think that an "appeal to authority" argument has much
merit, he did say that he found Linux "quite delightful" as a
continuation of UNIX, and I would not expect him to have viewed your OS
ideas as productive.)
 I'm not asking him to approve my OS ideas. I'm asking him
to explain what is wrong with the C90 that he approved of,
and whether my mentioned extensions are reasonable.
 
You can ask him anything you like - just don't be surprised if he does not answer.
I never knew Ritchie personally, and can only make guesses as to what he might think or say.  I would, however, be very surprised if he considered C90 to be "perfect" or in any sense complete, or that he disapproved of the C standards committee moving forward with the language.  I expect that like most of us, he would like some parts of each new standard, and dislike other parts - some parts he would find useful, and others not so much.  And he would be happy to accept that the language is not for him personally - it's fine to have features that are of use and interest to other people.

But Keith is absolutely correct here.  C90 is C90, and will remain that
way (baring the very unlikely possibility of minor technical corrections).
>
You can make your own libraries, and OS's, and extensions, and languages
- whatever makes you happy.  (And if you enjoy what you are doing, and
it's not harming anyone, then that's all the reason you need.  You don't
need approval from anyone else.  Don't let me or anyone else hinder you
enjoying yourself.)  However, nothing that you ever do will be an
extension to C90.
 You seem to have a different definition of "extension to C90" to me, then.
 
You suggested "extending C90" with the inclusion of your new functions. That's the definition of "extension to C90" I am using.

Which is also fine.
 Regardless, I intend to compete with the ISO committee, and
not so much start from scratch, as start from C90.
 
You don't lack ambition!

My branch may not appeal to a majority, but I'm not particularly
trying to appeal to a majority. I'm interested in appealing to the
people who I work with (e.g. author of pdld). And I'm also
interested in technical guidance from the majority who likely
have more technical skills than me, regardless of whether they
agree with my approach/goals or not (spoiler: they don't).
 
I have no problem with giving technical advice (if I have any that I think will be useful - I work with a significantly different type of programming, however).  But I think you'd get on a lot better if you said you were trying to write a C90 library of functions for directory access, and dropped the bizarre doomsday philosophy.  Choose C90 for maximal portability, or personal preference - that's fine.  Trying to convince other people that C90 is somehow "perfect" while C99 is a "complete and utter joke" is not going to get you much technical help. Telling us that you are doing all this to be "apocalypse-ready" simply brands you as a delusional nutcase.  And while I think delusional nutcases (as long as they are non-violent) have as much right to get technical answers as the next person, it really does distract from the C-related questions you have.

Date Sujet#  Auteur
20 May07:06 * encapsulating directory operations131Paul Edwards
20 May08:27 +* Re: encapsulating directory operations18Lawrence D'Oliveiro
20 May10:33 i`* Re: encapsulating directory operations17Paul Edwards
21 May01:10 i `* Re: encapsulating directory operations16Lawrence D'Oliveiro
21 May01:23 i  `* Re: encapsulating directory operations15Paul Edwards
21 May04:37 i   `* Re: encapsulating directory operations14Lawrence D'Oliveiro
21 May11:00 i    +* Re: encapsulating directory operations3Paul Edwards
22 May07:49 i    i`* Re: encapsulating directory operations2Lawrence D'Oliveiro
22 May08:02 i    i `- Re: encapsulating directory operations1Kaz Kylheku
22 May00:51 i    `* Re: encapsulating directory operations10James Kuyper
22 May06:04 i     `* Re: encapsulating directory operations9Lawrence D'Oliveiro
22 May19:13 i      `* Re: encapsulating directory operations8James Kuyper
22 May23:46 i       `* Re: encapsulating directory operations7Lawrence D'Oliveiro
23 May00:07 i        `* Re: encapsulating directory operations6James Kuyper
23 May00:15 i         `* Re: encapsulating directory operations5Kaz Kylheku
23 May00:26 i          +* Re: encapsulating directory operations2Paul Edwards
23 May01:44 i          i`- Re: encapsulating directory operations1Kaz Kylheku
23 May01:10 i          `* Re: encapsulating directory operations2James Kuyper
23 May03:08 i           `- Re: encapsulating directory operations1Kaz Kylheku
20 May10:18 +* Re: encapsulating directory operations56Keith Thompson
20 May10:33 i+* Re: encapsulating directory operations12Richard Heathfield
20 May10:45 ii+- Re: encapsulating directory operations1Paul Edwards
20 May12:42 ii+- Re: encapsulating directory operations1David Brown
20 May14:55 ii+* Re: encapsulating directory operations7Kaz Kylheku
20 May15:05 iii`* Re: encapsulating directory operations6Richard Heathfield
20 May15:09 iii +* Re: encapsulating directory operations2Muttley
20 May15:15 iii i`- Re: encapsulating directory operations1Paul Edwards
20 May15:48 iii `* Re: encapsulating directory operations3Paul Edwards
20 May16:02 iii  `* Re: encapsulating directory operations2Richard Heathfield
20 May16:28 iii   `- Re: encapsulating directory operations1Paul Edwards
23 May13:43 ii`* Re: encapsulating directory operations2Tim Rentsch
23 May14:27 ii `- Re: encapsulating directory operations1Richard Heathfield
20 May10:36 i`* Re: encapsulating directory operations43Paul Edwards
20 May13:23 i +* Re: encapsulating directory operations39David Brown
20 May14:47 i i`* Re: encapsulating directory operations38Paul Edwards
20 May15:37 i i +* Re: encapsulating directory operations10Richard Heathfield
20 May16:11 i i i`* Re: encapsulating directory operations9Paul Edwards
20 May16:43 i i i `* Re: encapsulating directory operations8Richard Heathfield
20 May22:15 i i i  +* Re: encapsulating directory operations2Paul Edwards
20 May23:50 i i i  i`- Re: encapsulating directory operations1Kaz Kylheku
21 May02:11 i i i  +- Re: encapsulating directory operations1Lawrence D'Oliveiro
21 May03:40 i i i  `* Re: encapsulating directory operations4James Kuyper
21 May05:50 i i i   `* Re: encapsulating directory operations3Richard Heathfield
21 May09:06 i i i    `* Re: encapsulating directory operations2David Brown
21 May09:27 i i i     `- Re: encapsulating directory operations1Richard Heathfield
20 May17:19 i i `* Re: encapsulating directory operations27David Brown
20 May17:43 i i  +* Re: encapsulating directory operations6Richard Heathfield
20 May18:14 i i  i+* Re: encapsulating directory operations4Kaz Kylheku
20 May18:20 i i  ii`* Re: encapsulating directory operations3Richard Heathfield
20 May19:50 i i  ii +- Re: encapsulating directory operations1Richard Heathfield
20 May20:34 i i  ii `- Re: encapsulating directory operations1Kaz Kylheku
21 May09:09 i i  i`- Re: encapsulating directory operations1David Brown
20 May17:51 i i  +- Re: encapsulating directory operations1Kaz Kylheku
20 May18:09 i i  +* Re: encapsulating directory operations2Richard Heathfield
20 May19:34 i i  i`- Re: encapsulating directory operations1Richard Heathfield
20 May22:41 i i  +* Re: encapsulating directory operations4Paul Edwards
20 May23:02 i i  i+- Re: encapsulating directory operations1Keith Thompson
21 May02:05 i i  i`* Re: encapsulating directory operations2Lawrence D'Oliveiro
21 May10:23 i i  i `- Re: encapsulating directory operations1Paul Edwards
20 May22:51 i i  +* Re: encapsulating directory operations9Paul Edwards
21 May05:31 i i  i`* Re: encapsulating directory operations8Richard Heathfield
21 May11:08 i i  i `* Re: encapsulating directory operations7Paul Edwards
21 May11:28 i i  i  +- Re: encapsulating directory operations1Richard Heathfield
21 May16:00 i i  i  `* Re: encapsulating directory operations5David Brown
21 May16:37 i i  i   `* Re: encapsulating directory operations4Richard Heathfield
21 May18:21 i i  i    +- Re: encapsulating directory operations1Michael S
22 May11:37 i i  i    `* Re: encapsulating directory operations2James Kuyper
22 May18:53 i i  i     `- Re: encapsulating directory operations1Kaz Kylheku
20 May23:09 i i  +- Re: encapsulating directory operations1Paul Edwards
21 May09:27 i i  `* Re: encapsulating directory operations3David Brown
21 May11:46 i i   `* Re: encapsulating directory operations2Paul Edwards
21 May15:46 i i    `- Re: encapsulating directory operations1David Brown
21 May01:12 i `* Re: encapsulating directory operations3Lawrence D'Oliveiro
21 May01:25 i  `* Re: encapsulating directory operations2Paul Edwards
21 May02:03 i   `- Re: encapsulating directory operations1Lawrence D'Oliveiro
20 May14:53 +* Re: encapsulating directory operations52Kaz Kylheku
20 May15:12 i`* Re: encapsulating directory operations51Paul Edwards
20 May22:41 i `* Re: encapsulating directory operations50Keith Thompson
20 May23:38 i  `* Re: encapsulating directory operations49Paul Edwards
21 May00:09 i   +* Re: encapsulating directory operations5Paul Edwards
21 May00:22 i   i+- Re: encapsulating directory operations1Keith Thompson
21 May01:18 i   i+* Re: encapsulating directory operations2Kaz Kylheku
21 May01:31 i   ii`- Re: encapsulating directory operations1Paul Edwards
21 May02:02 i   i`- Re: encapsulating directory operations1Lawrence D'Oliveiro
21 May00:18 i   +* Re: encapsulating directory operations34Keith Thompson
21 May00:57 i   i+* Re: encapsulating directory operations26Paul Edwards
21 May06:41 i   ii`* Re: encapsulating directory operations25Keith Thompson
21 May11:41 i   ii +* Re: encapsulating directory operations22Paul Edwards
21 May19:06 i   ii i+* Re: encapsulating directory operations19Keith Thompson
21 May19:22 i   ii ii+- Re: encapsulating directory operations1Keith Thompson
22 May22:10 i   ii ii+* Re: encapsulating directory operations14Paul Edwards
22 May23:32 i   ii iii+* Re: encapsulating directory operations12Keith Thompson
23 May00:16 i   ii iiii+* Re: encapsulating directory operations7Paul Edwards
23 May02:38 i   ii iiiii+- Re: encapsulating directory operations1Keith Thompson
23 May03:28 i   ii iiiii+* Re: encapsulating directory operations2Kaz Kylheku
23 May05:27 i   ii iiiiii`- Re: encapsulating directory operations1Keith Thompson
23 May06:08 i   ii iiiii`* Re: encapsulating directory operations3Janis Papanagnou
23 May06:20 i   ii iiiii `* Re: encapsulating directory operations2Keith Thompson
23 May06:43 i   ii iiiii  `- Re: encapsulating directory operations1Janis Papanagnou
23 May16:09 i   ii iiii`* Re: encapsulating directory operations4Richard Harnden
23 May17:50 i   ii iiii `* Re: encapsulating directory operations3Richard Heathfield
22 May23:44 i   ii iii`- Re: encapsulating directory operations1Paul Edwards
22 May23:06 i   ii ii`* Re: encapsulating directory operations3Paul Edwards
21 May20:31 i   ii i`* Re: encapsulating directory operations2Kaz Kylheku
22 May22:52 i   ii `* Re: encapsulating directory operations2Paul Edwards
21 May03:21 i   i`* Re: encapsulating directory operations7Kaz Kylheku
21 May03:26 i   +* Re: encapsulating directory operations7James Kuyper
21 May22:19 i   `* Re: encapsulating directory operations2Waldek Hebisch
21 May03:35 +* Re: encapsulating directory operations3Janis Papanagnou
22 May19:34 `- Re: encapsulating directory operations1Bonita Montero

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal