• Re: encapsulating directory operations

    From Keith Thompson@3:633/280.2 to All on Sat May 24 18:27:46 2025
    Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
    Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
    Richard Harnden <richard.harnden@gmail.invalid> writes:
    On 22/05/2025 23:32, Keith Thompson wrote:
    [...]
    In one of your library's headers:
    extern const char ESCAPE;
    In the corresponding *.c file:
    const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
    Change the name if you prefer.

    Wouldn't that be a reserved identifier?

    Yes, it would. Good catch.

    (Identifiers starting with E followed by either a digit or an uppercase
    letter are reserved; they could be defined as macros in <errno.h>.)

    They are reserved only as macros, and only if <errno.h> has
    been #include'd.

    For this particular use, it's easy to make the definition work,
    simply by adding

    #undef ESCAPE

    before the declaration in the header file, and before the
    definition in the source file (assuming of course that if
    there are any #include <errno.h> they precede the #undef's).

    It would be even easier to pick a different name.

    If I had a time machine and sufficient influence, I might make all
    the errno macros start with something more distinct, like E_ or ERR.
    But I don't.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    void Void(void) { Void(); } /* The recursive call of the void */

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: None to speak of (3:633/280.2@fidonet)
  • From Tim Rentsch@3:633/280.2 to All on Sun May 25 15:10:59 2025
    "Paul Edwards" <mutazilah@gmail.com> writes:

    Someone (Jean-Marc) wrote some "folder" routines which I like a lot.
    You can see them here:

    https://sourceforge.net/p/pdos/gitcode/ci/master/tree/hwzip/folder.c

    And in essence, when you read from a directory, the only
    thing you get is the filename. If it is actually a subdirectory,
    then that is indicated with a "/" at the end of the filename.

    [elaboration]

    Any thoughts (besides "get a life!")?

    I offer the following items of advice, after reading many of
    the postings in this thread.

    Stop thinking about what is faithful to the spirit of C90.
    All that matters is whether you think a feature or language
    construct is consistent with what you think of as C90.
    Nothing else.

    If you want to describe a language change, or addition,
    write a description in the style of a section of the
    ISO C standard, from section 6 or before. (Personally I
    think the writing in C99 or C11 is a little better
    than the writing in C90, but make a choice about which
    one you prefer and stick to it.)

    If you want to describe additional library functionality,
    write a description in the style of a section of the ISO C
    standard, from section 7.

    Learn how to write more clearly, more concisely, and more
    effectively in terms of communicating your thoughts to
    others. Write to convey, not to convince.

    Make all of the above your immediate priority, and nothing
    else, until descriptions of any and all new features and
    language constructs are complete.

    Don't give any feedback on the advice given here, whether you
    think it's good or it's bad or whatever. If you don't want to
    follow it, don't follow it; it makes no nevermind to me, nor I
    expect to anyone else. (And it is my request that no one else
    discuss it either, because doing so is worse than just a waste
    of time but actually counterproductive. This thread has gone
    on way too long already.)

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Mon May 26 07:54:10 2025
    "Janis Papanagnou" <janis_papanagnou+ng@hotmail.com> wrote in message news:100p1u4$3um4p$1@dont-email.me...
    On 23.05.2025 07:20, Keith Thompson wrote:
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
    [...]
    If you have created a separate library, advertise it so that it
    gets used, and if people are widely happy to have that library
    suggest it for inclusion. Then committees might pick it up (or
    not).

    Or it might *not* be included in the language standard because
    there's no need to do so. If a library is popular, programmers
    can just use it whether it's part of the standard library or not.
    Plenty of popular libraries are not part of the C standard library --
    and they don't need to be.

    Yes, sure. - I thought this was what I wrote [with other words];
    "might pick it up (or not)".

    Honestly, I still don't understand Paul's fixation on the standards
    track; i.e. beyond the good feeling one may have when contributing
    something [potentially] useful. If it's a sophisticated library and
    made available to the public that could be reward enough. (But who
    am I to judge. To each his own.)

    (sorry for the delay in replying)

    And here's a chance to clear up another point.

    It's none of those things.

    It's the other way around.

    I am religiously conforming to C90 and making all my tools, and my
    OS, to C90.

    I have been doing this for nearly 40 years.

    Even when people complained about MSDOS being "different",
    I didn't see any difference. I basically told them that they were
    wrong. The implementation they were using was conformant
    with the ANSI C draft - it's up to them to adjust, not MSDOS
    nor anything else. If they write their software "properly", it will
    work not just on MSDOS, but also on MVS.

    At the time I didn't know why people were plastering "near"
    and "far" keywords everywhere. In fact, I basically still don't.
    I simply choose an appropriate memory model.

    And I can remember talking to a long-term DOS programmer
    who stated that you couldn't do xyz without doing a BIOS
    call or directly manipulating the hardware. xyz might have
    been getting a single character from the keyboard. And I said
    no, you can get that with a standard read. You just need to
    do this devioctl call first.

    So that is the background. I just chose to follow C90,
    religiously.

    But the irony is I don't really have that as a religion - it
    just appears that way.

    When I understood the limits of C90, I had no religious
    qualms about changing/forking C90. Only practical.

    It has taken me nearly 40 years to find those limits.

    And now I am hitting those limits.

    E.g. I can't drive an EBCDIC X3.64 terminal unless C90
    provides an ESC define.

    And I can't do a "dir" either.

    And nor can I do a non-blocking peep.

    So now, belatedly, I am revisiting the C90 standard and
    asking about its limits, and whether they should exist and
    why they should exist.

    All this time that I was "investigating", the ISO C and most
    of the world had raced ahead, invalidating 36-bit machines,
    invalidating MVS (as they always had anyway), etc.

    I am now - belatedly - challenging that path of "development".

    It doesn't really matter to me whether I actually succeed in
    being more popular than the ISO strain of "development".

    What matters to me is whether C90+ or C90-refined is
    logical. And only if the C90 standard is sufficiently forked -
    because it is logical to do so - can I say my ecosystem is
    "completely portable".

    That's what C90 is all about after all - making things as
    completely portable as possible.

    My #define ESCAPE 0x1b is not portable. It won't work
    on EBCDIC. And crucially - it won't work on some other
    theoretical character set - even if it includes an ESC.

    So I have reached the limits of C90, and something has
    to give. Or it is "time for something to give".

    There are two ways to go.

    I could say "ANSI x3.64 terminals cannot be supported
    in a portable manner, and so I will use edlin for the rest
    of my life".

    Or I could say "change C90 so I can use microemacs".

    I'm happy to change (or work on changing) the entire
    mainframe ecosystem to switch from 3270 terminals
    to EBCDIC ANSI terminals.

    Actually succeeding in doing that (with or without
    coercion), is a separate exercise. And I don't really
    care if it happens or succeeds.

    What I care about is that I made a logical attempt to
    do so, which justifies my use of microemacs instead
    of edlin.

    At the end of the day, I'm trying to run microemacs,
    while sticking to my principle of being standards-conforming.

    I'm trying to run microemacs, not win Miss America.

    I can demonstrate microemacs running on a mainframe.
    So I know it is technically possible.

    But it violates C90 and there is currently no C90+ I can
    point to instead that my flavor of microemacs conforms to.

    That's the issue.

    If I had a C90+ I can start off by saying "the entire rest
    of the world is wrong and I am right for following C90+
    instead of C90 or a derivative".

    To the person who said I should write to convey, not
    convince - I'm not trying to convince anyone. I don't
    care if no-one in the world moves to C90+ except me.
    I'm just after the technical information required to
    write C90+.

    Making sure the identifier doesn't start with "E" is one
    example of that. I wouldn't have thought of that myself.

    I believe I will need some more identifiers for the
    microemacs keystrokes too - like ctrl-x, ctrl-s to save.

    The alternative (for me) is grim.

    edlin

    That's convey. Not convince.

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Mon May 26 08:12:03 2025
    "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87y0uot8b7.fsf@nosuchdomain.example.com...
    "Paul Edwards" <mutazilah@gmail.com> writes:

    But neither of these are in C23. Nor were they in C90.
    I want a slight variation to BOTH of those standards,
    and for the next ISO standard - C30 or whatever -
    to include that slight variation.

    (I didn't previously state this, because I wasn't aware
    of it, again)

    I don't believe

    You are correct to nuance things - an acknowledgement
    that you can't predict the future with 100% certainty.

    that you personally will have any influence over any
    future C standard. Your goals are too different from the goals of the committee and those of the vast majority of people who care about C.

    To me - this is a "mere challenge".

    In this case, the plan is that my "add-on library", is so
    small, and so useful, and hopefully so popular, that it
    gets standardized into a theoretical C30, as well as
    existing C90 libraries - including but not limited to
    PDPCLIB - updated to include this new feature, that,
    in hindsight, should have existed even in K&R C.

    In my opinion that will never happen.

    I am discussing a theoretical possibility, not making a
    hard prediction.

    I have no problem with whatever functionality you want to provide in
    your PDPCLIB, and I'm willing to discuss some of it in technical terms.

    Sure, thanks.

    It's just a library. It may or may not
    depend on features of the C90 standard library.

    No. It IS C90+.

    I don't know what you mean by that. If you mean that your PDPCLIB
    library IS "C90+", that's fine; both are your invented terms.
    But it's an odd choice of terminology.

    You are guessing what I am talking about, so I will try to
    explain.

    No. PDPCLIB *will be* one of the possible theoretical
    implementations of C90+.

    Right now, it is pure C90.

    Because right now, C90+ doesn't exist.

    As such, there is no ESCAPE or any other define in any existing
    or new header in PDPCLIB.

    And that's the problem - I don't know where to add it.
    As it turns out, the "defacto vague committee" made a
    determination that "ESCAPE" is not an appropriate
    name. I agree with the other members of the committee,
    and the original proposer - ie you - agreed with that
    "good catch".

    That's a pretty good result to me.

    If the other control characters are necessary for the
    operation of microemacs - which I believe they are -
    more than just ESCAPE needs to be added anyway.

    Which header file and what names - that don't start
    with "E"?

    This is intended to be in the official ISO C standard for the next
    1 million years.

    That will not happen.

    Even assuming that non-ESCAPE is never added to the
    ISO C standard - and I'm not sure how you can predict
    that - that doesn't stop it from being my INTENTION.

    Actually influencing ISO is a separate exercise.

    That will not happen either.

    What do you mean by that? Not one single member of
    the ISO committee will ever be influenced by a single
    thing I say? Even if I join the committee myself? Even if
    I bribe them? Even if I coerce them? Even if I stack the
    ISO committee with my friends (after making some
    friends - or bribing some people)?

    It probably won't involve coercion.

    But coercion wouldn't be required if the C90+ committee comes
    up with something reasonable.

    That sounds like a threat. If it is, I suggest you stick it where the
    sun don't shine. But as far as I know you have no ability to carry out
    your threat, so it's more pathetically amusing that frightening.

    You are correct that I have no ability to coerce anyone at all.
    Nor do I wish to do so even if I did. Nor did I even say it was
    required.

    It is a theoretical possibility.

    Don't assume you can predict the future.

    It never ever occurred to me that a US president would one
    day mull over invading an erstwhile ally (Denmark) in order
    to annex some territory (Greenland), that they are already on
    as invited guests.

    And if I am one day elected president of the USA, at the
    same time as Chancellor of Germany, and a few other
    places, you may well find 90% of the planet using it (or
    at least, having it on their system).

    See above regarding "where the sun don't shine".

    I only need 51% of the vote, not 100% of the vote.

    And I only said that 90% of the planet may be using
    my ecosystem, not 100%.

    You have no personal control over either those 51% or
    those 90%.

    We're both lobbying for their support.

    "Don't vote for Paul - he's going to replace the ISO
    C committee just so that he can run microemacs!!!".

    I don't think most voters will care as much about that
    issue as you apparently do. But we'll see ...

    And again - I don't actually care if I succeed. I'm happy
    to have just tried.

    Did you see "One Flew Over the Cuckoo's Nest"?

    The guy tries to lift the water cooler. It doesn't really
    bother him that he failed.

    A big Indian guy succeeded.

    Maybe one day a big Indian guy will read comp.lang.c
    and complete what I was unable to complete.

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Keith Thompson@3:633/280.2 to All on Mon May 26 08:29:05 2025
    "Paul Edwards" <mutazilah@gmail.com> writes:
    [...]
    E.g. I can't drive an EBCDIC X3.64 terminal unless C90
    provides an ESC define.
    [...]

    Of course you can. You can just use '\x27' in your code. It doesn't
    have to be part of the language standard. If you have an application
    that, for whatever reason, needs to drive both ASCII and EBCDIC
    terminals, you can configure it by any means you like to use
    '\x1b' or '\x27` (command-line argument, environment variable,
    configuration file, reply from the terminal, whatever).

    The idea that you can't do that without a constant defined in your
    language standard is just silly.

    [...]
    That's what C90 is all about after all - making things as
    completely portable as possible.
    [...]

    No, that's not what C90 was ever about. Very few C programs are
    completely portable, because they don't need to be.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    void Void(void) { Void(); } /* The recursive call of the void */

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: None to speak of (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Mon May 26 08:31:46 2025
    "Paul Edwards" <mutazilah@gmail.com> wrote in message news:10103i7$1jdii$1@dont-email.me...

    That's convey. Not convince.

    Oh yeah - an more "conveying".

    I am happy to invalidate the last (2025-1999) years of
    software that you wrote, with no moral qualms, the same
    way as you have no moral qualms about invalidating
    beautiful 36-bit machines every time you write int32_t,
    and invalidate beautiful MVS every time you #include
    unistd.h because there is no C90 function to do what
    you want, and you didn't propose a C90+ to add one,
    and you just insist MVS doesn't exist either way.

    Or use the term "not relevant today".

    There's the battle lines right there.

    I'm not particularly expecting to win, but I was thinking
    36-bit machines would be useful to me so that I can
    support a variation of VISCII without needing to take
    over control characters. I would be happy to take over
    control characters, but that was until I found that I
    probably need the box-drawing characters from code
    page 437 too.

    Post-edlin is microemacs. Post-microemacs is a text
    windowing system.

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Keith Thompson@3:633/280.2 to All on Mon May 26 08:34:12 2025
    "Paul Edwards" <mutazilah@gmail.com> writes:
    [...]
    It never ever occurred to me that a US president would one
    day [SNIP]

    I urge you to stick to the topic of this newsgroup. If you want
    to talk about politics, don't do it here. And if you want to talk
    about coercing or bribing members of the C committee or any similar
    antisocial behaviors, keep it to yourself.

    I can't stop you from posting here. I can ignore you.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    void Void(void) { Void(); } /* The recursive call of the void */

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: None to speak of (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Mon May 26 08:40:50 2025
    "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87a570jpe6.fsf@nosuchdomain.example.com...
    "Paul Edwards" <mutazilah@gmail.com> writes:
    [...]
    E.g. I can't drive an EBCDIC X3.64 terminal unless C90
    provides an ESC define.
    [...]

    Of course you can.

    I'm not disputing that it is physically possible.

    You're misinterpreting my "can't". I was going to say "you
    know what I mean", but maybe you don't.

    You can just use '\x27' in your code. It doesn't
    have to be part of the language standard. If you have an application
    that, for whatever reason, needs to drive both ASCII and EBCDIC
    terminals, you can configure it by any means you like to use
    '\x1b' or '\x27` (command-line argument, environment variable,
    configuration file, reply from the terminal, whatever).

    Yes, I agree those are standards-conforming alternatives.

    But not what I want. For reasons which are difficult for me
    to elaborate - "aesthetic", or "self-contained" may or may
    not be apt words - I want to include the ESCAPE in the
    C code, just like the "hello, world\n" bit.

    The C90 committee didn't force me to accept "\n" from a
    config file, so that I could have CRLF on MSDOS.

    The idea that you can't do that without a constant defined in your
    language standard is just silly.

    It may be silly from your perspective, but for me it is
    crucial.

    That's what C90 is all about after all - making things as
    completely portable as possible.

    No, that's not what C90 was ever about. Very few C programs are
    completely portable, because they don't need to be.

    I dispute the "don't need to be".

    And even if you insist that about everyone else, it doesn't
    apply to me.

    I want my programs to be "completely portable", meaning
    "conform to hosted C90 rules" or "conform to hosted C90+
    rules". Those are the only two choices.

    Also - something else I didn't mention.

    Even if I got my C90+ changes into a future C30 standard -
    that's still not good enough. Whether it takes C40, or C50,
    or C60000000 - one day I intend for it to align with C90+.

    If that means invalidating 60 million years worth of C
    development - so be it. You should have read comp.lang.c
    in 2025. It was always an OOB question.

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Mon May 26 09:01:54 2025
    "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:875xhojp5n.fsf@nosuchdomain.example.com...

    And if you want to talk
    about coercing or bribing members of the C committee or any similar antisocial behaviors

    I'm not really antisocial. They are theoretical possibilities
    that can't be ruled out. No matter how absurd you believe
    them to be - and I would tentatively agree - but I have
    been burnt too many times to pretend that I can predict
    the future.

    In more practical terms, it is as per the original article I
    posted from Jeff. He - like me - believes that the IT
    industry is a case of the inmates are running the asylum.

    I sense an opportunity - possibly a commercial opportunity -
    here.

    The existing software is too complicated to maintain, and
    systems are failing. Have you seen the movie "Idiocracy"?
    I believe it is already happening.

    PDOS is basically as simple as I can make it. That also
    means it has the most chance of being maintainable.

    The supporting infrastructure has one thing that is too
    complicated to maintain - gcc.

    That can currently be treated as a black box. cc64 is
    in the same boat.

    We have been attempting for years/decades to stand
    up a replacement, but it hasn't happened yet.

    At some point I may be able to run bank software,
    where my bank software is on a fully understood by
    normal programmers - not a few freaks that are dying
    out - system, and so some bank that uses my software
    is more competitive than other banks that use the
    latest 2048-bit system with 5000 Tbps fiber optic
    connections, that is permanently broken at the software
    side - or even if it is on the hardware side - no-one
    can detect that, because they can't prove - or even
    report - it - via software - to the hardware engineers
    so that they can correct it.

    I've seen that first hand. On a POSIX system, we were
    getting intermittent hangs on the software side. And I
    think we didn't even know whether it was on the disk
    or network side.

    I told them this is not something for us application
    programmers to solve - we need systems programming
    support, who will then liase with the OS, 3rd party
    software, and hardware manufacturers as required.

    "what's a system programmer?".

    (that's a term familiar on MVS)

    It was a complete clown show. Again - I'm not alone.
    Jeff in the original link expressed it very nicely.

    I think it was solved when multiple bits of third party
    software were downgraded.

    As far as I know, the problem was never isolated and
    reported to a vendor.

    Certainly whenever Windows freezes on me, I don't
    report it to Microsoft.

    You can report PDOS bugs to me easily though, and
    at least to date, they are investigated without charge.

    You can sort of do that with any bugs in MVS (z/OS)
    too.

    That's the only competitor to PDOS I'm aware of,
    and indeed, I would encourage you to use my
    competitor, rather than PDOS, for now.

    I am already aware that your (non-specific reader)
    mileage varies, but you're welcome to repeat that
    anyway. And it will be ignored, as usual. I already
    know we (non-specific) have different goals too.

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Kenny McCormack@3:633/280.2 to All on Mon May 26 09:25:06 2025
    In article <875xhojp5n.fsf@nosuchdomain.example.com>,
    Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    "Paul Edwards" <mutazilah@gmail.com> writes:
    [...]
    It never ever occurred to me that a US president would one
    day [SNIP]

    I urge you to stick to the topic of this newsgroup. If you want
    to talk about politics, don't do it here. And if you want to talk
    about coercing or bribing members of the C committee or any similar >antisocial behaviors, keep it to yourself.

    I can't stop you from posting here. I can ignore you.

    You should have done that long ago.

    It is clear that you and Paul are not even on the same planet in terms of
    what you are talking about. Whatever made you think you two could
    communicate?

    Really, Keith, you don't have to respond to every single thread. You don't have to assert your control and dominance in every single battle. Instead,
    you need to carefully pick the ones in which your particular brand of
    blather will be appreciated.

    --
    I'll give him credit for one thing: He is (& will be) the most quotable President
    ever. Books have been written about (GW) Bushisms, but Dubya's got nothing on Trump.

    Tremendously wet - from the standpoint of water.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: The official candy of the new Millennium (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Mon May 26 09:48:46 2025
    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100oicc$3ob15$3@dont-email.me...
    On Fri, 23 May 2025 07:52:27 +1000, Paul Edwards wrote:

    Moreover, what is the definition of 'character' in this context?

    Something that fgetc() would be able to consume without blocking.

    That wouldn't cope with Unicode. Anything that can't cope with Unicode
    isn't going to be considered very useful nowadays.

    "people nowadays" don't speak with one voice.

    I may well be a minority, but I don't have a need to support
    Unicode. I'm more interested in a modified VISCII than
    Unicode.

    fgetc() won't hang on a single character in either case.

    And I consider it to be useful, even if I am literally alone,
    and remain alone forever. I can't prove that I'm alone
    though. I have no idea who is "out there".

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Mon May 26 10:15:19 2025
    On Mon, 26 May 2025 09:48:46 +1000, Paul Edwards wrote:

    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100oicc$3ob15$3@dont-email.me...

    On Fri, 23 May 2025 07:52:27 +1000, Paul Edwards wrote:

    Moreover, what is the definition of 'character' in this context?

    Something that fgetc() would be able to consume without blocking.

    That wouldn't cope with Unicode. Anything that can't cope with Unicode
    isn't going to be considered very useful nowadays.

    "people nowadays" don't speak with one voice.

    Nor with one language. Which is why we have Unicode.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Janis Papanagnou@3:633/280.2 to All on Mon May 26 11:29:13 2025
    On 26.05.2025 00:40, Paul Edwards wrote:
    "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87a570jpe6.fsf@nosuchdomain.example.com...

    You can just use '\x27' in your code. It doesn't
    have to be part of the language standard. If you have an application
    that, for whatever reason, needs to drive both ASCII and EBCDIC
    terminals, you can configure it by any means you like to use
    '\x1b' or '\x27` (command-line argument, environment variable,
    configuration file, reply from the terminal, whatever).

    Yes, I agree those are standards-conforming alternatives.

    But not what I want. For reasons which are difficult for me
    to elaborate - "aesthetic", or "self-contained" may or may
    not be apt words - I want to include the ESCAPE in the
    C code, just like the "hello, world\n" bit.

    Doesn't '\e' work for you?

    char * str = "\e";
    puts (str);

    printf ("\e\n");

    putchar ('\e');
    putchar ('\n');

    Works for me. - Is that non-standard?

    $ cc -std=c90 escape.c
    $ a.out | od -c
    0000000 033 \n 033 \n 033 \n


    The C90 committee didn't force me to accept "\n" from a
    config file, so that I could have CRLF on MSDOS.

    If what you want as "escape" is a semantical name also on your
    EBCDIC systems then I'd expect a compiler to use the correct
    encoding for '\e'.

    (If OTOH that "escape" isn't a general semantical term then it
    wouldn't be reflected by the compiler; you certainly cannot
    expect it be defined through a _configuration_ file.)

    Janis

    [...]


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Janis Papanagnou@3:633/280.2 to All on Mon May 26 11:37:28 2025
    On 25.05.2025 23:54, Paul Edwards wrote:
    "Janis Papanagnou" <janis_papanagnou+ng@hotmail.com> wrote in message news:100p1u4$3um4p$1@dont-email.me...
    On 23.05.2025 07:20, Keith Thompson wrote:
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
    [...]
    If you have created a separate library, advertise it so that it
    gets used, and if people are widely happy to have that library
    suggest it for inclusion. Then committees might pick it up (or
    not).

    Or it might *not* be included in the language standard because
    there's no need to do so. If a library is popular, programmers
    can just use it whether it's part of the standard library or not.
    Plenty of popular libraries are not part of the C standard library --
    and they don't need to be.

    Yes, sure. - I thought this was what I wrote [with other words];
    "might pick it up (or not)".

    Honestly, I still don't understand Paul's fixation on the standards
    track; i.e. beyond the good feeling one may have when contributing
    something [potentially] useful. If it's a sophisticated library and
    made available to the public that could be reward enough. (But who
    am I to judge. To each his own.)

    (sorry for the delay in replying)

    No worries.

    [snip many lines]

    tldr;

    Your posts are many and always also very long, with repetitions, but
    rarely clarifying things [for me], they also appear incoherent to me.
    So bear with me if I now occasionally skip (some of your) long posts.
    If you have a clear desire I'd think it could be formulated tersely
    (or its content be reconsidered to gain more clarity before posting).

    Janis


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Mon May 26 11:46:32 2025
    "Janis Papanagnou" <janis_papanagnou+ng@hotmail.com> wrote in message news:1010g5b$1lr7o$1@dont-email.me...
    On 26.05.2025 00:40, Paul Edwards wrote:
    "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87a570jpe6.fsf@nosuchdomain.example.com...

    You can just use '\x27' in your code. It doesn't
    have to be part of the language standard. If you have an application
    that, for whatever reason, needs to drive both ASCII and EBCDIC
    terminals, you can configure it by any means you like to use
    '\x1b' or '\x27` (command-line argument, environment variable,
    configuration file, reply from the terminal, whatever).

    Yes, I agree those are standards-conforming alternatives.

    But not what I want. For reasons which are difficult for me
    to elaborate - "aesthetic", or "self-contained" may or may
    not be apt words - I want to include the ESCAPE in the
    C code, just like the "hello, world\n" bit.

    Doesn't '\e' work for you?

    That's not part of C90, nor even C23.

    Which means there are lot of compilers - some of which I still use -
    that don't have that, and are never likely to be updated - even
    with a patch.

    The C90 committee didn't force me to accept "\n" from a
    config file, so that I could have CRLF on MSDOS.

    If what you want as "escape" is a semantical name also on your
    EBCDIC systems then I'd expect a compiler to use the correct
    encoding for '\e'.

    Yes - had they done that.

    Even then, I still need control characters for microemacs.

    (If OTOH that "escape" isn't a general semantical term then it
    wouldn't be reflected by the compiler; you certainly cannot
    expect it be defined through a _configuration_ file.)

    I'm expecting to be defined through a header file.

    Not necessarily one of the ones that already exist in C90.

    Not necessarily not, either.

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Mon May 26 11:50:30 2025
    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:1010bqn$1l25r$1@dont-email.me...
    On Mon, 26 May 2025 09:48:46 +1000, Paul Edwards wrote:

    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100oicc$3ob15$3@dont-email.me...

    On Fri, 23 May 2025 07:52:27 +1000, Paul Edwards wrote:

    Moreover, what is the definition of 'character' in this context?

    Something that fgetc() would be able to consume without blocking.

    That wouldn't cope with Unicode. Anything that can't cope with Unicode
    isn't going to be considered very useful nowadays.

    "people nowadays" don't speak with one voice.

    Nor with one language. Which is why we have Unicode.

    Which is one solution to the problem.

    Just not a solution I agree with.

    I prefer VISCII-like, possibly requiring a 9-bit char, and
    invalidating all applications with POSIX assumptions.

    Other solutions could involve forcing everyone to use
    English. Another solution I'm not in favor of - at least
    not right now. I'm pretty happy with what C90 came
    up with. The standard was delayed for a year because
    of that, I believe I read.

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From vallor@3:633/280.2 to All on Mon May 26 14:05:25 2025
    On Mon, 26 May 2025 08:40:50 +1000, "Paul Edwards" <mutazilah@gmail.com>
    wrote in <101069l$1k3nm$1@dont-email.me>:

    The idea that you can't do that without a constant defined in your
    language standard is just silly.

    It may be silly from your perspective, but for me it is crucial.

    I've x-posted this to comp.programming, and set followup-to there.

    I'm wondering why your control-character-handling wouldn't be better
    handled with a curses library. IIRC, back in my DOS days (early 90's),
    there was a curses library for DOS.

    A quick look around found this: https://pdcurses.org/ ...which
    includes DOS support.

    If it doesn't handle EBCDIC terminal escapes, consider extending it.

    I don't know anything about microemacs, but if it doesn't use a curses-like library to handle different terminal types, I'd be surprised. I see that Linus' uemacs uses curses:

    https://github.com/torvalds/uemacs/blob/master/tcap.c

    Again, followup-to comp.programming, as this is definitely off-topic
    for comp.lang.c.

    --
    -v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
    OS: Linux 6.14.8 Release: Mint 22.1 Mem: 258G
    "Conformity obstructs progress."

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: ---:- FTN<->UseNet Gate -:--- (3:633/280.2@fidonet)
  • From James Kuyper@3:633/280.2 to All on Mon May 26 23:43:07 2025
    On 5/25/25 21:29, Janis Papanagnou wrote:
    On 26.05.2025 00:40, Paul Edwards wrote:
    ....
    But not what I want. For reasons which are difficult for me
    to elaborate - "aesthetic", or "self-contained" may or may
    not be apt words - I want to include the ESCAPE in the
    C code, just like the "hello, world\n" bit.

    Doesn't '\e' work for you?

    char * str = "\e";
    puts (str);

    printf ("\e\n");

    putchar ('\e');
    putchar ('\n');

    Works for me. - Is that non-standard?

    Yes. It's a common extension.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Tue May 27 03:16:53 2025
    On 2025-05-26, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
    On 5/25/25 21:29, Janis Papanagnou wrote:
    On 26.05.2025 00:40, Paul Edwards wrote:
    ...
    But not what I want. For reasons which are difficult for me
    to elaborate - "aesthetic", or "self-contained" may or may
    not be apt words - I want to include the ESCAPE in the
    C code, just like the "hello, world\n" bit.

    Doesn't '\e' work for you?

    char * str = "\e";
    puts (str);

    printf ("\e\n");

    putchar ('\e');
    putchar ('\n');

    Works for me. - Is that non-standard?

    Yes. It's a common extension.

    If that's not available in compilers for IBM mainframes in such a way
    that it produces the EBCDIC escape, then it doesn't solve Paul's
    "problem" anyway.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Peter 'Shaggy' Haywood@3:633/280.2 to All on Mon May 26 15:19:36 2025
    Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May 2025
    10:43 pm. It's a cool scene! Dig it.

    C99 is just as stable as C90, and has been for well over a
    decade.

    Methinks Tim is having trouble with his arithmetic. Either that or he
    doesn't know what year it is now. :)
    C99 was ratified in 1999, over two and a half decades ago.

    C11 is just as stable as C90, and has been for just slightly
    less than a decade.

    And C11 was ratified in 2011, no? That was almost a decade and a half
    ago.

    --


    ----- Dig the NEW and IMPROVED news sig!! -----


    -------------- Shaggy was here! ---------------
    Ain't I'm a dawg!!

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From David Brown@3:633/280.2 to All on Wed May 28 00:23:22 2025
    On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote:
    Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May 2025
    10:43 pm. It's a cool scene! Dig it.

    C99 is just as stable as C90, and has been for well over a
    decade.

    Methinks Tim is having trouble with his arithmetic. Either that or he doesn't know what year it is now. :)
    C99 was ratified in 1999, over two and a half decades ago.

    C11 is just as stable as C90, and has been for just slightly
    less than a decade.

    And C11 was ratified in 2011, no? That was almost a decade and a half
    ago.


    Tim was, I believe, taking into account the time it took for common implementations of C compilers and libraries to have complete and
    generally bug-free support for the standards, and for these
    implementations to become common. C99 was published in 1999, but it
    took quite a while before most people programming in C could happily use
    C99 without worrying about the tool support being "experimental" or not
    as mature as C90 support.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Michael S@3:633/280.2 to All on Wed May 28 01:10:41 2025
    On Tue, 27 May 2025 16:23:22 +0200
    David Brown <david.brown@hesbynett.no> wrote:

    On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote:
    Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May
    2025 10:43 pm. It's a cool scene! Dig it.

    C99 is just as stable as C90, and has been for well over a
    decade.

    Methinks Tim is having trouble with his arithmetic. Either that
    or he doesn't know what year it is now. :)
    C99 was ratified in 1999, over two and a half decades ago.

    C11 is just as stable as C90, and has been for just slightly
    less than a decade.

    And C11 was ratified in 2011, no? That was almost a decade and a
    half ago.


    Tim was, I believe, taking into account the time it took for common implementations of C compilers and libraries to have complete and
    generally bug-free support for the standards, and for these
    implementations to become common. C99 was published in 1999, but it
    took quite a while before most people programming in C could happily
    use C99 without worrying about the tool support being "experimental"
    or not as mature as C90 support.



    I believe that your belief is wrong.
    It is much more likely that Tim took into account defect reports.
    Here is the list of C11 defect reports with the last dated 2016: https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm

    I did not find similar list for C99. However believing Tim I would guess
    that the last change in C99 document was made ~15 years ago.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From David Brown@3:633/280.2 to All on Wed May 28 03:24:45 2025
    On 27/05/2025 17:10, Michael S wrote:
    On Tue, 27 May 2025 16:23:22 +0200
    David Brown <david.brown@hesbynett.no> wrote:

    On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote:
    Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May
    2025 10:43 pm. It's a cool scene! Dig it.

    C99 is just as stable as C90, and has been for well over a
    decade.

    Methinks Tim is having trouble with his arithmetic. Either that
    or he doesn't know what year it is now. :)
    C99 was ratified in 1999, over two and a half decades ago.

    C11 is just as stable as C90, and has been for just slightly
    less than a decade.

    And C11 was ratified in 2011, no? That was almost a decade and a
    half ago.


    Tim was, I believe, taking into account the time it took for common
    implementations of C compilers and libraries to have complete and
    generally bug-free support for the standards, and for these
    implementations to become common. C99 was published in 1999, but it
    took quite a while before most people programming in C could happily
    use C99 without worrying about the tool support being "experimental"
    or not as mature as C90 support.



    I believe that your belief is wrong.
    It is much more likely that Tim took into account defect reports.
    Here is the list of C11 defect reports with the last dated 2016: https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm

    I did not find similar list for C99. However believing Tim I would guess
    that the last change in C99 document was made ~15 years ago.


    That sounds like a more plausible explanation than mine. You could say
    that my suggestion is "stable in practice", while the defect reports are "stable in theory". I think "stable in practice" is of greater
    importance to most programmers, but I believe it would be more in
    character for Tim to emphasis "stable in theory". In either case, I
    think it is fair to say that C99 and C11 are both very stable versions
    of C, and by now are just as suitable choices as C90 for most (but not
    all) purposes.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Tim Rentsch@3:633/280.2 to All on Wed May 28 09:16:50 2025
    Michael S <already5chosen@yahoo.com> writes:

    On Tue, 27 May 2025 16:23:22 +0200
    David Brown <david.brown@hesbynett.no> wrote:

    On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote:

    Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May
    2025 10:43 pm. It's a cool scene! Dig it.

    C99 is just as stable as C90, and has been for well over a
    decade.

    Methinks Tim is having trouble with his arithmetic. Either that
    or he doesn't know what year it is now. :)
    C99 was ratified in 1999, over two and a half decades ago.

    C11 is just as stable as C90, and has been for just slightly
    less than a decade.

    And C11 was ratified in 2011, no? That was almost a decade and a
    half ago.

    Tim was, I believe, taking into account the time it took for common
    implementations of C compilers and libraries to have complete and
    generally bug-free support for the standards, and for these
    implementations to become common. C99 was published in 1999, but it
    took quite a while before most people programming in C could happily
    use C99 without worrying about the tool support being "experimental"
    or not as mature as C90 support.

    I believe that your belief is wrong.
    It is much more likely that Tim took into account defect reports.
    Here is the list of C11 defect reports with the last dated 2016: https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm

    I did not find similar list for C99. However believing Tim I would guess that the last change in C99 document was made ~15 years ago.

    You are partly right. Besides defect reports, there are TCs. And
    there is always the possibility of future TCs, future defect
    reports, or future changes for any ISO C standard while it is
    still current.

    To be as stable as C90, a C standard would need to be immune to
    the possibility of such future changes.

    I take C99 to have reached this level of stability in 2011, when
    it was superseded by C11. I take C11 to have reached this level
    of stability in 2017, when it was superseded by C17.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Tim Rentsch@3:633/280.2 to All on Wed May 28 09:18:29 2025
    Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> writes:

    Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May 2025
    10:43 pm. It's a cool scene! Dig it.

    C99 is just as stable as C90, and has been for well over a
    decade.

    Methinks Tim is having trouble with his arithmetic. Either that or he doesn't know what year it is now. :)
    C99 was ratified in 1999, over two and a half decades ago.

    C11 is just as stable as C90, and has been for just slightly
    less than a decade.

    And C11 was ratified in 2011, no? That was almost a decade and a half
    ago.

    Amusing that you have such a low opinion of my mental
    faculties. :)

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Tim Rentsch@3:633/280.2 to All on Wed May 28 22:41:02 2025
    Richard Heathfield <rjh@cpax.org.uk> writes:

    On 24/05/2025 06:32, Tim Rentsch wrote:

    Richard Heathfield <rjh@cpax.org.uk> writes:

    On 23/05/2025 13:43, Tim Rentsch wrote:

    Richard Heathfield <rjh@cpax.org.uk> writes:

    On 20/05/2025 10:18, Keith Thompson wrote:

    C90 will never be extended.

    And for that reason it will always be valuable. Stability
    has a value all its own.

    C99 is just as stable as C90, and has been for well over a
    decade.

    Sure, but it's a different stable.

    If it were the same stable, it would be C90.

    C99 isn't C90, therefore it isn't the same stable.

    If you tell me C99 is a rock, I will not doubt you. But the C90
    rock it most certainly isn't.

    Now you're being silly.

    No, sir. If you want to play that game, you can play it with
    yourself. I know that you are perfectly capable of polite
    conversation, so I see no reason to endure the opposite.

    I don't think I'm being impolite. I think your comments
    were deliberately playing games with language, to make a
    point that has nothing to do with what I said. I don't
    think it's rude or even inconsiderate to point that out.
    If someone wants to say it could have been pointed out in
    a better way, okay, probably it could have been, but it
    wasn't meant as a personal comment, and I think that was
    evident from the rest of what I said (which was left out
    in your followup message).

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Michael S@3:633/280.2 to All on Wed May 28 23:04:15 2025
    On Tue, 27 May 2025 16:16:50 -0700
    Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

    Michael S <already5chosen@yahoo.com> writes:

    On Tue, 27 May 2025 16:23:22 +0200
    David Brown <david.brown@hesbynett.no> wrote:

    On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote:

    Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May
    2025 10:43 pm. It's a cool scene! Dig it.

    C99 is just as stable as C90, and has been for well over a
    decade.

    Methinks Tim is having trouble with his arithmetic. Either
    that or he doesn't know what year it is now. :)
    C99 was ratified in 1999, over two and a half decades ago.

    C11 is just as stable as C90, and has been for just slightly
    less than a decade.

    And C11 was ratified in 2011, no? That was almost a decade
    and a half ago.

    Tim was, I believe, taking into account the time it took for common
    implementations of C compilers and libraries to have complete and
    generally bug-free support for the standards, and for these
    implementations to become common. C99 was published in 1999, but
    it took quite a while before most people programming in C could
    happily use C99 without worrying about the tool support being
    "experimental" or not as mature as C90 support.

    I believe that your belief is wrong.
    It is much more likely that Tim took into account defect reports.
    Here is the list of C11 defect reports with the last dated 2016: https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm

    I did not find similar list for C99. However believing Tim I would
    guess that the last change in C99 document was made ~15 years ago.

    You are partly right. Besides defect reports, there are TCs. And
    there is always the possibility of future TCs, future defect
    reports, or future changes for any ISO C standard while it is
    still current.

    To be as stable as C90, a C standard would need to be immune to
    the possibility of such future changes.

    I take C99 to have reached this level of stability in 2011, when
    it was superseded by C11. I take C11 to have reached this level
    of stability in 2017, when it was superseded by C17.

    Got it. Stability occurs when the standards is fenced from changes by
    presence of the next edition.
    Stability by obsolescence.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Wed May 28 23:10:47 2025
    On 28/05/2025 13:41, Tim Rentsch wrote:
    Richard Heathfield <rjh@cpax.org.uk> writes:

    On 24/05/2025 06:32, Tim Rentsch wrote:

    Richard Heathfield <rjh@cpax.org.uk> writes:

    On 23/05/2025 13:43, Tim Rentsch wrote:

    Richard Heathfield <rjh@cpax.org.uk> writes:

    On 20/05/2025 10:18, Keith Thompson wrote:

    C90 will never be extended.

    And for that reason it will always be valuable. Stability
    has a value all its own.

    C99 is just as stable as C90, and has been for well over a
    decade.

    Sure, but it's a different stable.

    If it were the same stable, it would be C90.

    C99 isn't C90, therefore it isn't the same stable.

    If you tell me C99 is a rock, I will not doubt you. But the C90
    rock it most certainly isn't.

    Now you're being silly.

    No, sir. If you want to play that game, you can play it with
    yourself. I know that you are perfectly capable of polite
    conversation, so I see no reason to endure the opposite.

    I don't think I'm being impolite.

    Then we are again in disagreement, and it seems obvious that it
    would be foolishly optimistic of me to expect to be able to
    resolve the matter. I'll tell Thunderbird to leave it there.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Thu May 29 08:54:47 2025
    On 2025-05-28, Michael S <already5chosen@yahoo.com> wrote:
    Got it. Stability occurs when the standards is fenced from changes by presence of the next edition.

    Each technical corrigendum effectively yields a new edition.

    The previous standard without that corrigendum is forever stable,
    as any immutable object.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Thu May 29 17:21:53 2025
    On Wed, 21 May 2025 19:23:45 +1000, Paul Edwards wrote:

    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100j8t8$2g75r$5@dont-email.me...

    On Wed, 21 May 2025 07:41:12 +1000, Paul Edwards wrote:

    Basically the software industry is a joke. The advances have all been
    done by hardware engineers.

    Didn't they use software to manage that?

    Yes - as the guy (Jeff) said - software written by lunatics/artists.

    Was RCU invented by the hardware guys, or the software guys?

    What about journalling? Two-phase commit? Diffie-Hellman? RSA? Kerberos? kexec?

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Thu May 29 17:26:02 2025
    On Mon, 26 May 2025 11:50:30 +1000, Paul Edwards wrote:

    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:1010bqn$1l25r$1@dont-email.me...

    On Mon, 26 May 2025 09:48:46 +1000, Paul Edwards wrote:

    "people nowadays" don't speak with one voice.

    Nor with one language. Which is why we have Unicode.

    Which is one solution to the problem.

    Just not a solution I agree with.

    It’s the one most of the nations of the world agree with.

    I prefer VISCII-like, possibly requiring a 9-bit char, and invalidating
    all applications with POSIX assumptions.

    Are you going to set up your own UN as well? You could call it the “World Series of Nations” ...

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Thu May 29 17:27:45 2025
    On Fri, 23 May 2025 23:13:20 +0100, Richard Heathfield wrote:

    And who cares about future instability if C90 remains just as stable as
    ever it was?

    Even with the problems with const?

    char *strstr(const char *haystack, const char *needle);

    Dennis Ritchie pointed out the trouble with that.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From David Brown@3:633/280.2 to All on Thu May 29 18:21:54 2025
    On 29/05/2025 00:54, Kaz Kylheku wrote:
    On 2025-05-28, Michael S <already5chosen@yahoo.com> wrote:
    Got it. Stability occurs when the standards is fenced from changes by
    presence of the next edition.

    Each technical corrigendum effectively yields a new edition.

    The previous standard without that corrigendum is forever stable,
    as any immutable object.


    They also tend to have a very small impact on the practical
    implementations of the standards. AFAIK the TC's have all been small
    changes to the wording of the standard to improve clarity, rather than changing the language as implemented by toolchains.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Thu May 29 18:39:51 2025
    On 29/05/2025 08:27, Lawrence D'Oliveiro wrote:
    On Fri, 23 May 2025 23:13:20 +0100, Richard Heathfield wrote:

    And who cares about future instability if C90 remains just as stable as
    ever it was?

    Even with the problems with const?

    char *strstr(const char *haystack, const char *needle);

    Dennis Ritchie pointed out the trouble with that.

    Is C90 perfect? No, of course not. "C is quirky, flawed, and an
    enormous success."

    Is there value in having a powerful, widely-available language
    that, when you turn your back for a moment, stays *exactly* where
    you left it? Hell, yes.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Thu May 29 19:37:38 2025
    On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:

    On 29/05/2025 08:27, Lawrence D'Oliveiro wrote:

    On Fri, 23 May 2025 23:13:20 +0100, Richard Heathfield wrote:

    And who cares about future instability if C90 remains just as stable
    as ever it was?

    Even with the problems with const?

    char *strstr(const char *haystack, const char *needle);

    Dennis Ritchie pointed out the trouble with that.

    Is C90 perfect? No, of course not.

    Is there some value in that particular state of imperfection? Like the
    Amish, whose concept of the ideal level of technology is the one that was
    in effect at the time they were founded? And who have remained stuck at
    that point in time ever since?

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From James Kuyper@3:633/280.2 to All on Thu May 29 20:11:17 2025
    On 5/29/25 05:37, Lawrence D'Oliveiro wrote:
    On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:
    ....
    Is C90 perfect? No, of course not.

    Is there some value in that particular state of imperfection? Like the Amish, whose concept of the ideal level of technology is the one that was
    in effect at the time they were founded? And who have remained stuck at
    that point in time ever since?

    That's not actually the case. The Amish have slowly adopted more
    advanced levels of technology as the people around them have adopted
    farm more advanced ones. The important thing, from their point of view,
    it not a particular level of technology, but to maintain a clear
    distinction between them and the non-Amish.
    Which means that they are more adaptable than Richard is.
    Also note that different groups of Amish have different attitudes about
    what the correct technology level is.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Thu May 29 22:38:37 2025
    On 29/05/2025 10:37, Lawrence D'Oliveiro wrote:
    On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:

    On 29/05/2025 08:27, Lawrence D'Oliveiro wrote:

    On Fri, 23 May 2025 23:13:20 +0100, Richard Heathfield wrote:

    And who cares about future instability if C90 remains just as stable
    as ever it was?

    Even with the problems with const?

    char *strstr(const char *haystack, const char *needle);

    Dennis Ritchie pointed out the trouble with that.

    Is C90 perfect? No, of course not.

    Is there some value in that particular state of imperfection?

    Yes.

    Like the
    Amish, whose concept of the ideal level of technology is the one that was
    in effect at the time they were founded? And who have remained stuck at
    that point in time ever since?

    No, not even remotely like that.

    If I want C++, I know where to find it. If I want Python, I know
    where to find it. If I want Rust, I know where to find it.

    You can have new tools without breaking the old ones. We didn't
    have to change BCPL to get B, or B to get C, or C to get D or C++.

    This really is a very simple point, but perhaps a simple analogy
    will help to clarify it. You don't throw out your 3/4" just
    because you've bought a 19mm. There is room for both in the
    toolbox, and why write 3/4" on your new spanner? It /isn't/ a
    3/4" spanner even though it's very like it, so why pretend otherwise?

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Thu May 29 22:41:13 2025
    On 29/05/2025 11:11, James Kuyper wrote:
    On 5/29/25 05:37, Lawrence D'Oliveiro wrote:
    On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:
    ...
    Is C90 perfect? No, of course not.

    Is there some value in that particular state of imperfection? Like the
    Amish, whose concept of the ideal level of technology is the one that was
    in effect at the time they were founded? And who have remained stuck at
    that point in time ever since?

    That's not actually the case. The Amish have slowly adopted more
    advanced levels of technology as the people around them have adopted
    farm more advanced ones. The important thing, from their point of view,
    it not a particular level of technology, but to maintain a clear
    distinction between them and the non-Amish.
    Which means that they are more adaptable than Richard is.

    They use a lot of C++, do they?

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Fri May 30 01:06:40 2025
    Reply-To: slp53@pacbell.net

    Lawrence D'Oliveiro <ldo@nz.invalid> writes:
    On Wed, 21 May 2025 19:23:45 +1000, Paul Edwards wrote:

    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message
    news:100j8t8$2g75r$5@dont-email.me...

    On Wed, 21 May 2025 07:41:12 +1000, Paul Edwards wrote:

    Basically the software industry is a joke. The advances have all been
    done by hardware engineers.

    Didn't they use software to manage that?

    Yes - as the guy (Jeff) said - software written by lunatics/artists.

    Was RCU invented by the hardware guys, or the software guys?

    It was invented by Sequent operating system engineers, who often
    have significant exposure and input in to the hardware design.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Fri May 30 01:08:10 2025
    Reply-To: slp53@pacbell.net

    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 11:11, James Kuyper wrote:
    On 5/29/25 05:37, Lawrence D'Oliveiro wrote:
    On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:
    ...
    Is C90 perfect? No, of course not.

    Is there some value in that particular state of imperfection? Like the
    Amish, whose concept of the ideal level of technology is the one that was >>> in effect at the time they were founded? And who have remained stuck at
    that point in time ever since?

    That's not actually the case. The Amish have slowly adopted more
    advanced levels of technology as the people around them have adopted
    farm more advanced ones. The important thing, from their point of view,
    it not a particular level of technology, but to maintain a clear
    distinction between them and the non-Amish.
    Which means that they are more adaptable than Richard is.

    They use a lot of C++, do they?

    They do love power tools.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Fri May 30 02:36:21 2025
    On 29/05/2025 16:08, Scott Lurndal wrote:
    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 11:11, James Kuyper wrote:
    On 5/29/25 05:37, Lawrence D'Oliveiro wrote:
    On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:
    ...
    Is C90 perfect? No, of course not.

    Is there some value in that particular state of imperfection? Like the >>>> Amish, whose concept of the ideal level of technology is the one that was >>>> in effect at the time they were founded? And who have remained stuck at >>>> that point in time ever since?

    That's not actually the case. The Amish have slowly adopted more
    advanced levels of technology as the people around them have adopted
    farm more advanced ones. The important thing, from their point of view,
    it not a particular level of technology, but to maintain a clear
    distinction between them and the non-Amish.
    Which means that they are more adaptable than Richard is.

    They use a lot of C++, do they?

    They do love power tools.

    :-)

    If you want to take down a tree in a hurry, a chainsaw is just
    the job, but more delicate work requires more delicate tools.

    More to the point, if you have a million lines of legacy code all
    written in C90, it's a bloody good idea to keep a C90 compiler
    around because maintenance.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From James Kuyper@3:633/280.2 to All on Fri May 30 02:55:09 2025
    On 5/29/25 08:38, Richard Heathfield wrote:
    ....
    You can have new tools without breaking the old ones. We didn't
    have to change BCPL to get B, or B to get C, or C to get D or C++.

    This really is a very simple point, but perhaps a simple analogy
    will help to clarify it. You don't throw out your 3/4" just
    because you've bought a 19mm. There is room for both in the
    toolbox, and why write 3/4" on your new spanner? It /isn't/ a
    3/4" spanner even though it's very like it, so why pretend otherwise?

    That's why C99 is called C99, to distinguish it from C90 (and similarly
    for later versions). None of those revisions is large enough to justify
    giving the revised language an entirely new name.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Fri May 30 03:18:37 2025
    On 2025-05-29, Richard Heathfield <rjh@cpax.org.uk> wrote:
    If you want to take down a tree in a hurry, a chainsaw is just
    the job, but more delicate work requires more delicate tools.

    (I'm now searching YouTube for anyone in Asia who might be
    carving jade amulets with a chainsaw ...)

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Fri May 30 03:48:31 2025
    On 29/05/2025 17:55, James Kuyper wrote:
    On 5/29/25 08:38, Richard Heathfield wrote:
    ...
    You can have new tools without breaking the old ones. We didn't
    have to change BCPL to get B, or B to get C, or C to get D or C++.

    This really is a very simple point, but perhaps a simple analogy
    will help to clarify it. You don't throw out your 3/4" just
    because you've bought a 19mm. There is room for both in the
    toolbox, and why write 3/4" on your new spanner? It /isn't/ a
    3/4" spanner even though it's very like it, so why pretend otherwise?

    That's why C99 is called C99, to distinguish it from C90 (and similarly
    for later versions).

    Yes, I realise that.

    Obviously, we disagree about whether it's enough of a distinction
    to do the job.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Fri May 30 03:51:53 2025
    On 29/05/2025 18:18, Kaz Kylheku wrote:
    On 2025-05-29, Richard Heathfield <rjh@cpax.org.uk> wrote:
    If you want to take down a tree in a hurry, a chainsaw is just
    the job, but more delicate work requires more delicate tools.

    (I'm now searching YouTube for anyone in Asia who might be
    carving jade amulets with a chainsaw ...)


    Seek and you will find.

    I haven't found jade yet, but I think this is a step in your
    direction:

    <https://www.youtube.com/watch?v=9zo8KgEePB4>

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From David Brown@3:633/280.2 to All on Fri May 30 05:24:57 2025
    On 29/05/2025 10:39, Richard Heathfield wrote:
    On 29/05/2025 08:27, Lawrence D'Oliveiro wrote:
    On Fri, 23 May 2025 23:13:20 +0100, Richard Heathfield wrote:

    And who cares about future instability if C90 remains just as stable as
    ever it was?

    Even with the problems with const?

    char *strstr(const char *haystack, const char *needle);

    Dennis Ritchie pointed out the trouble with that.

    Is C90 perfect? No, of course not. "C is quirky, flawed, and an enormous success."

    Is there value in having a powerful, widely-available language that,
    when you turn your back for a moment, stays *exactly* where you left it? Hell, yes.


    That's one of the reasons I like C99 and C11, and look forward to C23.
    Once implemented, they don't change either.

    I agree with all your are arguments on this, except for one - I can't understand why you think C90 is different from later C standards in this regard.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Michael S@3:633/280.2 to All on Fri May 30 06:24:46 2025
    On Thu, 29 May 2025 21:24:57 +0200
    David Brown <david.brown@hesbynett.no> wrote:

    On 29/05/2025 10:39, Richard Heathfield wrote:
    On 29/05/2025 08:27, Lawrence D'Oliveiro wrote: =20
    On Fri, 23 May 2025 23:13:20 +0100, Richard Heathfield wrote:
    =20
    And who cares about future instability if C90 remains just as
    stable as ever it was? =20

    Even with the problems with const?

    =A0=A0=A0=A0 char *strstr(const char *haystack, const char *needle);

    Dennis Ritchie pointed out the trouble with that. =20
    =20
    Is C90 perfect? No, of course not. "C is quirky, flawed, and an
    enormous success."
    =20
    Is there value in having a powerful, widely-available language
    that, when you turn your back for a moment, stays *exactly* where
    you left it? Hell, yes.
    =20
    =20
    That's one of the reasons I like C99 and C11, and look forward to
    C23. Once implemented, they don't change either.
    =20
    I agree with all your are arguments on this, except for one - I can't=20 understand why you think C90 is different from later C standards in
    this regard.
    =20

    The Great Slow Kings
    Roger Zelazny

    Drax and Dran sat in the great Throne Hall of Glan, discussing life. Monarchs by virtue of superior intellect and physique--and the fact
    that they were the last two survivors of the race of Glan--theirs was
    a divided rule over the planet and their one subject, Zindrome, the
    palace robot.

    Drax had been musing for the past four centuries (theirs was a sluggish
    sort) over the possibility of life on other planets in the galaxy.

    Accordingly, "Dran," said he, addressing the other (who was becoming
    mildly curious as to his thoughts), "Dran, I've been thinking. There
    may be life on other planets in the galaxy."

    Dran considered his response to this, as the world wheeled several
    times about its sun.

    "True," he finally agreed, "there may."

    After several months Drax shot back, "If there is, we ought to find
    out."

    "Why?" asked Dran with equal promptness, which caused the other to
    suspect that he, too, had been thinking along these lines.

    So he measured his next statement out cautiously, first testing each
    word within the plated retort of his reptilian skull.

    "Our kingdom is rather underpopulated at present," he observed. "It
    would be good to have many subjects once more."

    Dran regarded him askance, then slowly turned his head. He closed one
    eye and half-closed the other, taking full stock of his co-ruler, whose appearance, as he had suspected, was unchanged since the last time he
    had looked.

    "That, also, is true," he noted. "What do you suggest we do?"

    This time Drax turned, reappraising him, eye to eye.

    I think we ought to find out if there is life on other planets in the
    galaxy."

    "Hmm."

    Two quick rounds of the seasons went unnoticed, then, "Let me think
    about it," he said, and turned away.

    After what he deemed a polite period of time, Drax coughed.

    "Have you thought sufficiently?"

    "No."

    Drax struggled to focus his eyes on the near-subliminal streak of
    bluish light which traversed, re-traversed and re-re-traversed the Hall
    as he waited.

    "Zindrome!" he finally called out.

    The robot slowed his movements to a statue-like immobility to
    accommodate his master. A feather duster protruded from his right limb.

    "You called, great Lord of Glan?"

    "Yes, Zindrome, worthy subject. Those old spaceships which we
    constructed in happier days, and never got around to using. Are any of
    them still capable of operation?"

    "I'll check, great Lord."

    He seemed to change position slightly.

    "There are three hundred eighty-two," he announced, "of which four are
    in functioning condition, great Lord. I've checked all the operating
    circuits."

    "Drax," warned Dran, "you are arrogating unauthorized powers to
    yourself once more. You should have conferred with me before issuing
    that order."

    "I apologize," stated the other. "I simply wanted to expedite matters,
    should your decision be that we conduct a survey."

    "You have anticipated my decision correctly," nodded Dran, "but your
    eagerness seems to bespeak a hidden purpose."

    "No purpose but the good of the realm," smiled the other.

    "That may be, but the last time you spoke of 'the good of the realm'
    the civil strife which ensued cost us our other robot."

    "I have learned my lesson and profited thereby. I shall be more
    judicious in the future."

    "I hope so. Now, about this investigation--which part of the galaxy do
    you intend to investigate first?"

    A tension-filled pause ensued.

    "I had assumed," murmured Drax, "that you would conduct the expedition.
    Being the more mature monarch, yours should be a more adequate decision
    as to whether or not a particular species is worthy of our enlightened
    rule."

    "Yes, but your youth tends to make you more active than I. The journey
    should be more expeditiously conducted by you." He emphasized the word "expeditiously."

    "We could both go, in separate ships," offered Drax. "That would be
    truly expeditious--"

    Their heated debating was cut short by a metallic cough-equivalent.

    "Masters," suggested Zindrome, "the half-life of radioactive materials
    being as ephemeral as it is, I regret to report that only one spaceship
    is now in operational condition."

    "That settles it, Dran. _You_ go. It will require a steadier _rrand_ to
    manage an underpowered ship."

    "And leave you to foment civil strife and usurp unfranchised powers?
    No, you go!"

    "I suppose we could _both_ go," sighed Drax.

    "Fine! Leave the kingdom leaderless! _That_ is the kind of muddleheaded thinking which brought about our present political embarrassment."

    "Masters," said Zindrome, "if _someone_ doesn't go soon the ship will
    be useless."

    They both studied their servant, approving the rapid chain of logic
    forged by his simple statement.

    "Very well," they smiled in unison, "_you_ go."

    Zindrome bowed quite obsequiously and departed from the great Throne
    Hall of Glan.

    "Perhaps we should authorize Zindrome to construct facsimiles of
    himself," stated Dran, tentatively. "If we had more subjects we could accomplish more."

    "Are you forgetting our most recent agreement?" asked Drax. "A
    superfluity of robots tended to stimulate factionalism last time--and
    certain people grew ambitious..." He let his voice trail off over the
    years, for emphasis.

    "I am not certain as to whether your last allusion contains a hidden accusation," began the other carefully. "If so, permit me to caution
    you concerning rashness--and to remind you who it was who engineered
    the Mono-Robot Protection Pact."

    "Do you believe things will be different in the case of a multitude of
    organic subjects?" inquired the other.

    "Definitely," said Dran. "There is a certain irrational element in the rationale of the organic being, making it less amenable to direct
    orders than a machine would be. Our robots, at least, were faithful
    when we ordered them to destroy each other. Irresponsible organic
    subjects either do it without being told, which is boorish, or refuse
    to do it when you order them, which is insubordination."

    "True," smiled Drax, unearthing a gem he had preserved for millennia
    against this occasion. "Concerning organic life the only statement
    which can be made with certainty is that life is uncertain."

    "Hmm." Dran narrowed his eyes to slits. "Let me ponder that for a
    moment. Like much of your thinking it seems to smack of a concealed
    sophistry."

    "It contains none, I assure you. It is the fruit of much meditation."

    "Hmm."

    Dran's pondering was cut short, by the arrival of Zindrome who clutched
    two brownish blurs beneath his metal arms.

    "Back already, Zindrome? What have you there? Slow the down so we can
    see them."

    "They are under sedation at present, great Masters. It is the movements
    caused by their breathing which produce the unpleasant vibration
    pattern on your retinas. To subject them to more narcosis could prove deleterious."

    "Nevertheless," maintained Dran, "we must appraise our new subjects
    carefully, which requires that we see them. Slow them down some more."

    "You gave that order without-" began Drax, but was distracted by the
    sudden appearance of the two hairy bipeds.

    "Warm-blooded?" he asked.

    "Yes, Lord."

    "That bespeaks a very brief life-span."

    "True," offered Dran, "but that kind tends to reproduce quite rapidly."

    "That observation tends to be correct," nodded Drax. "Tell me,
    Zindrome, do they represent the sexes necessary for reproduction?"

    "Yes, Master. There are two sexes among these anthropoids, so I brought
    one of each."

    "That was very wise. Where did you find them?"

    "Several billion light years from here."

    "Turn those two loose outside and go fetch us some more."

    The creatures vanished. Zindrome appeared not to have moved.

    "Have you the fuel necessary for another such journey?"

    "Yes, my Lord. More of it has evolved recently."

    "Excellent."

    The robot departed.

    "What sort of governmental setup should be inaugurate this time?" asked
    Drax.

    "Set us review the arguments for the various types."

    "A good idea."

    In the midst of their discussion Zindrome returned and stood waiting to
    be recognized.

    "What is it, Zindrome? Did you forget something?"

    "No, great Lords. When I returned to the world from which I obtained
    the samples I discovered that the race had progressed to the point
    where it developed fission processes, engaged in an atomic war and
    annihilated itself."

    "That was extremely inconsiderate--typical, however, I should say, of warm-blooded instability."

    Zindrome continued to shift.

    "Have you something else to report?"

    "Yes, great Masters. The two specimens I released have multiplied and
    are now spread over the entire planet of Glan."

    "We should have been advised!"

    "Yes, great Lords, but I was absent and--"

    "They themselves should have reported this action!"

    "Masters, I am afraid they are unaware of your existence."

    "How could that have happened?" asked Dran.

    "We are presently buried beneath several thousand layers of alluvial
    rock. The geological shifts--"

    "You have your orders to maintain the place and clean the grounds,"
    glowered Dran. "Have you been frittering away your time again?"

    "No, great Lords! It all occurred during my absence. I shall attend to
    it immediately."

    "First," ordered Drax, "tell us what else our subjects have been up to,
    that they saw fit to conceal from us."

    "Recently," observed the robot, "they have discovered how to forge and
    temper metals. Upon landing, I observed that they had developed many
    ingenious instruments of a cutting variety. Unfortunately they were
    using them to cut one another."

    "Do you mean," roared Dran, "that there is strife in the kingdom?"

    "Uh, yes, my Lord."

    "I will not brook unauthorized violence among my subjects!"

    "_Our_ subjects," added Drax, with a meaningful glare.

    "_Our_ subjects," amended Dran. "We must take immediate action."

    "Agreed."

    "Agreed."

    "I shall issue orders forbidding their engagement in activities leading
    to bloodshed."

    "I presume that you mean a joint proclamation," stated Drax.

    "Of course. I was not slighting you, I was simply shaken by the civil emergency. We shall draft an official proclamation. Let Zindrome fetch
    us writing instruments."

    "Zindrome, fetch--"

    "I have them here, my Lords."

    "Now, let me see. How shall we phrase it...?"

    "Perhaps I should clean the palace while your Excellencies--"

    "No! Wait right here! This will be very brief and to the point."

    "Mm. 'We hereby proclaim...'"

    "Don't forget our titles."

    "True. 'We, the imperial monarchs of Glan, herebeneath undersigned, do hereby...'"

    A feeble pulse of gamma rays passed unnoticed by the two rulers. The
    faithful Zindrome diagnosed its nature, however, and tried
    unsuccessfully to obtain the monarchs' attention. Finally, he dismissed
    the project with a stoical gesture typical of his kind. He waited.


    There!" they agreed flourishing the document. "Now you can tell us what
    you have been trying to say, Zindrome. But make it brief, you just
    deliver this soon."

    "It is already too late, great Lords. This race, also, progressed into civilized states, developed nuclear energy and eradicated itself while
    you were writing."

    "Barbarous!"

    "Warm-blooded irresponsibility!"

    "May I go clean up now, great Masters?"

    "Soon, Zindrome, soon. First, though, I move that we file the
    proclamation in the Archives for future use, in the event of similar occurrences."

    Dran nodded.

    "I agree. _We_ so order."

    The robot accepted the crumbling proclamation and vanished from sight.

    "You know," Drax mused, "there must be lots of radioactive material
    lying about now..."

    "There probably is."

    "It could be used to fuel a ship for another expedition."

    "Perhaps."

    "This time we could instruct Zindrome to bring back something with a
    longer lifespan and more deliberate habits--somewhat nearer our own."

    "That would have its dangers. But perhaps we could junk the Mono-Robot Protection Pact and order Zindrome to manufacture extras of himself.
    Under strict supervision."

    "That would have its dangers too."

    "At any rate, I should have to ponder your suggestion carefully."

    "And I yours."

    "It's been a busy day," nodded Dran. "Let's sleep on it."

    "A good idea."

    Sounds of saurian snoring emerged from the great Throne Hall of Glan.




    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Fri May 30 06:27:41 2025
    On 29/05/2025 20:24, David Brown wrote:
    On 29/05/2025 10:39, Richard Heathfield wrote:
    On 29/05/2025 08:27, Lawrence D'Oliveiro wrote:
    On Fri, 23 May 2025 23:13:20 +0100, Richard Heathfield wrote:

    And who cares about future instability if C90 remains just as
    stable as
    ever it was?

    Even with the problems with const?

    char *strstr(const char *haystack, const char *needle);

    Dennis Ritchie pointed out the trouble with that.

    Is C90 perfect? No, of course not. "C is quirky, flawed, and an
    enormous success."

    Is there value in having a powerful, widely-available language
    that, when you turn your back for a moment, stays *exactly*
    where you left it? Hell, yes.


    That's one of the reasons I like C99 and C11, and look forward to
    C23. Once implemented, they don't change either.

    I agree with all your are arguments on this,

    So far so good. :-)

    except for one - I
    can't understand why you think C90 is different from later C
    standards in this regard.


    I realise that my reply is going to sound glib, but I can't help
    that.

    I *don't* think C90 is different. I think C90 is exactly the
    same. It's the later standards that are different. Different from
    C90.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From Keith Thompson@3:633/280.2 to All on Fri May 30 06:45:16 2025
    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 20:24, David Brown wrote:
    [...]
    That's one of the reasons I like C99 and C11, and look forward to
    C23. Once implemented, they don't change either.
    I agree with all your are arguments on this,

    So far so good. :-)

    except for one - I can't understand why you think C90 is different
    from later C standards in this regard.

    I realise that my reply is going to sound glib, but I can't help that.

    I *don't* think C90 is different. I think C90 is exactly the
    same. It's the later standards that are different. Different from C90.

    I'd like to understand the point you're trying to make.

    Being different is a transitive relationship. C90 is different
    "from later C standards". You say that C90 is "exactly the same"
    -- as what? As itself? C99 is also exactly the same as itself.

    If the difference is that you personally like C90 and dislike C99
    and later editions, that's fine. De gustibus non est disputandem
    (never argue with a guy named Gus).

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    void Void(void) { Void(); } /* The recursive call of the void */

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: None to speak of (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Fri May 30 07:09:54 2025
    On 29/05/2025 21:45, Keith Thompson wrote:
    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 20:24, David Brown wrote:
    [...]
    That's one of the reasons I like C99 and C11, and look forward to
    C23. Once implemented, they don't change either.
    I agree with all your are arguments on this,

    So far so good. :-)

    except for one - I can't understand why you think C90 is different
    from later C standards in this regard.

    I realise that my reply is going to sound glib, but I can't help that.

    I *don't* think C90 is different. I think C90 is exactly the
    same. It's the later standards that are different. Different from C90.

    I'd like to understand the point you're trying to make.

    I'll do what I can to help out; I'm really not trying to be obscure.

    Being different is a transitive relationship. C90 is different
    "from later C standards". You say that C90 is "exactly the same"
    -- as what? As itself?

    Yes. And nothing else has that quality of being C90.

    C99 is also exactly the same as itself.

    Yes, but it's different from C99.

    If the difference is that you personally like C90 and dislike C99
    and later editions, that's fine. De gustibus non est disputandem
    (never argue with a guy named Gus).

    Look, Gus, if that's what you want to call yourself...well, okay,
    I can't in all honesty deny that de gustibus is part of it, but
    it's more to do with bit rot.

    Software houses need C90 for the same reason the government needs
    IBM 1311s (unless they've finished migrating off them now),
    cassette players, WW2 crypto keys, and the boot passwords for
    those early 1990s PCs lurking in the cellar.

    I shudder to think how much C90 code is out there, but it has to
    be /at least/ in the region of 10^9 LOC, much of it in the
    military arena, medical applications, and particularly the world
    of comms. Letting C90 compilers fall off the radar (e.g. by
    society forgetting how to program in it) really could be a
    stupendously bad idea, for all the reasons that people overlook
    when they shrug and say `I expect it'll all turn out fine'.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Fri May 30 07:19:44 2025
    Reply-To: slp53@pacbell.net

    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 21:45, Keith Thompson wrote:
    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 20:24, David Brown wrote:
    [...]
    That's one of the reasons I like C99 and C11, and look forward to
    C23. Once implemented, they don't change either.
    I agree with all your are arguments on this,

    So far so good. :-)

    except for one - I can't understand why you think C90 is different
    from later C standards in this regard.

    I realise that my reply is going to sound glib, but I can't help that.

    I *don't* think C90 is different. I think C90 is exactly the
    same. It's the later standards that are different. Different from C90.

    I'd like to understand the point you're trying to make.

    I'll do what I can to help out; I'm really not trying to be obscure.

    Being different is a transitive relationship. C90 is different
    "from later C standards". You say that C90 is "exactly the same"
    -- as what? As itself?

    Yes. And nothing else has that quality of being C90.

    C99 is also exactly the same as itself.

    Yes, but it's different from C99.

    If the difference is that you personally like C90 and dislike C99
    and later editions, that's fine. De gustibus non est disputandem
    (never argue with a guy named Gus).

    Look, Gus, if that's what you want to call yourself...well, okay,
    I can't in all honesty deny that de gustibus is part of it, but
    it's more to do with bit rot.

    Software houses need C90 for the same reason the government needs
    IBM 1311s (unless they've finished migrating off them now),
    cassette players, WW2 crypto keys, and the boot passwords for
    those early 1990s PCs lurking in the cellar.

    I shudder to think how much C90 code is out there, but it has to
    be /at least/ in the region of 10^9 LOC, much of it in the
    military arena, medical applications, and particularly the world
    of comms. Letting C90 compilers fall off the radar (e.g. by
    society forgetting how to program in it) really could be a
    stupendously bad idea, for all the reasons that people overlook
    when they shrug and say `I expect it'll all turn out fine'.

    And all the existing C compilers in the entire planet support
    the C90 dialect[*], if so instructed. Where is the problem?

    [*] Well, except perhap Bart's and various hobby compilers.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Chris M. Thomasson@3:633/280.2 to All on Fri May 30 07:29:23 2025
    On 5/29/2025 5:41 AM, Richard Heathfield wrote:
    On 29/05/2025 11:11, James Kuyper wrote:
    On 5/29/25 05:37, Lawrence D'Oliveiro wrote:
    On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:
    ...
    Is C90 perfect? No, of course not.

    Is there some value in that particular state of imperfection? Like the
    Amish, whose concept of the ideal level of technology is the one that
    was
    in effect at the time they were founded? And who have remained stuck at
    that point in time ever since?

    That's not actually the case. The Amish have slowly adopted more
    advanced levels of technology as the people around them have adopted
    farm more advanced ones. The important thing, from their point of view,
    it not a particular level of technology, but to maintain a clear
    distinction between them and the non-Amish.
    Which means that they are more adaptable than Richard is.

    They use a lot of C++, do they?


    ROFL!!!

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Chris M. Thomasson@3:633/280.2 to All on Fri May 30 07:31:06 2025
    On 5/29/2025 9:36 AM, Richard Heathfield wrote:
    On 29/05/2025 16:08, Scott Lurndal wrote:
    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 11:11, James Kuyper wrote:
    On 5/29/25 05:37, Lawrence D'Oliveiro wrote:
    On Thu, 29 May 2025 09:39:51 +0100, Richard Heathfield wrote:
    ...
    Is C90 perfect? No, of course not.

    Is there some value in that particular state of imperfection? Like the >>>>> Amish, whose concept of the ideal level of technology is the one
    that was
    in effect at the time they were founded? And who have remained
    stuck at
    that point in time ever since?

    That's not actually the case. The Amish have slowly adopted more
    advanced levels of technology as the people around them have adopted
    farm more advanced ones. The important thing, from their point of view, >>>> it not a particular level of technology, but to maintain a clear
    distinction between them and the non-Amish.
    Which means that they are more adaptable than Richard is.

    They use a lot of C++, do they?

    They do love power tools.

    :-)

    If you want to take down a tree in a hurry, a chainsaw is just the job,
    but more delicate work requires more delicate tools.

    More to the point, if you have a million lines of legacy code all
    written in C90, it's a bloody good idea to keep a C90 compiler around because maintenance.


    The Amish, from Family Guy:

    https://youtu.be/-wlwtpH1ldM

    LOL! They are quite efficient!

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Fri May 30 07:40:09 2025
    On 29/05/2025 22:19, Scott Lurndal wrote:
    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 21:45, Keith Thompson wrote:

    <snip>

    C99 is also exactly the same as itself.

    Yes, but it's different from C99.

    No it isn't! It's different from C90. (Mea culpa; poor
    proofreading on my part.)

    <snip>

    I shudder to think how much C90 code is out there, but it has to
    be /at least/ in the region of 10^9 LOC, much of it in the
    military arena, medical applications, and particularly the world
    of comms. Letting C90 compilers fall off the radar (e.g. by
    society forgetting how to program in it) really could be a
    stupendously bad idea, for all the reasons that people overlook
    when they shrug and say `I expect it'll all turn out fine'.

    And all the existing C compilers in the entire planet support
    the C90 dialect[*], if so instructed.

    Indeed. It's hard to imagine a platform without a C90 compiler.
    That's an extraordinarily powerful quality that we would do well
    not to lose.

    Where is the problem?

    Where? I don't know. /When/ is the problem? When we forget that
    it matters.

    [*] Well, except perhap Bart's and various hobby compilers.

    Er, quite.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From Keith Thompson@3:633/280.2 to All on Fri May 30 07:50:13 2025
    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 21:45, Keith Thompson wrote:
    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 20:24, David Brown wrote:
    [...]
    That's one of the reasons I like C99 and C11, and look forward to
    C23. Once implemented, they don't change either.
    I agree with all your are arguments on this,

    So far so good. :-)

    except for one - I can't understand why you think C90 is different
    from later C standards in this regard.

    I realise that my reply is going to sound glib, but I can't help that.

    I *don't* think C90 is different. I think C90 is exactly the
    same. It's the later standards that are different. Different from C90.
    I'd like to understand the point you're trying to make.

    I'll do what I can to help out; I'm really not trying to be obscure.

    Being different is a transitive relationship. C90 is different
    "from later C standards". You say that C90 is "exactly the same"
    -- as what? As itself?

    Yes. And nothing else has that quality of being C90.

    C99 is also exactly the same as itself.

    Yes, but it's different from C99.

    I hope that was a typo. If you really meant that C99 is different from
    C99, I suggest that requires a bit more explanation.

    If the difference is that you personally like C90 and dislike C99
    and later editions, that's fine. De gustibus non est disputandem
    (never argue with a guy named Gus).

    Look, Gus, if that's what you want to call yourself...well, okay, I
    can't in all honesty deny that de gustibus is part of it, but it's
    more to do with bit rot.

    Software houses need C90 for the same reason the government needs IBM
    1311s (unless they've finished migrating off them now), cassette
    players, WW2 crypto keys, and the boot passwords for those early 1990s
    PCs lurking in the cellar.

    I shudder to think how much C90 code is out there, but it has to be
    /at least/ in the region of 10^9 LOC, much of it in the military
    arena, medical applications, and particularly the world of
    comms. Letting C90 compilers fall off the radar (e.g. by society
    forgetting how to program in it) really could be a stupendously bad
    idea, for all the reasons that people overlook when they shrug and say
    `I expect it'll all turn out fine'.

    Right, there's a lot of existing C90 code out there, and we need
    both C90 compilers and programmers who are familiar with C90
    to maintain it. The alternative of updating it to conform to a
    later C standard is often impractical (and the update would also
    require programmers who know C90). I don't recall anyone suggesting
    otherwise. ISO has decreed that each edition "cancels and replaces"
    the previous edition, but none of us are obligated to accept that.

    If I were starting a new project in C, I would not consider
    using C90. At this point, I'd probably use C11 (perhaps with
    compiler-specific extensions depending on the details of the
    project).

    Obviously C90, C99, and C11 are all different from each other.
    You seem to be suggesting that C90 is special in some way that C99
    and C11 are not. If that's an accurate summary of your opinion,
    can you explain it? And if it isn't, just what are we talking about?

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    void Void(void) { Void(); } /* The recursive call of the void */

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: None to speak of (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Fri May 30 09:05:22 2025
    On 29/05/2025 22:50, Keith Thompson wrote:
    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 21:45, Keith Thompson wrote:
    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 20:24, David Brown wrote:
    [...]
    That's one of the reasons I like C99 and C11, and look forward to
    C23. Once implemented, they don't change either.
    I agree with all your are arguments on this,

    So far so good. :-)

    except for one - I can't understand why you think C90 is different
    from later C standards in this regard.

    I realise that my reply is going to sound glib, but I can't help that. >>>>
    I *don't* think C90 is different. I think C90 is exactly the
    same. It's the later standards that are different. Different from C90.
    I'd like to understand the point you're trying to make.

    I'll do what I can to help out; I'm really not trying to be obscure.

    Being different is a transitive relationship. C90 is different
    "from later C standards". You say that C90 is "exactly the same"
    -- as what? As itself?

    Yes. And nothing else has that quality of being C90.

    C99 is also exactly the same as itself.

    Yes, but it's different from C99.

    I hope that was a typo. If you really meant that C99 is different from
    C99, I suggest that requires a bit more explanation.

    Typo, of course. (9 is next to 0.) Alas, my typo-free days are over.

    <snip>

    Obviously C90, C99, and C11 are all different from each other.
    You seem to be suggesting that C90 is special in some way that C99
    and C11 are not.

    Yes. Nothing magical, of course. But C90 was there first and is
    (fairly literally) universal as no other dialect is. It would be
    a mistake to lose that.


    If that's an accurate summary of your opinion,
    can you explain it?

    Not sure I can be any clearer than I already have been, which
    seems to have been about as clear as mud. Ah well.

    And if it isn't, just what are we talking about?

    Maybe I'm just being grumpy out loud instead of muttering dark
    imprecations into my coffee mug.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From Waldek Hebisch@3:633/280.2 to All on Fri May 30 12:46:48 2025
    Richard Heathfield <rjh@cpax.org.uk> wrote:

    Software houses need C90 for the same reason the government needs
    IBM 1311s (unless they've finished migrating off them now),
    cassette players, WW2 crypto keys, and the boot passwords for
    those early 1990s PCs lurking in the cellar.

    I shudder to think how much C90 code is out there, but it has to
    be /at least/ in the region of 10^9 LOC, much of it in the
    military arena, medical applications, and particularly the world
    of comms. Letting C90 compilers fall off the radar (e.g. by
    society forgetting how to program in it) really could be a
    stupendously bad idea, for all the reasons that people overlook
    when they shrug and say `I expect it'll all turn out fine'.

    Clearly there is a lot of old code there. I am not sure why
    you think that C90 is very special here. I mean, goverment
    loves standards and for goverment project may mandate use
    of "standard" language, which could mean C90 in relevant
    period. However, business had tendency to use whatever their
    compilers supported, which frequently meant using vendor
    extentions. Due to extentions, I suspect that there is very
    little pure C90 code. Even if C90 was mandated it is not
    clear if C90 was really deliverd. More precisely, when you
    look at small snippets of C code there is good chance that
    they will be valid regardless of version of C that you use.
    However in large codebase one can expect some constructs that
    are not valid C90. Even for code born as pure C90, there is
    notrivial chance that maintanence introduced constructs
    from later C standards.

    AFAICS C99 and C11 did not introduced major incompatibilities
    with C90. OTOH some vendor extentions to C90 were
    standarized in C99 and C11. So, it is reasonable to suspect
    that amount of say C99 code is significantly larger
    than C90 code. Or may be better to say that deviation of
    C code from C99 is probably smaller than deviation from C90.

    Concerning new code it makes sense to avoid constructs that
    are made illegal in later standard, that is write to the
    latter of later standard even if you use only constructs
    available in C90. And concerning constructs not in C90,
    I find ability to mix declarations and statements important
    to readability. So any code that I write now is unlikely
    to be valid C90 for this (technically trivial) reason.
    For computational code multidimensional arrays are
    useful. In general purpose code sizes of arrays are
    typically only known at runtime, so it is natural to
    use variable modified types. Other people may find useful
    some other features of C99 or later standards, so there
    is incentive to go beyond C90.

    There is also historic aspect. C90 is part of history and
    I fully support preserving it (specification and actual
    programs) as historic artifacts. But I also think that
    C90 should be retired from practical use, that is code
    should be modernized to comply with later standards.
    If code needs to be very portable, than C90 compatibility
    makes sense, but for most code it it better to take
    advantage of newer features.

    BTW: In the past I used to point out to students that some
    features that they use in their programs are not C90 but
    say C99. But now I do not think that it is worth to
    bother students with information about C90.

    --
    Waldek Hebisch

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: To protect and to server (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Fri May 30 13:10:04 2025
    On Thu, 29 May 2025 13:38:37 +0100, Richard Heathfield wrote:

    This really is a very simple point, but perhaps a simple analogy
    will help to clarify it. You don't throw out your 3/4" just
    because you've bought a 19mm. There is room for both in the
    toolbox, and why write 3/4" on your new spanner? It /isn't/ a
    3/4" spanner even though it's very like it, so why pretend otherwise?

    Let me clarify your analogy with another analogy: a language compiler is
    just like a spanner. Anything you can say about one, applies equally to another. The difference is, old language compilers can get worn, but
    spanners stay bright and new forever.

    Also, 19mm spanners are upward-compatible with ¾” ones, aren’t they? Any nuts you can handle with the old one, you can deal with using the new one, can’t you?

    Because argument by analogy works like that.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Fri May 30 13:42:44 2025
    On 2025-05-30, Waldek Hebisch <antispam@fricas.org> wrote:
    Concerning new code it makes sense to avoid constructs that
    are made illegal in later standard, that is write to the
    latter of later standard even if you use only constructs
    available in C90.

    Speaking of which, I like to avoid declarations mixed
    with statements. GCC supports that with a diagnostic: -Werror=declaration-after-statement.

    However, the wording of the diagnostic, when it goes off,
    is poor: it says something like "C90 doesn't allow
    mixed declarations and statements".

    Aaaargh! I said, error out for declarations after
    statements. I didn't say I'm writing in C90.
    Look, in the same function, I initialized an automatic
    aggregate with a non-constant, which is also not in C90!

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Fri May 30 17:34:21 2025
    On Thu, 29 May 2025 22:09:54 +0100, Richard Heathfield wrote:

    I shudder to think how much C90 code is out there, but it has to be /at least/ in the region of 10^9 LOC, much of it in the military arena,
    medical applications, and particularly the world of comms.

    The military and aerospace were/are using Ada a lot. That’s why the 🇺🇸 DoD
    sponsored its creation, after all. And guess what: that is a language that
    is still alive and well and being maintained today. Because that is a
    language that was designed to be more robust against stupid errors than C could ever be.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Fri May 30 18:18:43 2025
    "Scott Lurndal" <scott@slp53.sl.home> wrote in message news:Qb4_P.377135$vvyf.313049@fx18.iad...
    Richard Heathfield <rjh@cpax.org.uk> writes:

    I shudder to think how much C90 code is out there, but it has to
    be /at least/ in the region of 10^9 LOC, much of it in the
    military arena, medical applications, and particularly the world
    of comms. Letting C90 compilers fall off the radar (e.g. by
    society forgetting how to program in it) really could be a
    stupendously bad idea, for all the reasons that people overlook
    when they shrug and say `I expect it'll all turn out fine'.

    And all the existing C compilers in the entire planet support
    the C90 dialect[*], if so instructed. Where is the problem?

    [*] Well, except perhap Bart's and various hobby compilers.


    And also except the most important, or second most
    important, compiler on the planet.

    (The competition for first place being IBM's C compiler for z/OS)


    C:\Program Files\Microsoft Visual Studio\2022\Professional>cl /?
    Microsoft (R) C/C++ Optimizing Compiler Version 19.41.34123 for x64
    Copyright (C) Microsoft Corporation. All rights reserved.

    ....

    -LANGUAGE-

    /std:<c++14|c++17|c++20|c++latest> C++ standard version
    c++14 - ISO/IEC 14882:2014 (default)
    c++17 - ISO/IEC 14882:2017
    c++20 - ISO/IEC 14882:2020
    c++latest - latest draft standard (feature set subject to change) /std:<c11|c17|clatest> C standard version
    c11 - ISO/IEC 9899:2011
    c17 - ISO/IEC 9899:2018
    clatest - latest draft standard (feature set subject to change)




    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Fri May 30 18:41:21 2025
    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:10191uh$3olom$2@dont-email.me...
    On Wed, 21 May 2025 19:23:45 +1000, Paul Edwards wrote:

    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100j8t8$2g75r$5@dont-email.me...

    On Wed, 21 May 2025 07:41:12 +1000, Paul Edwards wrote:

    Basically the software industry is a joke. The advances have all been
    done by hardware engineers.

    Didn't they use software to manage that?

    Yes - as the guy (Jeff) said - software written by lunatics/artists.

    Was RCU invented by the hardware guys, or the software guys?

    What about journalling? Two-phase commit? Diffie-Hellman? RSA? Kerberos? kexec?

    I'm not disputing advances in computer science. Three way diff
    would be my favorite.

    It then needs to be incorporated into a professional product.
    Which is properly funded, understood, someone has pride
    in the integrity of the product, and bugs reports are always
    addressed with professionalism - no matter what is required.
    Literally to the ends of the earth. If they ever needed more
    money to fix a bug, they'd just jack up the prices they charge.

    In other words, MVS (z/OS).

    I doubt that the original author (Jeff) was working on z/OS when
    he wrote about the shambles he saw.

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Fri May 30 18:47:08 2025
    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:1019269$3olom$3@dont-email.me...
    On Mon, 26 May 2025 11:50:30 +1000, Paul Edwards wrote:

    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:1010bqn$1l25r$1@dont-email.me...

    On Mon, 26 May 2025 09:48:46 +1000, Paul Edwards wrote:

    "people nowadays" don't speak with one voice.

    Nor with one language. Which is why we have Unicode.

    Which is one solution to the problem.

    Just not a solution I agree with.

    It's the one most of the nations of the world agree with.

    They may not agree if they are suddenly exposed to resource constraints.

    I prefer VISCII-like, possibly requiring a 9-bit char, and invalidating
    all applications with POSIX assumptions.

    Are you going to set up your own UN as well? You could call it the "World Series of Nations" ...

    Sort of. I'm going to have the only understandable, maintainable
    and maintained open source OS.

    When the appropriate resource constraints kick in - including
    the emerging lack of skilled programmers in Idiocracy, it will
    be a race to the bottom, where PDOS serves as a backstop.
    As designed.

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From David Brown@3:633/280.2 to All on Fri May 30 19:20:44 2025
    On 29/05/2025 14:38, Richard Heathfield wrote:

    This really is a very simple point, but perhaps a simple analogy will
    help to clarify it. You don't throw out your 3/4" just because you've
    bought a 19mm. There is room for both in the toolbox, and why write 3/4"
    on your new spanner? It /isn't/ a 3/4" spanner even though it's very
    like it, so why pretend otherwise?


    Your analogy does not cover C99 vs C90.

    You have a good 3/4" spanner. You don't throw it out just because you
    also get an adjustable spanner - sometimes the 3/4" spanner is more
    practical, or perhaps a bit stronger. That's keeping C when you also
    have C++ available.

    You have a good 3/4" spanner. Now you get a new 3/4" spanner that is
    made of stronger steel, has a more comfortable grip, and has a box/ring
    at the other end which the old spanner did not. You probably won't
    throw out the old spanner, but most of the time you will now use the new spanner. That's C99 vs C90.

    Sometimes, of course, we have non-rational reasons for a preference.
    Maybe you just like using the old spanner because you've had it since
    you were a kid and there's an emotional attachment. Or maybe you don't
    like the shade of grey of the new spanner. That, of course, is fine -
    when something is good enough for the job, you don't need something
    better and can make the choice for any other personal reason. It is
    just very difficult for other people to understand such choices.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Fri May 30 20:54:32 2025
    On 30/05/2025 10:20, David Brown wrote:
    On 29/05/2025 14:38, Richard Heathfield wrote:

    This really is a very simple point, but perhaps a simple
    analogy will help to clarify it. You don't throw out your 3/4"
    just because you've bought a 19mm. There is room for both in
    the toolbox, and why write 3/4" on your new spanner? It /isn't/
    a 3/4" spanner even though it's very like it, so why pretend
    otherwise?


    Your analogy does not cover C99 vs C90.

    It does if we can construct a program that is legal C90 but not
    legal C99, which is easy enough, or (slightly harder but still
    not that hard) a program that is legal in both dialects but which
    gives different output under C99 than it does for C90.

    $ cat c9099.c;gcc -W -Wall -ansi -pedantic -o c90 c9099.c;gcc -o
    c99 c9099.c;./c90;./c99
    #include <stdio.h>

    int main(void)
    {
    int a = 42;

    int b = a //* comment */ 6;
    ;
    printf("Soln = %d\n", b);

    return 0;
    }
    Soln = 7
    Soln = 42

    Obviously it's a contrived example, but then examples pointing
    out the consequences of language differences invariably are.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From David Brown@3:633/280.2 to All on Sat May 31 00:02:18 2025
    On 30/05/2025 12:54, Richard Heathfield wrote:
    On 30/05/2025 10:20, David Brown wrote:
    On 29/05/2025 14:38, Richard Heathfield wrote:

    This really is a very simple point, but perhaps a simple analogy will
    help to clarify it. You don't throw out your 3/4" just because you've
    bought a 19mm. There is room for both in the toolbox, and why write
    3/4" on your new spanner? It /isn't/ a 3/4" spanner even though it's
    very like it, so why pretend otherwise?


    Your analogy does not cover C99 vs C90.

    It does if we can construct a program that is legal C90 but not legal
    C99, which is easy enough, or (slightly harder but still not that hard)
    a program that is legal in both dialects but which gives different
    output under C99 than it does for C90.

    $ cat c9099.c;gcc -W -Wall -ansi -pedantic -o c90 c9099.c;gcc -o c99 c9099.c;./c90;./c99
    #include <stdio.h>

    int main(void)
    {
    int a = 42;

    int b = a //* comment */ 6;
    ;
    printf("Soln = %d\n", b);

    return 0;
    }
    Soln = 7
    Soln = 42

    Obviously it's a contrived example, but then examples pointing out the consequences of language differences invariably are.


    The analogy there is like complaining you can't use the back end of your
    new spanner to hammer in nails, because it now has a box/ring at the end.


    About the only non-pathological circumstances where a C90 program could
    not be compiled as C99 and give the same result is if you happened to
    use the word "restrict" as an identifier.

    (And yes, I know there was a minor change in the types of certain
    integer constants, and that it is conceivable that a particularly
    unusual C90 compiler gave different unspecified rounding for negative
    division than on a C99 compiler.)


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Sat May 31 01:26:04 2025
    On 30/05/2025 15:02, David Brown wrote:
    On 30/05/2025 12:54, Richard Heathfield wrote:

    <snip>

    Obviously it's a contrived example, but then examples pointing
    out the consequences of language differences invariably are.


    The analogy there is like complaining you can't use the back end
    of your new spanner to hammer in nails, because it now has a
    box/ring at the end.

    Your argument now appears to be that people wouldn't need C90 if
    only they'd written their C90 in such a way that C99 would have
    met their needs.

    This is undoubtedly the case.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From David Brown@3:633/280.2 to All on Sat May 31 01:37:20 2025
    On 30/05/2025 01:05, Richard Heathfield wrote:
    On 29/05/2025 22:50, Keith Thompson wrote:
    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 21:45, Keith Thompson wrote:

    C99 is also exactly the same as itself.

    Yes, but it's different from C99.

    I hope that was a typo. If you really meant that C99 is different from
    C99, I suggest that requires a bit more explanation.

    Typo, of course. (9 is next to 0.) Alas, my typo-free days are over.


    You are, I believe, older than me. At what age can I expect my
    typo-free days to start?

    :-)



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From David Brown@3:633/280.2 to All on Sat May 31 01:42:32 2025
    On 30/05/2025 17:26, Richard Heathfield wrote:
    On 30/05/2025 15:02, David Brown wrote:
    On 30/05/2025 12:54, Richard Heathfield wrote:

    <snip>

    Obviously it's a contrived example, but then examples pointing out
    the consequences of language differences invariably are.


    The analogy there is like complaining you can't use the back end of
    your new spanner to hammer in nails, because it now has a box/ring at
    the end.

    Your argument now appears to be that people wouldn't need C90 if only
    they'd written their C90 in such a way that C99 would have met their needs.


    I can't see how you get that from what I wrote.

    However, it /is/ the case that most people write / wrote their C90 in
    such a way that C99 meets their needs. The good folks who gave us C99 specifically made backwards compatibility a priority (though not an
    absolute).

    I'm not sure we are getting anywhere with this thread...

    This is undoubtedly the case.




    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Richard Harnden@3:633/280.2 to All on Sat May 31 02:25:12 2025
    Reply-To: nospam.harnden@invalid.com

    On 30/05/2025 16:37, David Brown wrote:
    On 30/05/2025 01:05, Richard Heathfield wrote:

    Typo, of course. (9 is next to 0.) Alas, my typo-free days are over.


    You are, I believe, older than me. At what age can I expect my typo-
    free days to start?

    Typo free days to /end/



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Sat May 31 02:32:39 2025
    On 30/05/2025 16:37, David Brown wrote:
    On 30/05/2025 01:05, Richard Heathfield wrote:
    On 29/05/2025 22:50, Keith Thompson wrote:
    Richard Heathfield <rjh@cpax.org.uk> writes:
    On 29/05/2025 21:45, Keith Thompson wrote:

    C99 is also exactly the same as itself.

    Yes, but it's different from C99.

    I hope that was a typo. If you really meant that C99 is
    different from
    C99, I suggest that requires a bit more explanation.

    Typo, of course. (9 is next to 0.) Alas, my typo-free days are
    over.


    You are, I believe, older than me. At what age can I expect my
    typo-free days to start?

    :-)

    I came up with a few answers to that, but you'll be glad to hear
    that I decided you didn't deserve any of them. ;-)

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Sat May 31 02:39:00 2025
    On 30/05/2025 16:42, David Brown wrote:
    <snip>
    I can't see how you get that from what I wrote.

    Perhaps I've been spending too long in comp.theory

    I'm not sure we are getting anywhere with this thread...

    Agreed. I can no longer remember how this sub-thread started, but
    I would guess that it was a wry aside that got bicycle-pumped out
    of proportion.

    void main(void)
    {
    char *s="Let's call the whole thing";
    printf("%s %s", s, gets(s));
    }

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Sat May 31 02:39:41 2025
    On 30/05/2025 17:25, Richard Harnden wrote:
    On 30/05/2025 16:37, David Brown wrote:
    On 30/05/2025 01:05, Richard Heathfield wrote:

    Typo, of course. (9 is next to 0.) Alas, my typo-free days are
    over.


    You are, I believe, older than me. At what age can I expect my
    typo- free days to start?

    Typo free days to /end/

    No, I think he was right the first time.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Sat May 31 04:04:42 2025
    On 2025-05-30, David Brown <david.brown@hesbynett.no> wrote:
    On 29/05/2025 14:38, Richard Heathfield wrote:

    This really is a very simple point, but perhaps a simple analogy will
    help to clarify it. You don't throw out your 3/4" just because you've
    bought a 19mm. There is room for both in the toolbox, and why write 3/4"
    on your new spanner? It /isn't/ a 3/4" spanner even though it's very
    like it, so why pretend otherwise?


    Your analogy does not cover C99 vs C90.

    You have a good 3/4" spanner. You don't throw it out just because you
    also get an adjustable spanner - sometimes the 3/4" spanner is more practical, or perhaps a bit stronger. That's keeping C when you also
    have C++ available.

    You have a good 3/4" spanner. You also have an adjustable wrench.

    They are welded together and and the 3/4" spanner is written
    in the language of the adjustable one ...

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Sat May 31 08:10:16 2025
    On Fri, 30 May 2025 18:18:43 +1000, Paul Edwards wrote:

    (The competition for first place being IBM's C compiler for z/OS)

    Come on, who writes C code for z/OS? Mainframes are supposed to be all
    about COBOL code, aren’t they? Or so we keep being told.

    And what might IBM’s COBOL compiler (and associated system utilities) be written in? Why, its long-time systems-programming language of choice,
    PL/I.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Sat May 31 16:20:33 2025
    Am 20.05.2025 um 09:27 schrieb Lawrence D'Oliveiro:
    On Tue, 20 May 2025 16:06:19 +1000, Paul Edwards wrote:

    And in essence, when you read from a directory, the only thing you get
    is the filename.

    You want at least the type of entry as well, surely.

    <https://manpages.debian.org/readdir(3)>

    Easier to handle: https://en.cppreference.com/w/cpp/filesystem/directory_iterator.html

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Sun Jun 1 07:42:05 2025
    On Sat, 31 May 2025 08:20:33 +0200, Bonita Montero wrote:

    Am 20.05.2025 um 09:27 schrieb Lawrence D'Oliveiro:

    On Tue, 20 May 2025 16:06:19 +1000, Paul Edwards wrote:

    And in essence, when you read from a directory, the only thing you get
    is the filename.

    You want at least the type of entry as well, surely.

    <https://manpages.debian.org/readdir(3)>

    Easier to handle: https://en.cppreference.com/w/cpp/filesystem/directory_iterator.html

    If you’re wanting language-specific facilities, then see if you can beat this <https://docs.python.org/3/library/os.html#os.walk>.

    For one thing, notice how it gives you the choice of whether to follow symlinks or not?

    Oh, and also notice os.fwalk(), which supports dirfds.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Sun Jun 1 15:58:54 2025
    Am 31.05.2025 um 23:42 schrieb Lawrence D'Oliveiro:

    On Sat, 31 May 2025 08:20:33 +0200, Bonita Montero wrote:

    Easier to handle:
    https://en.cppreference.com/w/cpp/filesystem/directory_iterator.html

    If you’re wanting language-specific facilities, then see if you can beat this <https://docs.python.org/3/library/os.html#os.walk>.
    For one thing, notice how it gives you the choice of whether to follow symlinks or not?

    Sth. like this:

    for( directory_entry const &de : recursive_directory_iterator( "\\", directory_options::follow_directory_symlink ) )
    cout << de.path() << endl;


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Sun Jun 1 17:43:19 2025
    On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:

    Am 31.05.2025 um 23:42 schrieb Lawrence D'Oliveiro:

    On Sat, 31 May 2025 08:20:33 +0200, Bonita Montero wrote:

    Easier to handle:
    https://en.cppreference.com/w/cpp/filesystem/directory_iterator.html

    If you’re wanting language-specific facilities, then see if you can
    beat this <https://docs.python.org/3/library/os.html#os.walk>. For
    one thing, notice how it gives you the choice of whether to follow
    symlinks or not?

    Sth. like this:

    for( directory_entry const &de : recursive_directory_iterator( "\\", directory_options::follow_directory_symlink ) )
    cout << de.path() << endl;

    You need the dirfd functions to avoid certain potential security holes
    on operations with symlinks.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Mon Jun 2 17:35:24 2025
    Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:

    On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:

    Sth. like this:

    for( directory_entry const &de : recursive_directory_iterator( "\\",
    directory_options::follow_directory_symlink ) )
    cout << de.path() << endl;

    You need the dirfd functions to avoid certain potential security holes
    on operations with symlinks.

    Which security holes ?


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Tue Jun 3 01:24:45 2025
    Reply-To: slp53@pacbell.net

    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:

    On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:

    Sth. like this:

    for( directory_entry const &de : recursive_directory_iterator( "\\", >>> directory_options::follow_directory_symlink ) )
    cout << de.path() << endl;

    You need the dirfd functions to avoid certain potential security holes
    on operations with symlinks.

    Which security holes ?


    The fchownat() function shall be equivalent to the chown() and lchown()
    functions except in the case where path specifies a relative path. In
    this case the file to be changed is determined relative to the directory
    associated with the file descriptor fd instead of the current working
    directory. If the access mode of the open file description associated
    with the file descriptor is not O_SEARCH, the function shall check
    whether directory searches are permitted using the current permissions
    of the directory underlying the file descriptor. If the access mode is
    O_SEARCH, the function shall not perform the check.

    Similiter for fstatat, faccessat, fchownat, openat, readlinkat et alia.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From James Kuyper@3:633/280.2 to All on Tue Jun 3 09:14:08 2025
    On 6/2/25 11:24, Scott Lurndal wrote:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:

    ....
    You need the dirfd functions to avoid certain potential security holes
    on operations with symlinks.

    Which security holes ?


    The fchownat() function shall be equivalent to the chown() and lchown() functions except in the case where path specifies a relative path. In
    this case the file to be changed is determined relative to the directory associated with the file descriptor fd instead of the current working directory. If the access mode of the open file description associated
    with the file descriptor is not O_SEARCH, the function shall check
    whether directory searches are permitted using the current permissions
    of the directory underlying the file descriptor. If the access mode is O_SEARCH, the function shall not perform the check.

    Similiter for fstatat, faccessat, fchownat, openat, readlinkat et alia.

    That describes what the functions do, it doesn't explain the potential
    security holes that they avoid. The hole might seem obvious to you, but
    it's certainly not obvious to me - probably because writing code to
    traverse directories is something I've almost never had to do.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Tue Jun 3 09:54:53 2025
    Reply-To: slp53@pacbell.net

    James Kuyper <jameskuyper@alumni.caltech.edu> writes:
    On 6/2/25 11:24, Scott Lurndal wrote:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:

    ...
    You need the dirfd functions to avoid certain potential security holes >>>> on operations with symlinks.

    Which security holes ?


    The fchownat() function shall be equivalent to the chown() and lchown()
    functions except in the case where path specifies a relative path. In
    this case the file to be changed is determined relative to the directory
    associated with the file descriptor fd instead of the current working
    directory. If the access mode of the open file description associated
    with the file descriptor is not O_SEARCH, the function shall check
    whether directory searches are permitted using the current permissions
    of the directory underlying the file descriptor. If the access mode is
    O_SEARCH, the function shall not perform the check.

    Similiter for fstatat, faccessat, fchownat, openat, readlinkat et alia.

    That describes what the functions do, it doesn't explain the potential >security holes that they avoid. The hole might seem obvious to you, but
    it's certainly not obvious to me - probably because writing code to
    traverse directories is something I've almost never had to do.



    From the posix standard:

    "The purpose of the fstatat() function is to obtain the status
    of files in directories other than the current working directory
    without exposure to race conditions. Any part of the path of a
    file could be changed in parallel to a call to stat(), resulting
    in unspecified behavior. By opening a file descriptor for the target
    directory and using the fstatat() function it can be guaranteed that
    the file for which status is returned is located relative to the desired directory."

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Tue Jun 3 10:37:39 2025
    On Mon, 2 Jun 2025 09:35:24 +0200, Bonita Montero wrote:

    Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:

    On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:

    Sth. like this:

    for( directory_entry const &de : recursive_directory_iterator( "\\", >>> directory_options::follow_directory_symlink ) )
    cout << de.path() << endl;

    You need the dirfd functions to avoid certain potential security
    holes on operations with symlinks.

    Which security holes ?

    TOCTOU.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Tue Jun 3 11:02:54 2025
    On 2025-06-02, Scott Lurndal <scott@slp53.sl.home> wrote:
    From the posix standard:

    "The purpose of the fstatat() function is to obtain the status
    of files in directories other than the current working directory
    without exposure to race conditions. Any part of the path of a
    file could be changed in parallel to a call to stat(), resulting
    in unspecified behavior. By opening a file descriptor for the target
    directory and using the fstatat() function it can be guaranteed that
    the file for which status is returned is located relative to the desired directory."

    The security guarantee you want is that when you follow some path
    /a/b/c/d/.., that none of the path components "a", "b", "c", "d", ...
    are under the control of an adversary. Adversary means any other user
    who is not you or root. (If you are root, any other user, therefore).

    If, say "c" is under the control of an adversary, then the adversary can
    make it a symlink, so that "d" is then anything whatsoever in any
    location whatsoever.

    I've developed an experimental security library called safepath
    which tries to validate a path for this kind of safety.

    https://www.kylheku.com/cgit/safepath/about/

    Caveat: note the lack of a test suite in this project!

    It doesn't rely on these functions because, it's not necesary.
    If you know that /a/b/c is safe, then by induction you can proceed
    to /a/b/c/d. For instance if you are root, and non-root is not able
    to tamper with /a/b/c, then, generally speaking, there is no race
    condition to worry about in making two accesses to c: one to check its permissions and ownership, and another to traverse it.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Wed Jun 4 03:41:23 2025
    Am 02.06.2025 um 17:24 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:

    On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:

    Sth. like this:

    for( directory_entry const &de : recursive_directory_iterator( "\\", >>>> directory_options::follow_directory_symlink ) )
    cout << de.path() << endl;

    You need the dirfd functions to avoid certain potential security holes
    on operations with symlinks.

    Which security holes ?


    The fchownat() function shall be equivalent to the chown() and lchown()
    functions except in the case where path specifies a relative path. In
    this case the file to be changed is determined relative to the directory
    associated with the file descriptor fd instead of the current working
    directory. If the access mode of the open file description associated
    with the file descriptor is not O_SEARCH, the function shall check
    whether directory searches are permitted using the current permissions
    of the directory underlying the file descriptor. If the access mode is
    O_SEARCH, the function shall not perform the check.

    And why is this relevant for directory_iterator or recursive_directory_iterator ?

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Wed Jun 4 04:25:17 2025
    Reply-To: slp53@pacbell.net

    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 02.06.2025 um 17:24 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:

    On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:

    Sth. like this:

    for( directory_entry const &de : recursive_directory_iterator( "\\", >>>>> directory_options::follow_directory_symlink ) )
    cout << de.path() << endl;

    You need the dirfd functions to avoid certain potential security holes >>>> on operations with symlinks.

    Which security holes ?


    The fchownat() function shall be equivalent to the chown() and lchown() >> functions except in the case where path specifies a relative path. In
    this case the file to be changed is determined relative to the directory >> associated with the file descriptor fd instead of the current working
    directory. If the access mode of the open file description associated
    with the file descriptor is not O_SEARCH, the function shall check
    whether directory searches are permitted using the current permissions >> of the directory underlying the file descriptor. If the access mode is >> O_SEARCH, the function shall not perform the check.

    And why is this relevant for directory_iterator or >recursive_directory_iterator ?

    Why are you asking this question on comp.lang.c?


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Wed Jun 4 19:23:42 2025
    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:101dac8$mkpm$3@dont-email.me...
    On Fri, 30 May 2025 18:18:43 +1000, Paul Edwards wrote:

    (The competition for first place being IBM's C compiler for z/OS)

    Come on, who writes C code for z/OS?

    I used to at one place I worked. Neither I nor the company
    were alone in the world.

    Mainframes are supposed to be all
    about COBOL code, aren't they? Or so we keep being told.

    That would make the IBM COBOL compiler the most important
    compiler in the world, not the most important C compiler in the world.

    And what might IBM's COBOL compiler (and associated system utilities) be written in? Why, its long-time systems-programming language of choice,
    PL/I.

    Yep - all locking you down to the most important platform
    in the world.

    If you want to be able to escape from this situation, in case
    IBM uses its monpoly to screw you over, you probably want
    to switch to IBM C, and code in C90, so that your
    institution can jump ship in that situation, as there are inferior
    systems waiting to accept your entire codebase.

    And I know what you're thinking - all the data is in EBCDIC.
    There are no other EBCDIC systems I could possibly jump to.
    We would need an 80386 EBCDIC version of Win32 in order
    for this to be remotely possible - which doesn't exist, and likely
    never will exist.

    For it to exist it would need some sort of pseudo-bios concept
    that allowed charset conversion. And no such thing exists as far
    as I am aware!


    Watch this spot.

    D:\devel\pdos\pdpclib>grep EBCDIC makefile.p32
    makefile.p32: # define this if you are producing an EBCDIC to ASCII
    pseudo-bios
    makefile.p32: # char needs to be unsigned for EBCDIC so this should be

    D:\devel\pdos\pdpclib>

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Wed Jun 4 23:05:14 2025
    Reply-To: slp53@pacbell.net

    "Paul Edwards" <mutazilah@gmail.com> writes:
    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message

    And I know what you're thinking - all the data is in EBCDIC.
    There are no other EBCDIC systems I could possibly jump to.

    Except for various Unisys systems, which are still being sold.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Thu Jun 5 00:00:53 2025
    "Scott Lurndal" <scott@slp53.sl.home> wrote in message news:ewX%P.70348$ZDN7.23298@fx35.iad...
    "Paul Edwards" <mutazilah@gmail.com> writes:
    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message

    And I know what you're thinking - all the data is in EBCDIC.
    There are no other EBCDIC systems I could possibly jump to.

    Except for various Unisys systems, which are still being sold.

    Can you tell me what CPU is being used on the EBCDIC
    systems? Is it the one where C is basically impossible to
    implement, while COBOL is a good fit?

    Are they selling actual CPUs or are they using emulation?

    If using emulation, I may as well emulate an IBM mainframe.
    There is a commercial z/Arch emulator already.

    Thanks. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From David Brown@3:633/280.2 to All on Thu Jun 5 01:30:30 2025
    On 04/06/2025 11:23, Paul Edwards wrote:

    And I know what you're thinking - all the data is in EBCDIC.
    There are no other EBCDIC systems I could possibly jump to.
    We would need an 80386 EBCDIC version of Win32 in order
    for this to be remotely possible - which doesn't exist, and likely
    never will exist.

    For it to exist it would need some sort of pseudo-bios concept
    that allowed charset conversion. And no such thing exists as far
    as I am aware!


    You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
    /that/ might be) to use data using EBCDIC character encoding. It is no different from working with any other character encoding - ASCII, UTF-8, different 8-bit code pages, or whatever. If the data is just passing
    through your code, read it in and pass it out without a care. If you
    need to convert it or mix it with some other encoding, work with a
    common encoding - UTF-8 is normally the right choice.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From =?UTF-8?Q?Josef_M=C3=B6llers?=@3:633/280.2 to All on Thu Jun 5 04:48:45 2025
    On 04.06.25 17:30, David Brown wrote:
    On 04/06/2025 11:23, Paul Edwards wrote:

    And I know what you're thinking - all the data is in EBCDIC.
    There are no other EBCDIC systems I could possibly jump to.
    We would need an 80386 EBCDIC version of Win32 in order
    for this to be remotely possible - which doesn't exist, and likely
    never will exist.

    For it to exist it would need some sort of pseudo-bios concept
    that allowed charset conversion. And no such thing exists as far
    as I am aware!


    You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
    /that/ might be) to use data using EBCDIC character encoding. It is no different from working with any other character encoding - ASCII, UTF-8, different 8-bit code pages, or whatever. If the data is just passing through your code, read it in and pass it out without a care. If you
    need to convert it or mix it with some other encoding, work with a
    common encoding - UTF-8 is normally the right choice.

    This might be true if there were no special characters, but eg the slash
    is 2FH in ASCII but 61H in EBCDIC, so Linux may have a problem there.
    The backslash is 0E0H in EBCDIC (at least in Australia, Brasil, Canada,
    and various other countries), 0ECH in Germany and Austria while it is
    5CH in ASCII. So DOS and Windows have a problem here.

    So, YES, the operating system has to be aware of the code set used.

    Josef

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: ---:- FTN<->UseNet Gate -:--- (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Thu Jun 5 04:58:23 2025
    "David Brown" <david.brown@hesbynett.no> wrote in message news:101poqm$t350$1@dont-email.me...
    On 04/06/2025 11:23, Paul Edwards wrote:

    And I know what you're thinking - all the data is in EBCDIC.
    There are no other EBCDIC systems I could possibly jump to.
    We would need an 80386 EBCDIC version of Win32 in order
    for this to be remotely possible - which doesn't exist, and likely
    never will exist.

    For it to exist it would need some sort of pseudo-bios concept
    that allowed charset conversion. And no such thing exists as far
    as I am aware!

    You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
    /that/ might be) to use data using EBCDIC character encoding. It is no different from working with any other character encoding - ASCII, UTF-8, different 8-bit code pages, or whatever. If the data is just passing
    through your code, read it in and pass it out without a care. If you
    need to convert it or mix it with some other encoding, work with a
    common encoding - UTF-8 is normally the right choice.

    If I have existing C code that does:

    fopen("test1.dat", "rb");
    fread into buf
    if (memcmp(buf + 5, "XYZ", 3) == 0)

    and test1.dat is in EBCDIC, the above program on the 80386
    has been compiled with EBCDIC strings, so it works, and then
    now you do:

    printf("It matches!\n");

    where do you expect those characters in the printf string - all
    currently EBCDIC - to be translated to ASCII on a modern
    Windows 10/11 system?

    And how do you expect Windows 10/11 to find "test1.dat" -
    all EBCDIC on its current ASCII filesystem?

    And I would want the data to remain in EBCDIC for
    easy transportation, so if I do:

    fopen("output.txt", "w")
    I expect that file to remain in EBCDIC, so that it can be
    opened with "rb" by zip.


    You could indeed statically link a C library that takes care
    of all that - with EBCDIC to ASCII conversion happening
    on just filenames and the stdin/stdout/stderr streams.

    Or you could have a dynamic C library and OS (possibly
    combined) that sits between your app and the Windows OS
    so that things are more reasonable.

    And either way, you will need the supporting 80386 EBCDIC
    Win32 toolchain to make it work. You would need someone
    (or some people) really bloody-minded to sit down and
    assemble all the required infrastructure over years, indeed
    decades, to make it all work.

    Fortunately the internet is big enough to find all the required
    people to make it happen.

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Thu Jun 5 05:19:45 2025
    On 2025-06-04, Paul Edwards <mutazilah@gmail.com> wrote:
    If I have existing C code that does:

    fopen("test1.dat", "rb");
    fread into buf
    if (memcmp(buf + 5, "XYZ", 3) == 0)

    and test1.dat is in EBCDIC, the above program on the 80386
    has been compiled with EBCDIC strings, so it works, and then
    now you do:

    printf("It matches!\n");

    where do you expect those characters in the printf string - all
    currently EBCDIC - to be translated to ASCII on a modern
    Windows 10/11 system?

    I think that in this case you would ideally want the EBCDIC-enabled
    compiler to have extensions for working with both character sets.

    For isntance E"foo" would specify a string object that is
    encoded in EBCDIC in the execution environment, whereas
    "foo" is ASCII.

    You could develop a textual preprocesor which implements
    this transformation: tokenizes the C well enough to recognize
    string literals preceded by E, and translates them to
    string literals without E, whose content is EBCDIC bytes.

    It wouldn't have to be absoultely perfect; only to work
    correctly on your small amount of private code.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Thu Jun 5 05:24:17 2025
    "Kaz Kylheku" <643-408-1753@kylheku.com> wrote in message news:20250604121550.286@kylheku.com...
    On 2025-06-04, Paul Edwards <mutazilah@gmail.com> wrote:
    If I have existing C code that does:

    fopen("test1.dat", "rb");
    fread into buf
    if (memcmp(buf + 5, "XYZ", 3) == 0)

    and test1.dat is in EBCDIC, the above program on the 80386
    has been compiled with EBCDIC strings, so it works, and then
    now you do:

    printf("It matches!\n");

    where do you expect those characters in the printf string - all
    currently EBCDIC - to be translated to ASCII on a modern
    Windows 10/11 system?

    I think that in this case you would ideally want the EBCDIC-enabled
    compiler to have extensions for working with both character sets.

    For isntance E"foo" would specify a string object that is
    encoded in EBCDIC in the execution environment, whereas
    "foo" is ASCII.

    You could develop a textual preprocesor which implements
    this transformation: tokenizes the C well enough to recognize
    string literals preceded by E, and translates them to
    string literals without E, whose content is EBCDIC bytes.

    It wouldn't have to be absoultely perfect; only to work
    correctly on your small amount of private code.

    Even assuming the above was technically possible - what's
    wrong with just having a pseudo-bios and OS so that
    everything is totally clean?

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Thu Jun 5 07:09:13 2025
    Reply-To: slp53@pacbell.net

    =?UTF-8?Q?Josef_M=C3=B6llers?= <josef@invalid.invalid> writes:
    On 04.06.25 17:30, David Brown wrote:
    On 04/06/2025 11:23, Paul Edwards wrote:

    And I know what you're thinking - all the data is in EBCDIC.
    There are no other EBCDIC systems I could possibly jump to.
    We would need an 80386 EBCDIC version of Win32 in order
    for this to be remotely possible - which doesn't exist, and likely
    never will exist.

    For it to exist it would need some sort of pseudo-bios concept
    that allowed charset conversion. And no such thing exists as far
    as I am aware!


    You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
    /that/ might be) to use data using EBCDIC character encoding.  It is no
    different from working with any other character encoding - ASCII, UTF-8,
    different 8-bit code pages, or whatever.  If the data is just passing
    through your code, read it in and pass it out without a care.  If you
    need to convert it or mix it with some other encoding, work with a
    common encoding - UTF-8 is normally the right choice.

    This might be true if there were no special characters, but eg the slash
    is 2FH in ASCII but 61H in EBCDIC, so Linux may have a problem there.
    The backslash is 0E0H in EBCDIC (at least in Australia, Brasil, Canada,
    and various other countries), 0ECH in Germany and Austria while it is
    5CH in ASCII. So DOS and Windows have a problem here.

    There's more than one EBCDIC encoding, the Burroughs encoding differs
    from the IBM encoding in several areas; '[' and ']' in particular.


    So, YES, the operating system has to be aware of the code set used.

    David was referring to the application, not the OS. As he said,
    the application writer can do whatever is necessary to support EBCDIC, including translating it to ASCII when communicating with code that
    doesn't support EBCDIC.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Thu Jun 5 07:30:38 2025
    On 2025-06-04, Paul Edwards <mutazilah@gmail.com> wrote:
    "Kaz Kylheku" <643-408-1753@kylheku.com> wrote in message news:20250604121550.286@kylheku.com...
    On 2025-06-04, Paul Edwards <mutazilah@gmail.com> wrote:
    If I have existing C code that does:

    fopen("test1.dat", "rb");
    fread into buf
    if (memcmp(buf + 5, "XYZ", 3) == 0)

    and test1.dat is in EBCDIC, the above program on the 80386
    has been compiled with EBCDIC strings, so it works, and then
    now you do:

    printf("It matches!\n");

    where do you expect those characters in the printf string - all
    currently EBCDIC - to be translated to ASCII on a modern
    Windows 10/11 system?

    I think that in this case you would ideally want the EBCDIC-enabled
    compiler to have extensions for working with both character sets.

    For isntance E"foo" would specify a string object that is
    encoded in EBCDIC in the execution environment, whereas
    "foo" is ASCII.

    You could develop a textual preprocesor which implements
    this transformation: tokenizes the C well enough to recognize
    string literals preceded by E, and translates them to
    string literals without E, whose content is EBCDIC bytes.

    It wouldn't have to be absoultely perfect; only to work
    correctly on your small amount of private code.

    Even assuming the above was technically possible - what's
    wrong with just having a pseudo-bios and OS so that
    everything is totally clean?

    Nothing; it's just that the OS doesn't match the requirement given in
    some above quoted text I was responding to that this is on "modern
    Windows 10/11 system" which requires the program output to be
    "translated to ASCII".

    (There are obvious advantages to working with a widely used,
    contemporary system; I don't see it necessary to go into those.)

    A C program built on and running on an ASCII system, handling EBCDIC
    data, could benefit from having an E"..." string literal feature, as
    well as a E' ' character constant feature, either as a compiler
    extension or a preprocessing tool, so that in places where EBCDIC text
    is being handled, literals in that encoding could be conveniently
    specified.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Thu Jun 5 09:22:00 2025
    On Wed, 4 Jun 2025 19:23:42 +1000, Paul Edwards wrote:

    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:101dac8$mkpm$3@dont-email.me...

    Mainframes are supposed to be all about COBOL code, aren't they? Or so
    we keep being told.

    That would make the IBM COBOL compiler the most important compiler in
    the world, not the most important C compiler in the world.

    We heard that 20-30 years ago. IBM’s declining fortunes over all that time clearly indicate otherwise: batch-oriented mainframes are simply not a
    growth market. All that COBOL code is going out of use, one way or
    another: if the companies reliant on it don’t retire it, they are more likely to go out of business anyway. It’s just free-market competition in action.

    Most of the remaining COBOL code nowadays is compiled with ... wait for
    it ... GNU COBOL. And the GNU compiler suite is, I believe, written in C++
    at its core these days (used to be C).

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Thu Jun 5 09:48:20 2025
    Reply-To: slp53@pacbell.net

    Lawrence D'Oliveiro <ldo@nz.invalid> writes:
    On Wed, 4 Jun 2025 19:23:42 +1000, Paul Edwards wrote:


    Most of the remaining COBOL code nowadays is compiled with ... wait for
    it ... GNU COBOL. And the GNU compiler suite is, I believe, written in C++ >at its core these days (used to be C).

    I suspect your rather baseless assertion would be a surprise to Micro Focus.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From David Brown@3:633/280.2 to All on Thu Jun 5 16:18:27 2025
    On 04/06/2025 20:48, Josef Mllers wrote:
    On 04.06.25 17:30, David Brown wrote:
    On 04/06/2025 11:23, Paul Edwards wrote:

    And I know what you're thinking - all the data is in EBCDIC.
    There are no other EBCDIC systems I could possibly jump to.
    We would need an 80386 EBCDIC version of Win32 in order
    for this to be remotely possible - which doesn't exist, and likely
    never will exist.

    For it to exist it would need some sort of pseudo-bios concept
    that allowed charset conversion. And no such thing exists as far
    as I am aware!


    You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
    /that/ might be) to use data using EBCDIC character encoding. It is
    no different from working with any other character encoding - ASCII,
    UTF-8, different 8-bit code pages, or whatever. If the data is just
    passing through your code, read it in and pass it out without a care.
    If you need to convert it or mix it with some other encoding, work
    with a common encoding - UTF-8 is normally the right choice.

    This might be true if there were no special characters, but eg the slash
    is 2FH in ASCII but 61H in EBCDIC, so Linux may have a problem there.
    The backslash is 0E0H in EBCDIC (at least in Australia, Brasil, Canada,
    and various other countries), 0ECH in Germany and Austria while it is
    5CH in ASCII. So DOS and Windows have a problem here.

    So, YES, the operating system has to be aware of the code set used.


    No, it does not.

    Data is not handled by an OS, data is handled by an application. When
    an OS reads or writes a file, it doesn't care if it is in ASCII,
    UTF-EBCDIC, a jpeg file, or anything else. That is up to the
    application code.

    When the application is interacting with the OS in a way that uses
    text-based parameters - such as for opening files, creating directories
    and the like - then the application needs to make sure the parameters it
    sends are in the appropriate format. If the OS call expects ASCII, the application must ensure it is ASCII - not UTF-8 or anything else. If
    the application has a filename in UTF-8 or EBCDIC and the OS expects
    UCS2, then the application has to convert the encoding first. If the OS treats certain characters in a special way, then the application needs
    to ensure it uses those characters appropriately. The same applies with interaction with any other library or code, not just OS calls.

    This is all exactly the same for any character encoding. There is
    nothing remotely special about EBCDIC other than it's horrible design
    and dozen different incompatible encodings.




    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From David Brown@3:633/280.2 to All on Thu Jun 5 16:32:18 2025
    On 04/06/2025 20:58, Paul Edwards wrote:
    "David Brown" <david.brown@hesbynett.no> wrote in message news:101poqm$t350$1@dont-email.me...
    On 04/06/2025 11:23, Paul Edwards wrote:

    And I know what you're thinking - all the data is in EBCDIC.
    There are no other EBCDIC systems I could possibly jump to.
    We would need an 80386 EBCDIC version of Win32 in order
    for this to be remotely possible - which doesn't exist, and likely
    never will exist.

    For it to exist it would need some sort of pseudo-bios concept
    that allowed charset conversion. And no such thing exists as far
    as I am aware!

    You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
    /that/ might be) to use data using EBCDIC character encoding. It is no
    different from working with any other character encoding - ASCII, UTF-8,
    different 8-bit code pages, or whatever. If the data is just passing
    through your code, read it in and pass it out without a care. If you
    need to convert it or mix it with some other encoding, work with a
    common encoding - UTF-8 is normally the right choice.

    If I have existing C code that does:

    fopen("test1.dat", "rb");
    fread into buf
    if (memcmp(buf + 5, "XYZ", 3) == 0)

    and test1.dat is in EBCDIC, the above program on the 80386
    has been compiled with EBCDIC strings, so it works, and then
    now you do:

    printf("It matches!\n");

    where do you expect those characters in the printf string - all
    currently EBCDIC - to be translated to ASCII on a modern
    Windows 10/11 system?


    In /your/ code!

    /You/ are responsible for writing the code that handles the data, and
    which gets the encoding right. If you want to handle data in an odd
    encoding, write code to handle it. That's what everyone else does when dealing with data in different encodings.


    And how do you expect Windows 10/11 to find "test1.dat" -
    all EBCDIC on its current ASCII filesystem?

    Convert the character encoding for the string.

    People do this all the time. They write code that uses UTF-8, and have
    to deal with Windows crappy UCS2 / partial UTF-16 / wchar_t mess. Or
    they have code that supports different code pages because they started
    it in the pre-Unicode days and don't live in a little American-only
    ASCII bubble.

    C does not make this stuff particularly convenient, though it has
    improved a little since C90 - other languages have vastly superior
    string and encoding handling. But that does not mean you can't do it,
    or should not do it.

    Maybe if you actually wanted to contribute something useful to the C
    world - something that other people might find useful - you could put
    your efforts into writing a library that has functions for converting encodings back and forth with UTF-8 as the base. Include support for
    the dozen different EDBDIC versions.

    Or do you really think that if someone sent me a file to read that was
    in EDBDIC encoding, I'd be happy to install an EDBDIC "pseudo-bios" and
    EDBDIC version of Windows so that I could read it?


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Thu Jun 5 19:28:53 2025
    "David Brown" <david.brown@hesbynett.no> wrote in message news:101rdli$1cb3a$2@dont-email.me...
    On 04/06/2025 20:58, Paul Edwards wrote:
    "David Brown" <david.brown@hesbynett.no> wrote in message news:101poqm$t350$1@dont-email.me...
    On 04/06/2025 11:23, Paul Edwards wrote:

    And I know what you're thinking - all the data is in EBCDIC.
    There are no other EBCDIC systems I could possibly jump to.
    We would need an 80386 EBCDIC version of Win32 in order
    for this to be remotely possible - which doesn't exist, and likely
    never will exist.

    For it to exist it would need some sort of pseudo-bios concept
    that allowed charset conversion. And no such thing exists as far
    as I am aware!

    You don't need an EBCDIC operating system, or "pseudo-bios" (whatever
    /that/ might be) to use data using EBCDIC character encoding. It is no
    different from working with any other character encoding - ASCII,
    UTF-8,
    different 8-bit code pages, or whatever. If the data is just passing
    through your code, read it in and pass it out without a care. If you
    need to convert it or mix it with some other encoding, work with a
    common encoding - UTF-8 is normally the right choice.

    If I have existing C code that does:

    fopen("test1.dat", "rb");
    fread into buf
    if (memcmp(buf + 5, "XYZ", 3) == 0)

    and test1.dat is in EBCDIC, the above program on the 80386
    has been compiled with EBCDIC strings, so it works, and then
    now you do:

    printf("It matches!\n");

    where do you expect those characters in the printf string - all
    currently EBCDIC - to be translated to ASCII on a modern
    Windows 10/11 system?


    In /your/ code!

    /You/ are responsible for writing the code that handles the data, and
    which gets the encoding right. If you want to handle data in an odd encoding, write code to handle it. That's what everyone else does when dealing with data in different encodings.

    With my application programmer's hat on, I have already
    written the code, it is already C90-compliant, and no, I
    don't want to change my code.

    And how do you expect Windows 10/11 to find "test1.dat" -
    all EBCDIC on its current ASCII filesystem?

    Convert the character encoding for the string.

    People do this all the time. They write code that uses UTF-8, and have
    to deal with Windows crappy UCS2 / partial UTF-16 / wchar_t mess. Or
    they have code that supports different code pages because they started
    it in the pre-Unicode days and don't live in a little American-only
    ASCII bubble.

    C does not make this stuff particularly convenient, though it has
    improved a little since C90 - other languages have vastly superior
    string and encoding handling. But that does not mean you can't do it,
    or should not do it.

    Maybe if you actually wanted to contribute something useful to the C
    world - something that other people might find useful - you could put
    your efforts into writing a library that has functions for converting encodings back and forth with UTF-8 as the base. Include support for
    the dozen different EDBDIC versions.

    Or do you really think that if someone sent me a file to read that was
    in EDBDIC encoding, I'd be happy to install an EDBDIC "pseudo-bios" and EDBDIC version of Windows so that I could read it?

    It's not for you to send a file.

    It's for an enterprise - suddenly forced off the mainframe -
    to carry on, on a different machine, with no data conversion,
    and no code changes, because they took the precaution of
    writing in C90.

    And all running at native speed on the new x64 processor.

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Thu Jun 5 19:31:38 2025
    "Kaz Kylheku" <643-408-1753@kylheku.com> wrote in message news:20250604142536.604@kylheku.com...
    On 2025-06-04, Paul Edwards <mutazilah@gmail.com> wrote:
    "Kaz Kylheku" <643-408-1753@kylheku.com> wrote in message news:20250604121550.286@kylheku.com...
    On 2025-06-04, Paul Edwards <mutazilah@gmail.com> wrote:
    If I have existing C code that does:

    fopen("test1.dat", "rb");
    fread into buf
    if (memcmp(buf + 5, "XYZ", 3) == 0)

    and test1.dat is in EBCDIC, the above program on the 80386
    has been compiled with EBCDIC strings, so it works, and then
    now you do:

    printf("It matches!\n");

    where do you expect those characters in the printf string - all
    currently EBCDIC - to be translated to ASCII on a modern
    Windows 10/11 system?

    I think that in this case you would ideally want the EBCDIC-enabled
    compiler to have extensions for working with both character sets.

    For isntance E"foo" would specify a string object that is
    encoded in EBCDIC in the execution environment, whereas
    "foo" is ASCII.

    You could develop a textual preprocesor which implements
    this transformation: tokenizes the C well enough to recognize
    string literals preceded by E, and translates them to
    string literals without E, whose content is EBCDIC bytes.

    It wouldn't have to be absoultely perfect; only to work
    correctly on your small amount of private code.

    Even assuming the above was technically possible - what's
    wrong with just having a pseudo-bios and OS so that
    everything is totally clean?

    Nothing; it's just that the OS doesn't match the requirement given in
    some above quoted text I was responding to that this is on "modern
    Windows 10/11 system" which requires the program output to be
    "translated to ASCII".

    The OS - PDOS-generic - does (or can) "match the requirement".

    The underlying Windows 10/11 system is converted into
    nothing more than a glorified BIOS, ie pseudo-bios, which
    PDOS-generic can then run under.

    No emulation. Native x64 speed. EBCDIC.

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Paul Edwards@3:633/280.2 to All on Thu Jun 5 20:25:37 2025
    "David Brown" <david.brown@hesbynett.no> wrote in message news:101rdli$1cb3a$2@dont-email.me...

    Maybe if you actually wanted to contribute something useful to the C
    world - something that other people might find useful

    I'm not trying to win Miss America.

    I'm trying to make C90 - or a slight variation - that e.g.
    would include directory operations, hence the title,
    actually "work as designed".

    None of this nonsense about "real world programs
    can't be written in C90".

    Instead, if someone complains about IBM's monopoly, I
    just want to be able to respond "well maybe you should
    have written your app in C90. If you had, you could have
    moved your entire application, completely unchanged,
    with a simple recompile".

    Previously people could have said "It's not a simple
    matter of recompilation - you need to migrate the
    data from EBCDIC to ASCII too".

    And even further back than that, they would have said
    something along the lines of "IBM files are record-based
    and cannot be migrated".

    I never really understood the comment about being
    record-based. Took a long time to find out they were
    talking about the Loch Ness Monster.

    And the "-m31" (instead of -m32) option of gcc was
    another Loch Ness Monster.

    It took a long time to drain Loch Ness once and for all.

    And bring IBM mainframes in from the cold.

    BFN. Paul.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Waldek Hebisch@3:633/280.2 to All on Fri Jun 6 13:26:40 2025
    David Brown <david.brown@hesbynett.no> wrote:

    Maybe if you actually wanted to contribute something useful to the C
    world - something that other people might find useful - you could put
    your efforts into writing a library that has functions for converting encodings back and forth with UTF-8 as the base. Include support for
    the dozen different EDBDIC versions.

    AFAICS librecode already exists and can do this.

    --
    Waldek Hebisch

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: To protect and to server (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Fri Jun 6 18:29:12 2025
    Am 03.06.2025 um 20:25 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 02.06.2025 um 17:24 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:

    On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:

    Sth. like this:

    for( directory_entry const &de : recursive_directory_iterator( "\\", >>>>>> directory_options::follow_directory_symlink ) )
    cout << de.path() << endl;

    You need the dirfd functions to avoid certain potential security holes >>>>> on operations with symlinks.

    Which security holes ?


    The fchownat() function shall be equivalent to the chown() and lchown()
    functions except in the case where path specifies a relative path. In >>> this case the file to be changed is determined relative to the directory
    associated with the file descriptor fd instead of the current working >>> directory. If the access mode of the open file description associated >>> with the file descriptor is not O_SEARCH, the function shall check
    whether directory searches are permitted using the current permissions >>> of the directory underlying the file descriptor. If the access mode is >>> O_SEARCH, the function shall not perform the check.

    And why is this relevant for directory_iterator or
    recursive_directory_iterator ?

    Why are you asking this question on comp.lang.c?

    Because you can have it easier than with opendir() / readdir().


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Sat Jun 7 00:10:07 2025
    Reply-To: slp53@pacbell.net

    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 03.06.2025 um 20:25 schrieb Scott Lurndal:

    The fchownat() function shall be equivalent to the chown() and lchown()
    functions except in the case where path specifies a relative path. In >>>> this case the file to be changed is determined relative to the directory
    associated with the file descriptor fd instead of the current working >>>> directory. If the access mode of the open file description associated >>>> with the file descriptor is not O_SEARCH, the function shall check >>>> whether directory searches are permitted using the current permissions
    of the directory underlying the file descriptor. If the access mode is
    O_SEARCH, the function shall not perform the check.

    And why is this relevant for directory_iterator or
    recursive_directory_iterator ?

    Why are you asking this question on comp.lang.c?

    Because you can have it easier than with opendir() / readdir().

    Personally, I'd use nftw to iterate over a path.

    https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.html


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Sat Jun 7 03:10:13 2025
    Am 06.06.2025 um 16:10 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 03.06.2025 um 20:25 schrieb Scott Lurndal:

    The fchownat() function shall be equivalent to the chown() and lchown()
    functions except in the case where path specifies a relative path. In
    this case the file to be changed is determined relative to the directory
    associated with the file descriptor fd instead of the current working
    directory. If the access mode of the open file description associated
    with the file descriptor is not O_SEARCH, the function shall check >>>>> whether directory searches are permitted using the current permissions
    of the directory underlying the file descriptor. If the access mode is
    O_SEARCH, the function shall not perform the check.

    And why is this relevant for directory_iterator or
    recursive_directory_iterator ?

    Why are you asking this question on comp.lang.c?

    Because you can have it easier than with opendir() / readdir().

    Personally, I'd use nftw to iterate over a path.

    https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.html

    That would be much nicer with a lambda which can take the context
    of the calling function.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Sat Jun 7 03:24:50 2025
    Reply-To: slp53@pacbell.net

    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 06.06.2025 um 16:10 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 03.06.2025 um 20:25 schrieb Scott Lurndal:

    The fchownat() function shall be equivalent to the chown() and lchown()
    functions except in the case where path specifies a relative path. In
    this case the file to be changed is determined relative to the directory
    associated with the file descriptor fd instead of the current working
    directory. If the access mode of the open file description associated
    with the file descriptor is not O_SEARCH, the function shall check >>>>>> whether directory searches are permitted using the current permissions
    of the directory underlying the file descriptor. If the access mode is
    O_SEARCH, the function shall not perform the check.

    And why is this relevant for directory_iterator or
    recursive_directory_iterator ?

    Why are you asking this question on comp.lang.c?

    Because you can have it easier than with opendir() / readdir().

    Personally, I'd use nftw to iterate over a path.

    https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.html

    That would be much nicer with a lambda which can take the context
    of the calling function.


    That's a matter of opinion. In any case, nftw is a C function
    and C doesn't support lamda functions. nftw can be used
    in any C++ code, it is not restricted to C++17 or higher,
    which makes it far more portable than std::filesystem::directory_iterator
    (not to mention much easier to type :-).

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Sat Jun 7 03:26:51 2025
    Am 06.06.2025 um 19:24 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 06.06.2025 um 16:10 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 03.06.2025 um 20:25 schrieb Scott Lurndal:

    The fchownat() function shall be equivalent to the chown() and lchown()
    functions except in the case where path specifies a relative path. In
    this case the file to be changed is determined relative to the directory
    associated with the file descriptor fd instead of the current working
    directory. If the access mode of the open file description associated
    with the file descriptor is not O_SEARCH, the function shall check
    whether directory searches are permitted using the current permissions
    of the directory underlying the file descriptor. If the access mode is
    O_SEARCH, the function shall not perform the check.

    And why is this relevant for directory_iterator or
    recursive_directory_iterator ?

    Why are you asking this question on comp.lang.c?

    Because you can have it easier than with opendir() / readdir().

    Personally, I'd use nftw to iterate over a path.

    https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.html

    That would be much nicer with a lambda which can take the context
    of the calling function.


    That's a matter of opinion.

    It results in much less code. Just like a lambda passed
    to std::sort() which takes context of the calling function.

    In any case, nftw is a C function and C doesn't support lamda functions.

    Lambdas without capture can be converted to C function-pointers.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From wij@3:633/280.2 to All on Sat Jun 7 06:04:24 2025
    On Fri, 2025-06-06 at 19:26 +0200, Bonita Montero wrote:
    Am 06.06.2025 um 19:24 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 06.06.2025 um 16:10 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 03.06.2025 um 20:25 schrieb Scott Lurndal:
    =20
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The fchownat() functio=
    n shall be equivalent to the chown() and lchown()
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 functions except in th=
    e case where path specifies a relative path. In
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this case the file to =
    be changed is determined relative to the directory
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 associated with the fi=
    le descriptor fd instead of the current working
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 directory. If the acce=
    ss mode of the open file description associated
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with the file descript=
    or is not O_SEARCH, the function shall check
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 whether directory sear=
    ches are permitted using the current permissions
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the directory under=
    lying the file descriptor. If the access mode is
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 O_SEARCH, the function=
    shall not perform the check.
    =20
    And why is this relevant for directory_iterator or recursive_directory_iterator ?
    =20
    Why are you asking this question on comp.lang.c?
    =20
    Because you can have it easier than with opendir() / readdir().
    =20
    Personally, I'd use nftw to iterate over a path.
    =20
    https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.htm=
    l
    =20
    That would be much nicer with a lambda which can take the context
    of the calling function.
    =20
    =20
    That's a matter of opinion.
    =20
    It results in much less code.=C2=A0

    That is illusion, particularly in this case (about directory).
    Most serious programs will 'invent' their own functions, even their own
    'sugar syntax'... result would be better than 'directory_iterator'.
    In general, no need for such things as 'directory_iterator' in C-library.

    Just like a lambda passed
    to std::sort() which takes context of the calling function.
    =20
    In any case, nftw is a C function and C doesn't support lamda functions=
    ..
    =20
    Lambdas without capture can be converted to C function-pointers.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Tim Rentsch@3:633/280.2 to All on Sat Jun 7 10:16:09 2025
    Kaz Kylheku <643-408-1753@kylheku.com> writes:

    On 2025-05-28, Michael S <already5chosen@yahoo.com> wrote:

    Got it. Stability occurs when the standards is fenced from
    changes by presence of the next edition.

    Each technical corrigendum effectively yields a new edition.

    The previous standard without that corrigendum is forever stable,
    as any immutable object.

    There are two reasons why these comments are off base.

    The first is the word "edition" is wrong. All of the ISO documents
    related to C99, whether the original one or a later one associated
    with a TC, all say "this second edition...". And similarly for
    other versions of the language.

    The second is that the discussion is not about what is covered by
    ISO labels but about C90, C99, C11, etc. Each of these names is
    about one edition of the language, no matter how many separate ISO
    documents are involved, and that's what the conversation is
    concerned with. The documents might be immutable, but the documents
    are not what is under discussion, which is different versions (in
    other words editions, in the official terminology of the ISO C
    standards) of the C language.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Tim Rentsch@3:633/280.2 to All on Sat Jun 7 10:26:21 2025
    Michael S <already5chosen@yahoo.com> writes:

    On Tue, 27 May 2025 16:16:50 -0700
    Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

    Michael S <already5chosen@yahoo.com> writes:

    On Tue, 27 May 2025 16:23:22 +0200
    David Brown <david.brown@hesbynett.no> wrote:

    On 26/05/2025 07:19, Peter 'Shaggy' Haywood wrote:

    Groovy hepcat Tim Rentsch was jivin' in comp.lang.c on Fri, 23 May
    2025 10:43 pm. It's a cool scene! Dig it.

    C99 is just as stable as C90, and has been for well over a
    decade.

    Methinks Tim is having trouble with his arithmetic. Either
    that or he doesn't know what year it is now. :)
    C99 was ratified in 1999, over two and a half decades ago.

    C11 is just as stable as C90, and has been for just slightly
    less than a decade.

    And C11 was ratified in 2011, no? That was almost a decade
    and a half ago.

    Tim was, I believe, taking into account the time it took for common
    implementations of C compilers and libraries to have complete and
    generally bug-free support for the standards, and for these
    implementations to become common. C99 was published in 1999, but
    it took quite a while before most people programming in C could
    happily use C99 without worrying about the tool support being
    "experimental" or not as mature as C90 support.

    I believe that your belief is wrong.
    It is much more likely that Tim took into account defect reports.
    Here is the list of C11 defect reports with the last dated 2016:
    https://open-std.org/jtc1/sc22/wg14/www/docs/summary.htm

    I did not find similar list for C99. However believing Tim I would
    guess that the last change in C99 document was made ~15 years ago.

    You are partly right. Besides defect reports, there are TCs. And
    there is always the possibility of future TCs, future defect
    reports, or future changes for any ISO C standard while it is
    still current.

    To be as stable as C90, a C standard would need to be immune to
    the possibility of such future changes.

    I take C99 to have reached this level of stability in 2011, when
    it was superseded by C11. I take C11 to have reached this level
    of stability in 2017, when it was superseded by C17.

    Got it. Stability occurs when the standards is fenced from
    changes by presence of the next edition.
    Stability by obsolescence.

    Right except the word obsolescence is not appropriate. The release
    of C99 doesn't make C90 either obsolete or obsolescent. It is
    possible that a given earlier edition of C will become either
    obsolete or obsolescent, but it isn't the release of a subsequent
    edition that does that. Stability happens when a subsequent edition
    is ratified, regardless of when or whether an earlier edition ever
    becomes either obsolete or obsolescent. No edition of C is now
    obsolete, nor do I expect any of them will be during our lifetimes.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Sat Jun 7 14:24:53 2025
    Am 06.06.2025 um 22:04 schrieb wij:
    On Fri, 2025-06-06 at 19:26 +0200, Bonita Montero wrote:
    Am 06.06.2025 um 19:24 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 06.06.2025 um 16:10 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 03.06.2025 um 20:25 schrieb Scott Lurndal:

    The fchownat() function shall be equivalent to the chown() and lchown()
    functions except in the case where path specifies a relative path. In
    this case the file to be changed is determined relative to the directory
    associated with the file descriptor fd instead of the current working
    directory. If the access mode of the open file description associated
    with the file descriptor is not O_SEARCH, the function shall check
    whether directory searches are permitted using the current permissions
    of the directory underlying the file descriptor. If the access mode is
    O_SEARCH, the function shall not perform the check.

    And why is this relevant for directory_iterator or
    recursive_directory_iterator ?

    Why are you asking this question on comp.lang.c?

    Because you can have it easier than with opendir() / readdir().

    Personally, I'd use nftw to iterate over a path.

    https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.html

    That would be much nicer with a lambda which can take the context
    of the calling function.


    That's a matter of opinion.

    It results in much less code.

    That is illusion, particularly in this case (about directory).

    I've shown the code. In C++17 iterating through a single directory and
    printing it is two lines of code.

    Most serious programs will 'invent' their own functions, even their own 'sugar syntax'...

    Not to iterate through a directory in C++.

    'sugar syntax'... result would be better than 'directory_iterator'.

    Why ?

    In general, no need for such things as 'directory_iterator' in C-library.


    In C you're forced to write ten times the code if you include error
    handling.

    Just like a lambda passed
    to std::sort() which takes context of the calling function.

    In any case, nftw is a C function and C doesn't support lamda functions.

    Lambdas without capture can be converted to C function-pointers.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From wij@3:633/280.2 to All on Sat Jun 7 21:58:01 2025
    On Sat, 2025-06-07 at 06:24 +0200, Bonita Montero wrote:
    Am 06.06.2025 um 22:04 schrieb wij:
    On Fri, 2025-06-06 at 19:26 +0200, Bonita Montero wrote:
    Am 06.06.2025 um 19:24 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 06.06.2025 um 16:10 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 03.06.2025 um 20:25 schrieb Scott Lurndal:
    =20
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The fchownat=
    () function shall be equivalent to the chown() and lchown()
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 functions ex=
    cept in the case where path specifies a relative path. In
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this case th=
    e file to be changed is determined relative to the directory
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 associated w=
    ith the file descriptor fd instead of the current working
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 directory. I=
    f the access mode of the open file description associated
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with the fil=
    e descriptor is not O_SEARCH, the function shall check
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 whether dire=
    ctory searches are permitted using the current permissions
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the direc=
    tory underlying the file descriptor. If the access mode is
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 O_SEARCH, th=
    e function shall not perform the check.
    =20
    And why is this relevant for directory_iterator or recursive_directory_iterator ?
    =20
    Why are you asking this question on comp.lang.c?
    =20
    Because you can have it easier than with opendir() / readdir(=
    ).
    =20
    Personally, I'd use nftw to iterate over a path.
    =20
    https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw=
    ..html
    =20
    That would be much nicer with a lambda which can take the context
    of the calling function.
    =20
    =20
    That's a matter of opinion.
    =20
    It results in much less code.
    =20
    That is illusion, particularly in this case (about directory).
    =20
    I've shown the code. In C++17 iterating through a single directory and printing it is two lines of code.

    C has to deal with hardware, that is all the basic (C++ and other languages=
    are
    fundamentally the same).
    There are 'tons' of details to consider, e.g. in multi-user/tasking conditi= on.

    Most serious programs will 'invent' their own functions, even their own 'sugar syntax'...
    =20
    Not to iterate through a directory in C++.
    =20
    'sugar syntax'... result would be better than 'directory_iterator'.
    =20
    Why ?

    There are many kinds of 'sub-languages' that can do any specific job better=
    ..
    As said, C is the basic. Actually, IMO, C++ could be better than C, but C++ invented 10 times more possibility of doing things wrong (because most are duplications).

    In general, no need for such things as 'directory_iterator' in C-librar=
    y.
    =20
    =20
    In C you're forced to write ten times the code if you include error
    handling.

    C++ is no better, probably worse. Firstly, the term 'exception' (and
    'vector' probably) is disabled in human mind to think about exception.
    C++ had been trying to HIDE error (exception) from its beginning, very wron=
    g
    and very unsuccessful.

    Snipet from https://sourceforge.net/projects/cscall/files/MisFiles/ClassGui= delines.txt/download
    -------- Returning error and the error checking
    Error (branching point information) not handled is always a hiden 'UB' wai= ting
    to happen. The guideline is: ALWAYS CHECK THE ERROR. This guideline extend=
    s to
    API, therefore, "__attribute__((warn_unused_result))" should be added to t=
    he
    returning Errno. As usual, exception exists.

    From function usage point of view: The general concern of error checking m=
    ay
    be the complexity and readibility of the source codes. In this guidelines'
    view, without the checking and handling of the error, the evaluation
    (readibility, beauty,..) of the codes is one-sided judgement, because erro=
    r
    checking and handling is part of the complete program or (function). The A=
    PI
    can always move the 'unwelcome' one to somewhere, but the machine sees
    everything.
    The minimum check-and-throw pattern is better than ignoration, such coding
    (throw) is equivalent to a blended cheap-and-better assert.
    Practice proves that error checking actually reduces software development = and
    maintenance time, significantly.

    Notice the term 'branching point', errors are merely branching points.
    For a progam to be shorter/simpler as desired, how many branching points ar= e=20
    handled? What is 'convenience' based on, ignorance?

    Just like a lambda passed
    to std::sort() which takes context of the calling function.
    =20
    In any case, nftw is a C function and C doesn't support lamda funct=
    ions.
    =20
    Lambdas without capture can be converted to C function-pointers.
    =20


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Sun Jun 8 02:31:35 2025
    Am 07.06.2025 um 13:58 schrieb wij:

    C++ is no better, probably worse. Firstly, the term 'exception' (and
    'vector' probably) is disabled in human mind to think about exception.

    I deal with exceptions every day and I've no problems with that. C++
    exceptions aren't that clean like Java exceptions, but still make much
    less work than C return code handling.

    C++ had been trying to HIDE error (exception) from its beginning, very wrong and very unsuccessful.

    Exceptions are the cleanest way of error handling. In most cases you
    deal with the error in a higher function and not in the leaf of the
    call graph; therefore exceptions are perfect.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From wij@3:633/280.2 to All on Sun Jun 8 04:43:25 2025
    On Sat, 2025-06-07 at 18:31 +0200, Bonita Montero wrote:
    Am 07.06.2025 um 13:58 schrieb wij:
    =20
    C++ is no better, probably worse. Firstly, the term 'exception' (and 'vector' probably) is disabled in human mind to think about exception.
    =20
    I deal with exceptions every day and I've no problems with that. C++ exceptions aren't that clean like Java exceptions, but still make much
    less work than C return code handling.

    The error from opendir(..):

    EACCES Permission denied.
    EBADF fd is not a valid file descriptor opened for reading.
    EMFILE The per-process limit on the number of open file descriptors=
    has
    been reached.
    ENFILE The system-wide limit on the total number of open files has = been
    reached.
    ENOENT Directory does not exist, or name is an empty string.
    ENOMEM Insufficient memory to complete the operation.
    ENOTDIR name is not a directory.
    ...

    Those are just common errors, there are actually more, and more from subseq= uent
    read/write/.... File operations (particularily directory) are actually very=
    nasty.

    I think your 'less work' was from simplication or idealization, lots are=
    =20
    simplified and idealized. =20
    We have no problem is because our average programs don't need to handle tho= se=20
    individual errors, but C's major task is to build OS, not average applicati= ons.

    C++ had been trying to HIDE error (exception) from its beginning, very =
    wrong
    and very unsuccessful.
    =20
    Exceptions are the cleanest way of error handling.=C2=A0

    Conditional. As said 'simplified'.

    In most cases you
    deal with the error in a higher function and not in the leaf of the
    call graph; therefore exceptions are perfect.

    If you can handle errors that way, C can also do it in much simpler way.
    The basic problem of throwing error is losing error context, it is similar
    to set a global errno (or object) and cause the program to stack unwind.

    C++ has many artificial fancy things and encourages such programming style. Good or bad? Both, but I would say mostly bad.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Sun Jun 8 05:22:49 2025
    Am 07.06.2025 um 20:43 schrieb wij:

    The error from opendir(..):

    EACCES Permission denied.
    EBADF fd is not a valid file descriptor opened for reading.
    EMFILE The per-process limit on the number of open file descriptors has
    been reached.
    ENFILE The system-wide limit on the total number of open files has been
    reached.
    ENOENT Directory does not exist, or name is an empty string.
    ENOMEM Insufficient memory to complete the operation.
    ENOTDIR name is not a directory.
    ...

    With C++ that's all encapsulated in filesystem_error which is derived
    from system_error. But you can omit permission denied errors with directory_options::skip_permission_denied. That makes sense mostly
    with recursive_directory_iterator. If you want to to that in C you've
    at least ten times the code.

    I think your 'less work' was from simplication or idealization, lots are simplified and idealized.

    No, show me your C code to iterate through a directory and I show you
    the same code with up to a fifth of C++-code. When you iterate
    recur-sively that's a tenth of the code.

    If you can handle errors that way, C can also do it in much simpler way.

    Absolutely not.

    The basic problem of throwing error is losing error context, it is similar
    to set a global errno (or object) and cause the program to stack unwind.

    The context doesn't matter. A bad_alloc doesn't need context, a
    system_error also not. And that's most of the exceptions the C++
    runtime throws (some are derived from system_error).

    C++ has many artificial fancy things and encourages such programming style. Good or bad? Both, but I would say mostly bad.

    C is bad, because you've to do simple things over and over with multiple
    times the code because there are no language-facilities to abstract your coding.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From wij@3:633/280.2 to All on Sun Jun 8 05:56:47 2025
    On Sat, 2025-06-07 at 21:22 +0200, Bonita Montero wrote:
    Am 07.06.2025 um 20:43 schrieb wij:
    =20
    The error from opendir(..):
    =20
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EACCES Permission denied. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EBADF=C2=A0 fd is not a vali=
    d file descriptor opened for reading.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EMFILE The=C2=A0 per-process=
    limit on the number of open file descriptors has
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
    =A0=C2=A0=C2=A0 been reached.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENFILE The system-wide limit=
    on the total number of open files has=C2=A0 been
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
    =A0=C2=A0=C2=A0 reached.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENOENT Directory does not ex=
    ist, or name is an empty string.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENOMEM Insufficient memory t=
    o complete the operation.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ENOTDIR name is not a direct=
    ory.
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...
    =20
    With C++ that's all encapsulated in filesystem_error which is derived
    from system_error. But you can omit permission denied errors with directory_options::skip_permission_denied. That makes sense mostly
    with recursive_directory_iterator.=C2=A0

    I see std::filesystem as evidence that C++ finally admits the deficiency of
    its advance error handling system (std::exception). But the result is worse=
    than C.
    I am not familiar with C++ std lib, I cannot say much.

    If you want to to that in C you've
    at least ten times the code.
    =20
    I think your 'less work' was from simplication or idealization, lots ar=
    e
    simplified and idealized.
    =20
    No, show me your C code to iterate through a directory and I show you
    the same code with up to a fifth of C++-code. When you iterate=20 recur-sively that's a tenth of the code.
    =20
    If you can handle errors that way, C can also do it in much simpler way=
    ..
    =20
    Absolutely not.
    =20
    The basic problem of throwing error is losing error context, it is simi=
    lar
    to set a global errno (or object) and cause the program to stack unwind=
    ..
    =20
    The context doesn't matter. A bad_alloc doesn't need context, a
    system_error also not. And that's most of the exceptions the C++
    runtime throws (some are derived from system_error).
    =20
    C++ has many artificial fancy things and encourages such programming st=
    yle.
    Good or bad? Both, but I would say mostly bad.
    =20
    C is bad, because you've to do simple things over and over with multiple times the code because there are no language-facilities to abstract your coding.

    Most of the above replies are false owing from narrow view. I'll save my explanations.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Janis Papanagnou@3:633/280.2 to All on Sun Jun 8 07:12:23 2025
    On 07.06.2025 21:22, Bonita Montero wrote:
    Am 07.06.2025 um 20:43 schrieb wij:

    The basic problem of throwing error is losing error context, [...]

    Nonsense.

    The context doesn't matter. A bad_alloc doesn't need context, a
    system_error also not. And that's most of the exceptions the C++
    runtime throws (some are derived from system_error).

    Context, in the general case, matters. It's been decades that I
    used C++, but back then in the 1990's we did pass error context
    with the thrown error object. That's an inherent part of C++'s
    exception handling. If you use standard error classes without
    context that's of course possible, but nothing prevents you to
    define yet another error class derived from some existing error
    class with additional information. You are actually free to do
    what suits you and your projects best; use rudimentary handling,
    or have a sophisticated error framework, or anything in between.

    Janis


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Sun Jun 8 07:57:12 2025
    Am 07.06.2025 um 21:56 schrieb wij:

    I see std::filesystem as evidence that C++ finally admits the deficiency of its advance error handling system (std::exception). But the result is worse than C.
    I am not familiar with C++ std lib, I cannot say much.

    LOL




    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Sun Jun 8 18:06:58 2025
    Am 07.06.2025 um 21:56 schrieb wij:

    I see std::filesystem as evidence that C++ finally admits the deficiency of its advance error handling system (std::exception). But the result is worse
    than C.

    That's just a mere assertion without any facts. In fact, exception
    handling makes error handling possible with a fraction of the code
    length, because most parts of the code don't need to handle errors,
    whereas in C they do. In C every call level has to deal with erorrs,
    whereas in C++ only one level at the upper edge has to catch the
    errors.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Muttley@DastardlyHQ.org@3:633/280.2 to All on Sun Jun 8 18:55:52 2025
    On Sun, 8 Jun 2025 10:06:58 +0200
    Bonita Montero <Bonita.Montero@gmail.com> wibbled:
    Am 07.06.2025 um 21:56 schrieb wij:

    I see std::filesystem as evidence that C++ finally admits the deficiency of >> its advance error handling system (std::exception). But the result is worse
    than C.

    That's just a mere assertion without any facts. In fact, exception
    handling makes error handling possible with a fraction of the code
    length, because most parts of the code don't need to handle errors,
    whereas in C they do. In C every call level has to deal with erorrs,
    whereas in C++ only one level at the upper edge has to catch the
    errors.

    You can of course use setjmp & longjmp in C but depending on how many levels
    up you jump they could be more trouble than they're worth. I think I've only ever used them once.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From wij@3:633/280.2 to All on Mon Jun 9 00:52:41 2025
    On Sun, 2025-06-08 at 10:06 +0200, Bonita Montero wrote:
    Am 07.06.2025 um 21:56 schrieb wij:
    =20
    I see std::filesystem as evidence that C++ finally admits the deficienc=
    y of
    its advance error handling system (std::exception). But the result is w=
    orse
    =C2=A0> than C.
    =20
    That's just a mere assertion without any facts.

    I know a bit of the development of std::filesystem. The view of mere 'stand= ard'
    disregards fact and uses more the 'assertion' criticized.

    In fact, exception
    handling makes error handling possible with a fraction of the code
    length, because most parts of the code don't need to handle errors,

    "dont' need" is illusion, errors are always there, mostly ignored and encou= raged
    to ignore by simplification.

    whereas in C they do. In C every call level has to deal with erorrs,
    whereas in C++ only one level at the upper edge has to catch the
    errors.

    C has not hard coded what 'exception' should be. E.g. C can also set an err=
    or
    object and let interested code to handle it in many ways, what's left is im= pl.
    issues.

    But, I think the 'throw' mechanism (not std::exception) is good, like many others. 'throw' is more like a soft assert failure, which is no error handl= ing.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Mon Jun 9 01:02:08 2025
    Am 08.06.2025 um 10:55 schrieb Muttley@DastardlyHQ.org:

    You can of course use setjmp & longjmp in C but depending on how many levels up you jump they could be more trouble than they're worth. I think I've only ever used them once.

    That's makes a lot of work and it's really ugly. And you need global
    jump_buf-s for that.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Mon Jun 9 01:06:44 2025
    Am 08.06.2025 um 16:52 schrieb wij:

    I know a bit of the development of std::filesystem. The view of mere 'standard'
    disregards fact and uses more the 'assertion' criticized.

    Another statement without arguments.

    "dont' need" is illusion, errors are always there, mostly ignored and encouraged
    to ignore by simplification.

    If the code is written to be exception-safe, i.e. it uses
    RAII throughout, then this is easily possible.

    C has not hard coded what 'exception' should be. E.g. C can also set an error object and let interested code to handle it in many ways, what's left is impl.
    issues.

    Are you serious? The fact that the exception type is transported along
    with the exception itself makes things really convenient. This way, the
    stack can be unrolled until the correct exception handler is found.

    But, I think the 'throw' mechanism (not std::exception) is good, like many others. 'throw' is more like a soft assert failure, which is no error handling.

    Totally different - asserts are handled at debug-time.
    Based on this statement, you didn't understand exceptions correctly.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Muttley@DastardlyHQ.org@3:633/280.2 to All on Mon Jun 9 01:08:16 2025
    On Sun, 8 Jun 2025 17:02:08 +0200
    Bonita Montero <Bonita.Montero@gmail.com> wibbled:
    Am 08.06.2025 um 10:55 schrieb Muttley@DastardlyHQ.org:

    You can of course use setjmp & longjmp in C but depending on how many levels >> up you jump they could be more trouble than they're worth. I think I've only >> ever used them once.

    That's makes a lot of work and it's really ugly. And you need global >jump_buf-s for that.

    Its no different to C++ exceptions except obviously no destructors are called so there's no chance to do a tidy up at each stack level. Also jumps arn't limited to lower to higher stack frames jumps, they can jump about all over
    the place. Whether thats useful or not I can't say. I've never needed it.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Mon Jun 9 01:11:54 2025
    Am 07.06.2025 um 23:12 schrieb Janis Papanagnou:

    Context, in the general case, matters. ...

    If you need the context then you catch the exception near where
    it is thrown; but that's not usual, meaning in most cases you
    don't need that context. F.e. when a bad_alloc is thown it dosn't
    matter which allocation failed, it's just enough to know that a
    memory-collapse happened.

    It's been decades that I used C++, but back then in the 1990's
    we did pass error context with the thrown error object.

    You can easily define your own exception object with more context
    but for 95% of all exceptions bad_alloc or system_error fit.

    That's an inherent part of C++'s exception handling. If you use
    standard error classes without context that's of course possible,
    but nothing prevents you to define yet another error class derived
    from some existing error class with additional information. You
    are actually free to do what suits you and your projects best;
    use rudimentary handling, or have a sophisticated error framework,
    or anything in between.
    Most exceptions you throw or catch are bad_allocs or system_errors.
    With that you don't need any context. For the system_error it might
    make sense to catch them nearer to the call level where the error
    occured. Usually that happens with I/O-errors. But that still
    doesn't need the context of the individual I/O-operation.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Mon Jun 9 01:18:03 2025
    Am 08.06.2025 um 17:08 schrieb Muttley@DastardlyHQ.org:

    Its no different to C++ exceptions except obviously no destructors
    are called so there's no chance to do a tidy up at each stack level.

    It's much more complicated than exceptions because the functions where
    the error raises and where the error is "caught" need shared global
    variables. C++ doesn't need that, just throw and catch and everything
    is glued to the runtime.
    And the problem with your solution is: All functions between the setjmp-
    and the longjmp-calls don't have any cleanup, i.e. they don't handle
    back their opened resources to the runtime or the kernel. With RAII in combination with exceptions that's for free.
    Do you really think setjmp() / longjmp() is a competitive solution ?
    You're naive.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From wij@3:633/280.2 to All on Mon Jun 9 02:28:34 2025
    On Sun, 2025-06-08 at 17:06 +0200, Bonita Montero wrote:
    Am 08.06.2025 um 16:52 schrieb wij:
    =20
    I know a bit of the development of std::filesystem. The view of mere 's=
    tandard'
    disregards fact and uses more the 'assertion' criticized.
    =20
    Another statement without arguments.

    My primary interest of programming is on the theory. From your presented=
    =20
    wording, I don't think you can conduct a logical discussion (it seems you continue to ask for logical proof).

    "dont' need" is illusion, errors are always there, mostly ignored and e=
    ncouraged
    to ignore by simplification.
    =20
    If the code is written to be exception-safe, i.e. it uses
    RAII throughout, then this is easily possible.
    =20
    C has not hard coded what 'exception' should be. E.g. C can also set an=
    error
    object and let interested code to handle it in many ways, what's left i=
    s impl.
    issues.
    =20
    Are you serious? The fact that the exception type is transported along
    with the exception itself makes things really convenient. This way, the
    stack can be unrolled until the correct exception handler is found.
    =20
    But, I think the 'throw' mechanism (not std::exception) is good, like m=
    any
    others. 'throw' is more like a soft assert failure, which is no error h=
    andling.
    =20
    Totally different - asserts are handled at debug-time.
    Based on this statement, you didn't understand exceptions correctly.

    It seems your whole idea (and 'fact') is based on C++'s propaganda.

    Most of the related discussion have happened in the past I am lazy to repea= t.=20
    Just look at the fact, C++ is half-dying and accelerating (IMO, not because
    of bad but of trillions ways doing it wrong).
    You are repeating past errors and think your understanding and coding is=
    =20
    orthodox enough to be factually correct.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Mon Jun 9 02:55:50 2025
    Reply-To: slp53@pacbell.net

    Muttley@DastardlyHQ.org writes:
    On Sun, 8 Jun 2025 17:02:08 +0200
    Bonita Montero <Bonita.Montero@gmail.com> wibbled:
    Am 08.06.2025 um 10:55 schrieb Muttley@DastardlyHQ.org:

    You can of course use setjmp & longjmp in C but depending on how many levels
    up you jump they could be more trouble than they're worth. I think I've only
    ever used them once.

    That's makes a lot of work and it's really ugly. And you need global >>jump_buf-s for that.

    Its no different to C++ exceptions except obviously no destructors are called >so there's no chance to do a tidy up at each stack level. Also jumps arn't >limited to lower to higher stack frames jumps, they can jump about all over >the place. Whether thats useful or not I can't say. I've never needed it.


    I've used sigsetjmp/siglongjmp in C++ code, very successfully. As an experiment a few
    years ago, I replaced it with C++ exceptions and took a 20% performance
    hit in the application. Needless to say the experiment was a failure.

    Note that the code in question[*] is performance sensitive and doesn't do dynamic resource allocations (or use STL at all), thus the fact that
    C++ unwinding will execute destructors isn't relevent to this application.

    The primary cause of the performance hit was the extra code generated
    to handle stack unwinding.

    [*] Which models a CPU, longjmp is used when an modeled CPU exception
    (memory fault, arithmetic fault, interrupt, etc) is detected
    to return to the instruction dispatch loop.

    In general, I tend to concur with wij - I prefer to handle run-of-the-mill errors when they're detected.

    For example:

    c_file_card_unit::c_file_card_unit(ulong channel, ulong unit, const char *name,
    c_logger *lp, c_card_dlp *dlp, bool punch,
    bool hollerith, const char *binpath)
    : c_card_unit(channel, unit, lp, dlp, punch)
    {
    int flags = punch?O_RDWR|O_APPEND:O_RDONLY;
    int diag;
    uint8 header[CARD_SIZE_COLUMNS];

    f_file = NULL;
    f_inputhopper = 0ul;
    f_binfd = -1;
    snprintf(f_binary_path, sizeof(f_binary_path), "%s", binpath);

    diag = stat(name, &cu_stat);
    if (diag == -1) {
    if ((errno == ENOENT) && punch) {
    flags |= O_CREAT|O_EXCL;
    }
    }

    cu_fd = open(name, flags, 0600);
    if (cu_fd == -1) {
    fprintf(stdout, "%4.4lu/%2.2lu Unable to open '%s': %s\n",
    cu_channel, cu_unit, name, strerror(errno));
    return;
    }

    diag = fcntl(cu_fd, F_SETFD, FD_CLOEXEC);
    if (diag == -1) {
    lp->log("%4.4lu/%2.2lu Unable to set FD_CLOEXEC on '%s': %s\n",
    cu_channel, cu_unit, name, strerror(errno));
    diag = close(cu_fd);
    cu_fd = -1;
    return;
    }

    ....
    }

    bool
    c_file_card_unit::is_ready(void)
    {
    return (cu_fd != -1) && ((f_file != NULL) && !feof(f_file));
    }

    So, if is_ready() returns false after the constructor runs,
    the creator of the object knows the creation failed.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Mon Jun 9 02:58:24 2025
    Reply-To: slp53@pacbell.net

    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 07.06.2025 um 23:12 schrieb Janis Papanagnou:

    Context, in the general case, matters. ...

    If you need the context then you catch the exception near where
    it is thrown; but that's not usual, meaning in most cases you
    don't need that context. F.e. when a bad_alloc is thown it dosn't
    matter which allocation failed, it's just enough to know that a >memory-collapse happened.

    Actually it very much matters where the allocation failed, if
    one wishes to recover from it. It seems your concept of error
    handling is simply reporting it (hopefully with sufficient
    context information for the user to understand what needs to
    be fixed) and calling exit().

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Mon Jun 9 03:45:47 2025
    On 2025-06-08, Scott Lurndal <scott@slp53.sl.home> wrote:
    Muttley@DastardlyHQ.org writes:
    On Sun, 8 Jun 2025 17:02:08 +0200
    Bonita Montero <Bonita.Montero@gmail.com> wibbled:
    Am 08.06.2025 um 10:55 schrieb Muttley@DastardlyHQ.org:

    You can of course use setjmp & longjmp in C but depending on how many levels
    up you jump they could be more trouble than they're worth. I think I've only
    ever used them once.

    That's makes a lot of work and it's really ugly. And you need global >>>jump_buf-s for that.

    Its no different to C++ exceptions except obviously no destructors are called >>so there's no chance to do a tidy up at each stack level. Also jumps arn't >>limited to lower to higher stack frames jumps, they can jump about all over >>the place. Whether thats useful or not I can't say. I've never needed it.


    I've used sigsetjmp/siglongjmp in C++ code, very successfully. As an experiment a few
    years ago, I replaced it with C++ exceptions and took a 20% performance
    hit in the application. Needless to say the experiment was a failure.

    setjmp and longjmp have a clearly defined implementation model
    (obviously not in ISO C, but so in implementation practice).

    Implementations of setjmp do not stray far from the paradigm of just
    saving a bunch of registers in an array, which are then 'blindly"
    restored.

    This model gives you certain performance characteristics that you can
    rely on. Both saving the state and doing the longjmp are fairly cheap.

    In C++, the tradeoffs are going to be a crapshoot: whether it is
    expensive to set up a try block, but cheap to throw, or vice versa
    and that sort of thing.

    A C++ throw typically has to search for the exit point to which control
    will be transferred. (Maybe not in some statically analyzable cases,
    like throw and catch being all in the same function.)

    In general, I tend to concur with wij - I prefer to handle run-of-the-mill errors when they're detected.

    But errors can't always be handled where they are detected. That's why,
    in the first place, you are receiving the error from the function that
    failed! That function couldn't handle it, so it tossed it upward to you.

    The alternative to exceptions is to detect errors at multiple levels
    and pass up whatever you can't handle.


    For example:

    c_file_card_unit::c_file_card_unit(ulong channel, ulong unit, const char *name,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    OK, this is a constructor.

    So, if is_ready() returns false after the constructor runs,
    the creator of the object knows the creation failed.

    Right, just like the caller of open() knows that creation
    failed, because -1 was returned.

    The error was only partially handled by c_file_card_unit in so far
    is that it ended up in a documented state, which now something
    else has to handle.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Chris M. Thomasson@3:633/280.2 to All on Mon Jun 9 04:48:45 2025
    On 6/8/2025 9:58 AM, Scott Lurndal wrote:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 07.06.2025 um 23:12 schrieb Janis Papanagnou:

    Context, in the general case, matters. ...

    If you need the context then you catch the exception near where
    it is thrown; but that's not usual, meaning in most cases you
    don't need that context. F.e. when a bad_alloc is thown it dosn't
    matter which allocation failed, it's just enough to know that a
    memory-collapse happened.

    Actually it very much matters where the allocation failed, if
    one wishes to recover from it.

    Exactly. If an allocation failed in some of my older server code, 20
    years ago for sure. Well, it would make the server go into a sort of
    "panic mode" and dump cache, dump timed out connections, ect, then it
    would try the allocation again. If that failed, it would go into shit
    hit the fan mode... ;^)


    Another fun aspect is in panic mode, instead of dumping timedout
    connections that are deemed worthy, I send them a special packet. It
    says, disconnect from me and connect to my friend server, here is the
    address and port.



    It seems your concept of error
    handling is simply reporting it (hopefully with sufficient
    context information for the user to understand what needs to
    be fixed) and calling exit().


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Mon Jun 9 06:05:59 2025
    Am 08.06.2025 um 18:28 schrieb wij:

    My primary interest of programming is on the theory. ...

    Then don't talk about practical issues.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Mon Jun 9 06:07:13 2025
    Am 08.06.2025 um 18:55 schrieb Scott Lurndal:

    I've used sigsetjmp/siglongjmp in C++ code, very successfully. As an experiment a few
    years ago, I replaced it with C++ exceptions and took a 20% performance
    hit in the application. Needless to say the experiment was a failure.

    Exceptions aren't for the regular case but for exceptions. I.e. if you
    have an I/O error or there's not enough memory. The time to handle this
    cases doesn't matter.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Mon Jun 9 06:09:07 2025
    Am 08.06.2025 um 18:58 schrieb Scott Lurndal:

    Actually it very much matters where the allocation failed, if
    one wishes to recover from it.

    This very rarely makes sense. It's almost always the case that if
    an operation fails, it doesn't matter what allocation was behind
    it.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From wij@3:633/280.2 to All on Mon Jun 9 08:51:32 2025
    On Sun, 2025-06-08 at 22:05 +0200, Bonita Montero wrote:
    Am 08.06.2025 um 18:28 schrieb wij:
    =20
    My primary interest of programming is on the theory. ...
    =20
    Then don't talk about practical issues.

    Where did I talk about theory?
    It is you who talked like you want a theoretic proof.
    (I have no problem with that except I don't think you will understand).
    And now, you cut the context off to indicate I only interested in theory (i= magination).

    Your several posts indicate that your fact is actually propaganda and rejec=
    t other=20
    facts (practice).


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From wij@3:633/280.2 to All on Mon Jun 9 09:13:34 2025
    T24gU3VuLCAyMDI1LTA2LTA4IGF0IDE2OjU1ICswMDAwLCBTY290dCBMdXJuZGFsIHdyb3RlOgo+ IAo+IEZvciBleGFtcGxlOgo+IAo+IGNfZmlsZV9jYXJkX3VuaXQ6OmNfZmlsZV9jYXJkX3VuaXQo dWxvbmcgY2hhbm5lbCwgdWxvbmcgdW5pdCwgY29uc3QgY2hhciAqbmFtZSwKPiDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCBjX2xvZ2dlciAqbHAsIGNfY2FyZF9kbHAgKmRscCwgYm9vbCBwdW5jaCwKPiDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCBib29sIGhvbGxlcml0aCwgY29uc3QgY2hhciAqYmlucGF0aCkKPiDCoMKgwqAgOiBjX2NhcmRf dW5pdChjaGFubmVsLCB1bml0LCBscCwgZGxwLCBwdW5jaCkKPiB7Cj4gwqDCoMKgIGludCBmbGFn cyA9IHB1bmNoP09fUkRXUnxPX0FQUEVORDpPX1JET05MWTsKPiDCoMKgwqAgaW50IGRpYWc7Cj4g wqDCoMKgIHVpbnQ4IGhlYWRlcltDQVJEX1NJWkVfQ09MVU1OU107Cj4gCj4gwqDCoMKgIGZfZmls ZcKgwqDCoMKgwqDCoMKgID0gTlVMTDsKPiDCoMKgwqAgZl9pbnB1dGhvcHBlciA9IDB1bDsKPiDC oMKgwqAgZl9iaW5mZMKgwqDCoMKgwqDCoCA9IC0xOwo+IMKgwqDCoCBzbnByaW50ZihmX2JpbmFy eV9wYXRoLCBzaXplb2YoZl9iaW5hcnlfcGF0aCksICIlcyIsIGJpbnBhdGgpOwo+IAo+IMKgwqDC oCBkaWFnID0gc3RhdChuYW1lLCAmY3Vfc3RhdCk7Cj4gwqDCoMKgIGlmIChkaWFnID09IC0xKSB7 Cj4gwqDCoMKgwqDCoMKgwqAgaWYgKChlcnJubyA9PSBFTk9FTlQpICYmIHB1bmNoKSB7Cj4gwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCBmbGFncyB8PSBPX0NSRUFUfE9fRVhDTDsKPiDCoMKgwqDCoMKg wqDCoCB9Cj4gwqDCoMKgIH0KPiAKPiDCoMKgwqAgY3VfZmQgPSBvcGVuKG5hbWUsIGZsYWdzLCAw NjAwKTsKPiDCoMKgwqAgaWYgKGN1X2ZkID09IC0xKSB7Cj4gwqDCoMKgwqDCoMKgwqAgZnByaW50 ZihzdGRvdXQsICIlNC40bHUvJTIuMmx1IFVuYWJsZSB0byBvcGVuICclcyc6ICVzXG4iLAo+IMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjdV9jaGFubmVsLCBjdV91bml0LCBuYW1lLCBz dHJlcnJvcihlcnJubykpOwo+IMKgwqDCoMKgwqDCoMKgIHJldHVybjsKPiDCoMKgwqAgfQo+IAo+ IMKgwqDCoCBkaWFnID0gZmNudGwoY3VfZmQsIEZfU0VURkQsIEZEX0NMT0VYRUMpOwo+IMKgwqDC oCBpZiAoZGlhZyA9PSAtMSkgewo+IMKgwqDCoMKgwqDCoMKgIGxwLT5sb2coIiU0LjRsdS8lMi4y bHUgVW5hYmxlIHRvIHNldCBGRF9DTE9FWEVDIG9uICclcyc6ICVzXG4iLAo+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBjdV9jaGFubmVsLCBjdV91bml0LCBuYW1l LCBzdHJlcnJvcihlcnJubykpOwo+IMKgwqDCoMKgwqDCoMKgIGRpYWcgPSBjbG9zZShjdV9mZCk7 Cj4gwqDCoMKgwqDCoMKgwqAgY3VfZmQgPSAtMTsKPiDCoMKgwqDCoMKgwqDCoCByZXR1cm47Cj4g wqDCoMKgIH0KPiAKPiAuLi4KPiB9CgpJIHdvdWxkIGxpa2UganVzdCBzaGFyZSBteSBjb21tZW50 IG9mIHRoZSBjb2RlIChqdXN0IHNraW0gdGhlIGNvZGUpLgogIApBc3N1bWUgY19maWxlX2NhcmRf dW5pdCguLikgaXMgYSBub3JtYWwgZnVuY3Rpb246IAoxLiBJdCBzaG91bGQgYmUgb2J2aW91cyB0 aHJvd2luZyBpcyBubyBnb29kIHRoYW4gcmV0dXJuaW5nIGVycm9yLgoyLiBFcnJvciBpcyBpc3N1 ZWQgaW4gc2V2ZXJsIHBsYWNlcywgcG9zdCBjb25kaXRpb24gaXMgYSBjb25jZXJuLgozLiBFcnJv ciBoYW5kbGluZyBpdHNlbGYgKGNvZGUgYW5kIHByb3BhZ2F0aW9uKSBoYXMgdG8gKG9yIGJldHRl ciBiZSkgZXJyb3IgZnJlZS4KNC4gQ2FuY2VsbGF0aW9uIHBvaW50L0FzeW5jLXNpZ25hbCBzYWZl IGlzc3Vlcy4gCgo+IGJvb2wKPiBjX2ZpbGVfY2FyZF91bml0Ojppc19yZWFkeSh2b2lkKQo+IHsK PiDCoMKgwqAgcmV0dXJuIChjdV9mZCAhPSAtMSkgJiYgKChmX2ZpbGUgIT0gTlVMTCkgJiYgIWZl b2YoZl9maWxlKSk7Cj4gfQo+IAo+IFNvLCBpZiBpc19yZWFkeSgpIHJldHVybnMgZmFsc2UgYWZ0 ZXIgdGhlIGNvbnN0cnVjdG9yIHJ1bnMsCj4gdGhlIGNyZWF0b3Igb2YgdGhlIG9iamVjdCBrbm93 cyB0aGUgY3JlYXRpb24gZmFpbGVkLgoKSWYgdGhlIGNvZGUgaW4gQysrIGNvbnN0cnVjdG9yLCBy ZXR1cm5pbmcgZXJyb3IgZW5jb3VudGVyZWQgaXMgbm8gZ29vZCwgJ2NvbnRyYWN0JyBpcyBicm9r ZW4uCkEgY3RvciBsaWtlIHRoaXMgc2hvdWxkIGJlIGNvbnNpZGVyZWQgdG9vIGNvbXBsaWNhdGVk IGJ1dCBmaW5lIGluIG5vbi1zZXJpb3VzIGNvZGUuCg==



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Mon Jun 9 17:59:05 2025
    On Sun, 8 Jun 2025 10:06:58 +0200, Bonita Montero wrote:

    In C every call level has to deal with erorrs, whereas in C++ only
    one level at the upper edge has to catch the errors.

    Not necessarily that simple. It might be easier if C++ had
    try/finally (like Python does), but it doesn’t.

    Here’s a patch I submitted to the Blender project some years ago to
    fix up their directory-scan code to gracefully recover from errors
    without either memory leaks or double-frees. This code is in C. It’s
    all a matter of structured programming.

    <https://projects.blender.org/blender/blender/src/commit/edf4855a38e3ee24874431f7c6321f04cb6d1b2f>

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Muttley@DastardlyHQ.org@3:633/280.2 to All on Mon Jun 9 19:20:30 2025
    On Sun, 8 Jun 2025 17:18:03 +0200
    Bonita Montero <Bonita.Montero@gmail.com> wibbled:
    Am 08.06.2025 um 17:08 schrieb Muttley@DastardlyHQ.org:

    Its no different to C++ exceptions except obviously no destructors
    are called so there's no chance to do a tidy up at each stack level.

    It's much more complicated than exceptions because the functions where
    the error raises and where the error is "caught" need shared global >variables. C++ doesn't need that, just throw and catch and everything
    is glued to the runtime.
    And the problem with your solution is: All functions between the setjmp-
    and the longjmp-calls don't have any cleanup, i.e. they don't handle
    back their opened resources to the runtime or the kernel. With RAII in >combination with exceptions that's for free.
    Do you really think setjmp() / longjmp() is a competitive solution ?
    You're naive.

    Did you actually read what I wrote? Obviously in C++ you'd use exceptions
    but in C without any kind of built in exception mechanism they're better than nothing if you want to jump out of a deep stack.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Muttley@DastardlyHQ.org@3:633/280.2 to All on Mon Jun 9 20:21:42 2025
    On Sun, 08 Jun 2025 16:55:50 GMT
    scott@slp53.sl.home (Scott Lurndal) wibbled:
    In general, I tend to concur with wij - I prefer to handle run-of-the-mill >errors when they're detected.

    Same here. I think with exceptions the clue is in the name. They should really only be used for exceptional circumstances, not as a general minor error handling mechanism.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Mon Jun 9 20:58:07 2025
    Am 09.06.2025 um 11:20 schrieb Muttley@DastardlyHQ.org:

    Did you actually read what I wrote? Obviously in C++ you'd use exceptions
    but in C without any kind of built in exception mechanism they're better
    than nothing if you want to jump out of a deep stack.
    I ask myself if setjmp() / longjmp() with manual unwinding then is
    cheaper than to just have error-returns.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Mon Jun 9 21:01:37 2025
    Am 09.06.2025 um 12:21 schrieb Muttley@DastardlyHQ.org:

    Same here. I think with exceptions the clue is in the name. They should really
    only be used for exceptional circumstances, not as a general minor error handling mechanism.

    In Java they're also used for things that are more likely. But although
    Java is significantly slower than C++, exceptions are a magnitude faster
    than in C++.
    That's while with current table-driven exception handling does need to
    find the handler for the callers return address. As shared libraries
    might be loaded and unloaded asynchronously you've to ask the kernel
    for the image of every return address, and that's slow.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Mon Jun 9 21:04:45 2025
    Am 09.06.2025 um 09:59 schrieb Lawrence D'Oliveiro:

    Not necessarily that simple. It might be easier if C++ had
    try/finally (like Python does), but it doesn’t.

    The initial thought with C++ exceptions is that all the unrolling
    happens with RAII-classe so that you don't need finally. But some-
    times you won't write a class for each resource you hold. For this
    cases a helper-class like experimental::scope_exit is very comfor-
    table. Unfortunately that's still not in the standard so that I
    had to write it on my own:

    #pragma once
    #include <utility>
    #include <concepts>
    #include "nui.h"

    template<std::invocable Fn>
    struct defer final
    {
    defer( Fn &&fn ) :
    m_enabled( true ),
    m_fn( std::forward<Fn>( fn ) )
    {
    }
    defer( defer const & ) = delete;
    void operator =( defer const & ) = delete;
    ~defer()
    {
    if( m_enabled ) [[likely]]
    m_fn();
    }
    void operator ()()
    {
    if( !m_enabled ) [[unlikely]]
    return;
    m_fn();
    m_enabled = false;
    }
    void disable()
    {
    m_enabled = false;
    }
    private:
    bool m_enabled;
    NO_UNIQUE_ADDRESS Fn m_fn;
    };

    template<std::invocable ... Fns>
    inline void disable( defer<Fns> &... defs )
    {
    (defs.disable(), ...);
    }

    template<std::invocable Fn, std::invocable FnNext = Fn>
    struct xdefer final
    {
    xdefer( Fn &&fn, xdefer<FnNext> *next = nullptr ) :
    m_enabled( true ),
    m_next( next ),
    m_fn( std::forward<Fn>( fn ) )
    {
    }
    xdefer( xdefer const & ) = delete;
    void operator =( xdefer const & ) = delete;
    ~xdefer()
    {
    bool enabled = m_enabled;
    if( m_next ) [[likely]]
    m_next->m_enabled = enabled;
    if( enabled ) [[likely]]
    m_fn();
    }
    void operator ()()
    {
    if( !m_enabled ) [[unlikely]]
    return;
    m_fn();
    m_enabled = false;
    if( !m_next ) [[unlikely]]
    return;
    m_next->m_enabled = true;
    (*m_next)();
    }
    void disable()
    {
    m_enabled = false;
    }
    private:
    template<std::invocable Fn1, std::invocable Fn2>
    friend struct xdefer;
    bool m_enabled;
    xdefer<FnNext> *m_next;
    NO_UNIQUE_ADDRESS Fn m_fn;
    };

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Tue Jun 10 00:01:25 2025
    Reply-To: slp53@pacbell.net

    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 08.06.2025 um 18:58 schrieb Scott Lurndal:

    Actually it very much matters where the allocation failed, if
    one wishes to recover from it.

    This very rarely makes sense. It's almost always the case that if
    an operation fails, it doesn't matter what allocation was behind
    it.

    Have you ever written real-world production code? Like an operating
    system, where allocation failures should -never- result in an
    inability to recover.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Tue Jun 10 01:24:28 2025
    Am 09.06.2025 um 16:01 schrieb Scott Lurndal:

    Have you ever written real-world production code? Like an operating system, where allocation failures should -never- result in an
    inability to recover.

    If you need an allocation to proceed and it fails you can't recover.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Tue Jun 10 01:53:19 2025
    Reply-To: slp53@pacbell.net

    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 09.06.2025 um 16:01 schrieb Scott Lurndal:

    Have you ever written real-world production code? Like an operating
    system, where allocation failures should -never- result in an
    inability to recover.

    If you need an allocation to proceed and it fails you can't recover.

    That's your problem caused by poor design and implementation. Exacerbated
    by the propensity for you to use C++ features that require dynamic
    allocation where other forms of data structures are more suitable.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Tue Jun 10 03:45:32 2025
    Am 09.06.2025 um 17:53 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 09.06.2025 um 16:01 schrieb Scott Lurndal:

    Have you ever written real-world production code? Like an operating
    system, where allocation failures should -never- result in an
    inability to recover.

    If you need an allocation to proceed and it fails you can't recover.

    That's your problem caused by poor design and implementation.

    That's how 100% of all programs that deal with bad_alloc are designed.

    Exacerbated by the propensity for you to use C++ features that require dynamic allocation where other forms of data structures are more suitable.

    When dynamic allocation is needed it is needed.



    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Richard Heathfield@3:633/280.2 to All on Tue Jun 10 04:22:03 2025
    On 09/06/2025 16:53, Scott Lurndal wrote:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 09.06.2025 um 16:01 schrieb Scott Lurndal:

    Have you ever written real-world production code? Like an operating
    system, where allocation failures should -never- result in an
    inability to recover.

    If you need an allocation to proceed and it fails you can't recover.

    That's your problem caused by poor design and implementation.

    To be fair, that's how the schools teach them to cut code: if you
    drop a piton, jump off the mountain.

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: Fix this later (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Tue Jun 10 04:33:38 2025
    Reply-To: slp53@pacbell.net

    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 09.06.2025 um 17:53 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 09.06.2025 um 16:01 schrieb Scott Lurndal:

    Have you ever written real-world production code? Like an operating >>>> system, where allocation failures should -never- result in an
    inability to recover.

    If you need an allocation to proceed and it fails you can't recover.

    That's your problem caused by poor design and implementation.

    That's how 100% of all programs that deal with bad_alloc are designed.

    Exacerbated by the propensity for you to use C++ features that require
    dynamic allocation where other forms of data structures are more suitable.

    When dynamic allocation is needed it is needed.

    And there are many ways to handle it that don't include throwing
    bad_alloc when the system is unable to provide additional address
    space, memory or backing store.

    Allocating major data structures at application start (perhaps using a
    pool allocator) and crafting your algorithms such that they
    don't require infinite memory is a good start.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Tue Jun 10 04:39:17 2025
    Am 09.06.2025 um 20:33 schrieb Scott Lurndal:

    And there are many ways to handle it that don't include throwing
    bad_alloc when the system is unable to provide additional address
    space, memory or backing store.

    These ways are all less comfortable than bad_alloc.

    Allocating major data structures at application start (perhaps using
    a pool allocator) and crafting your algorithms such that they
    don't require infinite memory is a good start.

    With modern allocators like mimalloc allocation is that fast that
    you mostly can't compete with your own pools.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Tim Rentsch@3:633/280.2 to All on Tue Jun 10 11:59:27 2025
    scott@slp53.sl.home (Scott Lurndal) writes:

    Bonita Montero <Bonita.Montero@gmail.com> writes:

    Am 08.06.2025 um 18:58 schrieb Scott Lurndal:

    Actually it very much matters where the allocation failed, if
    one wishes to recover from it.

    This very rarely makes sense. It's almost always the case that if
    an operation fails, it doesn't matter what allocation was behind
    it.

    Have you ever written real-world production code? Like an operating system, where allocation failures should -never- result in an
    inability to recover.

    You're talking to someone who can't understand the difference
    between comp.lang.c and comp.lang.c++. What do you expect?

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Muttley@DastardlyHQ.org@3:633/280.2 to All on Tue Jun 10 17:21:32 2025
    On Mon, 09 Jun 2025 18:33:38 GMT
    scott@slp53.sl.home (Scott Lurndal) wibbled:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 09.06.2025 um 17:53 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 09.06.2025 um 16:01 schrieb Scott Lurndal:

    Have you ever written real-world production code? Like an operating >>>>> system, where allocation failures should -never- result in an
    inability to recover.

    If you need an allocation to proceed and it fails you can't recover.

    That's your problem caused by poor design and implementation.

    That's how 100% of all programs that deal with bad_alloc are designed.

    Exacerbated by the propensity for you to use C++ features that require
    dynamic allocation where other forms of data structures are more suitable. >>
    When dynamic allocation is needed it is needed.

    And there are many ways to handle it that don't include throwing
    bad_alloc when the system is unable to provide additional address
    space, memory or backing store.

    Allocating major data structures at application start (perhaps using a
    pool allocator) and crafting your algorithms such that they
    don't require infinite memory is a good start.

    Ugh. Then you end up like the Java JVM - grabbing boatloads of memory that causes huge startup delays and can often cause the machine to do lots of swapping and/or slow everything else down to treacle.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Tue Jun 10 17:51:12 2025
    Am 10.06.2025 um 03:59 schrieb Tim Rentsch:

    You're talking to someone who can't understand the difference
    between comp.lang.c and comp.lang.c++. What do you expect?

    Comparisons between C and any other lanugage are on-topic here. ;-)

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Tim Rentsch@3:633/280.2 to All on Tue Jun 10 20:21:52 2025
    Kaz Kylheku <643-408-1753@kylheku.com> writes:

    On 2025-06-08, Scott Lurndal <scott@slp53.sl.home> wrote:

    Muttley@DastardlyHQ.org writes:

    On Sun, 8 Jun 2025 17:02:08 +0200
    Bonita Montero <Bonita.Montero@gmail.com> wibbled:

    Am 08.06.2025 um 10:55 schrieb Muttley@DastardlyHQ.org:

    You can of course use setjmp & longjmp in C but depending on how
    many levels up you jump they could be more trouble than they're
    worth. I think I've only ever used them once.

    That's makes a lot of work and it's really ugly. And you need
    global jump_buf-s for that.

    Nonsense.

    [...]

    setjmp and longjmp have a clearly defined implementation model
    (obviously not in ISO C, but so in implementation practice).

    What I think you mean is that setjmp/longjmp have a natural and
    straightforward implementation strategy that works on many
    hardware platforms and in many C implementations. That strategy
    is not ubiquitous, and TTBOMK is not defined anywhere except
    implicitly by the code that implements it. Described perhaps,
    but that isn't the same as a definition.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Tue Jun 10 22:07:40 2025
    Am 03.06.2025 um 02:37 schrieb Lawrence D'Oliveiro:
    On Mon, 2 Jun 2025 09:35:24 +0200, Bonita Montero wrote:

    Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:

    On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:

    Sth. like this:

    for( directory_entry const &de : recursive_directory_iterator( "\\", >>>> directory_options::follow_directory_symlink ) )
    cout << de.path() << endl;

    You need the dirfd functions to avoid certain potential security
    holes on operations with symlinks.

    Which security holes ?

    TOCTOU.

    That's unavoidable with directory-operations. The file might have been
    changed or deleted as you process a directory entry. Unfortunately there
    are no really transactional filesystems, although they would be only
    a bit slower.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Tue Jun 10 23:19:24 2025
    Reply-To: slp53@pacbell.net

    Muttley@DastardlyHQ.org writes:
    On Mon, 09 Jun 2025 18:33:38 GMT
    scott@slp53.sl.home (Scott Lurndal) wibbled:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 09.06.2025 um 17:53 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 09.06.2025 um 16:01 schrieb Scott Lurndal:

    Have you ever written real-world production code? Like an operating >>>>>> system, where allocation failures should -never- result in an
    inability to recover.

    If you need an allocation to proceed and it fails you can't recover.

    That's your problem caused by poor design and implementation.

    That's how 100% of all programs that deal with bad_alloc are designed.

    Exacerbated by the propensity for you to use C++ features that require >>>> dynamic allocation where other forms of data structures are more suitable. >>>
    When dynamic allocation is needed it is needed.

    And there are many ways to handle it that don't include throwing
    bad_alloc when the system is unable to provide additional address
    space, memory or backing store.

    Allocating major data structures at application start (perhaps using a
    pool allocator) and crafting your algorithms such that they
    don't require infinite memory is a good start.

    Ugh. Then you end up like the Java JVM - grabbing boatloads of memory that >causes huge startup delays and can often cause the machine to do lots of >swapping and/or slow everything else down to treacle.

    That's a problem with host not being suitable for java, if that
    is the behavior you are seeing. I've not seen that in production
    java-based applications that are competently developed.

    For C/C++, one generally allocates page-aligned regions with mmap, eschewing granular allocation methods such as new/delete/malloc.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Tim Rentsch@3:633/280.2 to All on Wed Jun 11 00:18:50 2025
    scott@slp53.sl.home (Scott Lurndal) writes:

    [...]

    And all the existing C compilers in the entire planet support
    the C90 dialect[*], if so instructed. Where is the problem?

    It is common to use the word "dialect" when talking about
    different editions of the C standard, but actually it isn't
    right. The word "dialect" comes from linguistics, and it
    has a particular meaning that does not apply in this case.
    My understanding of the terminology used in linguistics is
    that C90, C99, C11, and so forth, should be referred to
    as "varieties" of the C language, in much the same way
    that American English and British English and Indian
    English are all different varieties (rather than dialects)
    of English.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Wed Jun 11 00:36:04 2025
    Reply-To: slp53@pacbell.net

    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 03.06.2025 um 02:37 schrieb Lawrence D'Oliveiro:
    On Mon, 2 Jun 2025 09:35:24 +0200, Bonita Montero wrote:

    Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:

    On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:

    Sth. like this:

    for( directory_entry const &de : recursive_directory_iterator( "\\", >>>>> directory_options::follow_directory_symlink ) )
    cout << de.path() << endl;

    You need the dirfd functions to avoid certain potential security
    holes on operations with symlinks.

    Which security holes ?

    TOCTOU.

    That's unavoidable with directory-operations.

    Incorrect. The entire purpose of the POSIX *at functions are to close
    those security holes.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Wed Jun 11 00:40:28 2025
    Am 10.06.2025 um 16:36 schrieb Scott Lurndal:

    That's unavoidable with directory-operations.

    Incorrect. The entire purpose of the POSIX *at functions are to close
    those security holes.

    You confirm me and say I'm incorrect incorrect - in the same sentence ?


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Muttley@DastardlyHQ.org@3:633/280.2 to All on Wed Jun 11 00:46:28 2025
    On Tue, 10 Jun 2025 13:19:24 GMT
    scott@slp53.sl.home (Scott Lurndal) wibbled:
    Muttley@DastardlyHQ.org writes:
    Ugh. Then you end up like the Java JVM - grabbing boatloads of memory that >>causes huge startup delays and can often cause the machine to do lots of >>swapping and/or slow everything else down to treacle.

    That's a problem with host not being suitable for java, if that
    is the behavior you are seeing. I've not seen that in production
    java-based applications that are competently developed.

    For C/C++, one generally allocates page-aligned regions with mmap, eschewing >granular allocation methods such as new/delete/malloc.

    No, one generally doesn't. Why on earth would anyone bother with their own
    low level memory allocation based on pages unless they were writing something like a database? Plus I'm sure most modern implementations of malloc() are sophisticated enough not to just allocate random blocks of memory but have their own pool behind the scenes which they manage.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Tim Rentsch@3:633/280.2 to All on Wed Jun 11 01:52:50 2025
    Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

    Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

    Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

    Richard Harnden <richard.harnden@gmail.invalid> writes:

    On 22/05/2025 23:32, Keith Thompson wrote:

    [...]

    In one of your library's headers:
    extern const char ESCAPE;
    In the corresponding *.c file:
    const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
    Change the name if you prefer.

    Wouldn't that be a reserved identifier?

    Yes, it would. Good catch.

    (Identifiers starting with E followed by either a digit or an
    uppercase letter are reserved; they could be defined as macros
    in <errno.h>.)

    They are reserved only as macros, and only if <errno.h> has
    been #include'd.

    For this particular use, it's easy to make the definition work,
    simply by adding

    #undef ESCAPE

    before the declaration in the header file, and before the
    definition in the source file (assuming of course that if
    there are any #include <errno.h> they precede the #undef's).

    It would be even easier to pick a different name.

    The point of my comment was to help explain the rules about what
    macro names are reserved and under what circumstances, not to
    suggest a way to avoid conflicts.

    A better way to avoid conflicts with E* macros is to take functions
    where errno is needed, as for example signal(), and not call them
    directly but rather wrap each one in a function, with the wrapping
    functions put in (one or more) separate translation unit(s). Those
    translation units, and only those translation units, are the ones
    where a #include <errno.h> is done. Some details are needed to keep
    the separation complete, but I think those aren't too hard to work
    out, so if someone has trouble please ask. This way most of the
    program can use names beginning with E that might otherwise be
    reserved, without any fear of conflicts. There is a bit of source
    code overhead, but that is paid only once, across all projects that
    use this approach. Also there are some other benefits, related to
    libraries used that are not part of ISO C, such as Posix, which
    again should be readily apparent to anyone used to working in large
    projects that use such libraries.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Wed Jun 11 02:52:11 2025
    On 2025-06-10, Scott Lurndal <scott@slp53.sl.home> wrote:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 03.06.2025 um 02:37 schrieb Lawrence D'Oliveiro:
    On Mon, 2 Jun 2025 09:35:24 +0200, Bonita Montero wrote:

    Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:

    On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:

    Sth. like this:

    for( directory_entry const &de : recursive_directory_iterator( "\\", >>>>>> directory_options::follow_directory_symlink ) )
    cout << de.path() << endl;

    You need the dirfd functions to avoid certain potential security
    holes on operations with symlinks.

    Which security holes ?

    TOCTOU.

    That's unavoidable with directory-operations.

    Incorrect. The entire purpose of the POSIX *at functions are to close
    those security holes.

    Simply by using a path coming from an untrusted input, you have
    a securty problem that no POSIX function addresses.

    I seem to recall that the "at" functions are mainly motivated by multithreading.

    A process has a single working directory, inherited from a time before
    threads. The "at" function can be used to defensively code file system
    access in a thread, even if there is code in the process which uses
    chdir.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Chris M. Thomasson@3:633/280.2 to All on Wed Jun 11 05:08:40 2025
    On 6/10/2025 6:19 AM, Scott Lurndal wrote:
    Muttley@DastardlyHQ.org writes:
    On Mon, 09 Jun 2025 18:33:38 GMT
    scott@slp53.sl.home (Scott Lurndal) wibbled:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 09.06.2025 um 17:53 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 09.06.2025 um 16:01 schrieb Scott Lurndal:

    Have you ever written real-world production code? Like an operating >>>>>>> system, where allocation failures should -never- result in an
    inability to recover.

    If you need an allocation to proceed and it fails you can't recover. >>>>>
    That's your problem caused by poor design and implementation.

    That's how 100% of all programs that deal with bad_alloc are designed. >>>>
    Exacerbated by the propensity for you to use C++ features that require >>>>> dynamic allocation where other forms of data structures are more suitable.

    When dynamic allocation is needed it is needed.

    And there are many ways to handle it that don't include throwing
    bad_alloc when the system is unable to provide additional address
    space, memory or backing store.

    Allocating major data structures at application start (perhaps using a
    pool allocator) and crafting your algorithms such that they
    don't require infinite memory is a good start.

    Ugh. Then you end up like the Java JVM - grabbing boatloads of memory that >> causes huge startup delays and can often cause the machine to do lots of
    swapping and/or slow everything else down to treacle.

    That's a problem with host not being suitable for java, if that
    is the behavior you are seeing. I've not seen that in production
    java-based applications that are competently developed.

    For C/C++, one generally allocates page-aligned regions with mmap, eschewing granular allocation methods such as new/delete/malloc.

    Humm... However, one can choose to carve out allocations from the
    region? Actually, this basically reminds me of my older region allocator
    code. So, this is basically dynamic within our defined region, so to
    speak. However, back in the day, I would try to recover from dynamic
    malloc failures... Just for testing the robustness of my system. Fwiw,
    here is my old region code:

    https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ

    If it fails to allocate, it simply means the region is exhausted at that
    time. Then my code can fall back to dumping connections, freeing cache,
    and try the allocation again? Fair enough? It was a long time ago, and
    when I was conducting said experiments. Fwiw, here is a direct link to
    my old region code that is, well, fun to me at least... :^)

    https://pastebin.com/raw/f37a23918

    Does it still work for anybody? ;^o

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Waldek Hebisch@3:633/280.2 to All on Wed Jun 11 06:22:29 2025
    Scott Lurndal <scott@slp53.sl.home> wrote:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 09.06.2025 um 17:53 schrieb Scott Lurndal:
    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 09.06.2025 um 16:01 schrieb Scott Lurndal:

    Have you ever written real-world production code? Like an operating >>>>> system, where allocation failures should -never- result in an
    inability to recover.

    If you need an allocation to proceed and it fails you can't recover.

    That's your problem caused by poor design and implementation.

    That's how 100% of all programs that deal with bad_alloc are designed.

    Exacerbated by the propensity for you to use C++ features that require
    dynamic allocation where other forms of data structures are more suitable. >>
    When dynamic allocation is needed it is needed.

    And there are many ways to handle it that don't include throwing
    bad_alloc when the system is unable to provide additional address
    space, memory or backing store.

    Allocating major data structures at application start (perhaps using a
    pool allocator) and crafting your algorithms such that they
    don't require infinite memory is a good start.

    If you can allocate memory before looking at data, then you really
    do not need dynamic allocation. And there are cases when you can
    do with something simpler than general dynamic allocation.

    But AFAICS there are cases which need general dynamic allocation.
    And there are cases which strictly speaking do not need general
    dynamic allocation, but dynamic allocation looks better in
    practice. Namely, one can estimate amount of memory that is
    sufficient to do the job, but this estimate is typically
    significantly bigger than amount of memory which would be
    dynamically allocated. In other words, users prefer
    "stochastic" version, that is program which usually is
    efficient, but with low probability may fail or require more
    resources to a "deterministic" program that always
    require more resources.

    There are now in use programs that solve high complexity
    problems. On many practical problems they are quite
    efficient, but by the nature of problem they need
    inpracticaly large resources on some instances. For
    such problem the best one can hope is to localize the
    trouble, that is fail the computation if it requires
    to much, but keep independent things running. And even
    such localized failure may be tricky (that is avoiding
    trouble in unrelated places).

    --
    Waldek Hebisch

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: To protect and to server (3:633/280.2@fidonet)
  • From Keith Thompson@3:633/280.2 to All on Wed Jun 11 06:35:19 2025
    Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
    Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
    Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
    Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
    Richard Harnden <richard.harnden@gmail.invalid> writes:
    On 22/05/2025 23:32, Keith Thompson wrote:
    [...]

    In one of your library's headers:
    extern const char ESCAPE;
    In the corresponding *.c file:
    const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
    Change the name if you prefer.

    Wouldn't that be a reserved identifier?

    Yes, it would. Good catch.

    (Identifiers starting with E followed by either a digit or an
    uppercase letter are reserved; they could be defined as macros
    in <errno.h>.)

    They are reserved only as macros, and only if <errno.h> has
    been #include'd.

    For this particular use, it's easy to make the definition work,
    simply by adding

    #undef ESCAPE

    before the declaration in the header file, and before the
    definition in the source file (assuming of course that if
    there are any #include <errno.h> they precede the #undef's).

    It would be even easier to pick a different name.

    The point of my comment was to help explain the rules about what
    macro names are reserved and under what circumstances, not to
    suggest a way to avoid conflicts.

    And the point of my comment was to suggest a way to avoid conflicts.

    A better way to avoid conflicts with E* macros is to take functions
    where errno is needed, as for example signal(), and not call them
    directly but rather wrap each one in a function, with the wrapping
    functions put in (one or more) separate translation unit(s). Those translation units, and only those translation units, are the ones
    where a #include <errno.h> is done. Some details are needed to keep
    the separation complete, but I think those aren't too hard to work
    out, so if someone has trouble please ask. This way most of the
    program can use names beginning with E that might otherwise be
    reserved, without any fear of conflicts. There is a bit of source
    code overhead, but that is paid only once, across all projects that
    use this approach. Also there are some other benefits, related to
    libraries used that are not part of ISO C, such as Posix, which
    again should be readily apparent to anyone used to working in large
    projects that use such libraries.

    That doesn't strike me as better. You're suggesting a substantial reorganization to avoid some simple name conflicts (identifiers
    starting with 'E'). I find it much easier -- and yes, better --
    to avoid defining identifiers starting with 'E'. (Actually only
    identifiers starting with 'E' followed by either a digit or an
    uppercase letter are reserved. It's simpler to avoid all identifiers
    starting with 'E', but you can safely use something like "Escape"
    if you like.)

    If there are other reasons for such an organization, that's fine.

    (My personal policy is to assume a more expansive set of reserved
    identifiers, because it means I only have to remember a simpler
    set of rules. For example, I find it easier to avoid defining any
    identifiers starting with '_' than to account for the rules for which
    _* identifiers are reserved for which purposes in which contexts.
    Of course I'll look up and apply the actual rules when I need to.)

    I find the reservation of potential errno macro names annoying.
    Using and reserving identifiers starting with "E_", for example,
    would have been less intrusive. But we're stuck with it.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    void Void(void) { Void(); } /* The recursive call of the void */

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: None to speak of (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Wed Jun 11 07:34:23 2025
    On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    I find the reservation of potential errno macro names annoying.

    If the standard contained /no/ statements about what a given header
    file may reserve, then /any/ identifier whatsoever would be a potential
    clash.

    The errno reservation is kind of good because implementors often extend
    the set of errno constants. POSIX has a lot more of them than ISO C, and
    there are some vendor-specific ones.

    Anyway, you can safely ignore the reservation theatre, and just
    deal with clashes that happen, when they happen. (If you're lucky,
    that could just be never).

    Anyway, ISO C, POSIX and vendors have historically introduced new
    identifiers in spaces that were not previously declared as reserved.
    If you're ever hit by that, you will feel like a completel sucker if
    you've religiously adhered to namespaces from your end.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Keith Thompson@3:633/280.2 to All on Wed Jun 11 08:09:44 2025
    Kaz Kylheku <643-408-1753@kylheku.com> writes:
    On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    I find the reservation of potential errno macro names annoying.

    If the standard contained /no/ statements about what a given header
    file may reserve, then /any/ identifier whatsoever would be a potential clash.

    The errno reservation is kind of good because implementors often extend
    the set of errno constants. POSIX has a lot more of them than ISO C, and there are some vendor-specific ones.

    Anyway, you can safely ignore the reservation theatre, and just
    deal with clashes that happen, when they happen. (If you're lucky,
    that could just be never).

    You can do that, but a new clash could happen when your code is
    compiled on a system that defines an errno macro that you haven't
    seen before.

    Anyway, ISO C, POSIX and vendors have historically introduced new
    identifiers in spaces that were not previously declared as reserved.
    If you're ever hit by that, you will feel like a completel sucker if
    you've religiously adhered to namespaces from your end.

    Yes, that can happen, but no, I won't feel like a complete sucker.

    If I define my own strfoo() function and a new edition of the standard
    defines strfoo() in <string.h>, the clash is my fault,and I could have
    avoided it by defining str_foo().

    Nothing can prevent all possible name clashes, but I like to follow the
    rules in the standard that let me prevent some of them.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    void Void(void) { Void(); } /* The recursive call of the void */

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: None to speak of (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Wed Jun 11 09:33:08 2025
    On Tue, 10 Jun 2025 14:07:40 +0200, Bonita Montero wrote:

    Am 03.06.2025 um 02:37 schrieb Lawrence D'Oliveiro:

    On Mon, 2 Jun 2025 09:35:24 +0200, Bonita Montero wrote:

    Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro:

    On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote:

    Sth. like this:

    for( directory_entry const &de : recursive_directory_iterator( "\
    \",
    directory_options::follow_directory_symlink ) )
    cout << de.path() << endl;

    You need the dirfd functions to avoid certain potential security
    holes on operations with symlinks.

    Which security holes ?

    TOCTOU.

    That's unavoidable with directory-operations.

    No it isn’t. That’s why we have the fd-based calls in recent POSIX, and in Linux. That plugs the holes, and makes it possible to implement privileged file-access software like Samba securely.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Wed Jun 11 11:16:11 2025
    On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    Kaz Kylheku <643-408-1753@kylheku.com> writes:
    On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    I find the reservation of potential errno macro names annoying.

    If the standard contained /no/ statements about what a given header
    file may reserve, then /any/ identifier whatsoever would be a potential
    clash.

    The errno reservation is kind of good because implementors often extend
    the set of errno constants. POSIX has a lot more of them than ISO C, and
    there are some vendor-specific ones.

    Anyway, you can safely ignore the reservation theatre, and just
    deal with clashes that happen, when they happen. (If you're lucky,
    that could just be never).

    You can do that, but a new clash could happen when your code is
    compiled on a system that defines an errno macro that you haven't
    seen before.

    A new CRASH could happen too, and any number of things.

    This clash would be literally one of the first roadblocks, if not the
    first one, that we would see when just exploring the possibility whether
    our code might not run on that system.

    At that point we could be months away from declaring that a supported
    platform.


    Anyway, ISO C, POSIX and vendors have historically introduced new
    identifiers in spaces that were not previously declared as reserved.
    If you're ever hit by that, you will feel like a completel sucker if
    you've religiously adhered to namespaces from your end.

    Yes, that can happen, but no, I won't feel like a complete sucker.

    If I define my own strfoo() function and a new edition of the standard defines strfoo() in <string.h>, the clash is my fault,and I could have avoided it by defining str_foo().

    But, my point is, that maybe you could have called it kidneybeans() and
    still have a clash.

    In fact, if you are writing new string functions that are the same sort
    of stuff like the standard ones, you should use the str prefix,
    for consistency.

    If your code is influential enough, they might be standardized one
    day---and then they are ready with the proper naming, so early adopters
    of your functions won't have to change anything; just in their build
    system drop the third party code and switch to what their library now
    provides.


    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Keith Thompson@3:633/280.2 to All on Wed Jun 11 12:11:09 2025
    Kaz Kylheku <643-408-1753@kylheku.com> writes:
    On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    Kaz Kylheku <643-408-1753@kylheku.com> writes:
    On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    I find the reservation of potential errno macro names annoying.

    If the standard contained /no/ statements about what a given header
    file may reserve, then /any/ identifier whatsoever would be a potential
    clash.

    The errno reservation is kind of good because implementors often extend
    the set of errno constants. POSIX has a lot more of them than ISO C, and >>> there are some vendor-specific ones.

    Anyway, you can safely ignore the reservation theatre, and just
    deal with clashes that happen, when they happen. (If you're lucky,
    that could just be never).

    You can do that, but a new clash could happen when your code is
    compiled on a system that defines an errno macro that you haven't
    seen before.

    A new CRASH could happen too, and any number of things.

    Sure, but a compilation failure is more likely.

    This clash would be literally one of the first roadblocks, if not the
    first one, that we would see when just exploring the possibility whether
    our code might not run on that system.

    At that point we could be months away from declaring that a supported platform.

    Sure, but why not skip that first roadblock?

    Anyway, ISO C, POSIX and vendors have historically introduced new
    identifiers in spaces that were not previously declared as reserved.
    If you're ever hit by that, you will feel like a completel sucker if
    you've religiously adhered to namespaces from your end.

    Yes, that can happen, but no, I won't feel like a complete sucker.

    If I define my own strfoo() function and a new edition of the standard
    defines strfoo() in <string.h>, the clash is my fault,and I could have
    avoided it by defining str_foo().

    But, my point is, that maybe you could have called it kidneybeans() and
    still have a clash.

    Certainly, I've already acknowledged that.

    But surely an identifier that the standard says is reserved is less
    likely to cause a clash than one that isn't.

    In fact, if you are writing new string functions that are the same sort
    of stuff like the standard ones, you should use the str prefix,
    for consistency.

    If your code is influential enough, they might be standardized one
    day---and then they are ready with the proper naming, so early adopters
    of your functions won't have to change anything; just in their build
    system drop the third party code and switch to what their library now provides.

    I see your point, but ... meh. To me, a name matching "str[a-z]*"
    fairly strongly suggests a function declared in <string.h> in ISO C.
    Of course it's not an absolute rule; see strlcpy(), for example
    (which is now part of POSIX).

    Even a str*() identifier that never clashes with ISO C's <string.h>
    can still clash with POSIX, or glibc, or BSD, or ....

    I would have been happier if POSIX were less intrusive on the
    C standard library, but the way C and POSIX evolved didn't make
    that feasible.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    void Void(void) { Void(); } /* The recursive call of the void */

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: None to speak of (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Wed Jun 11 15:07:37 2025
    Am 11.06.2025 um 01:33 schrieb Lawrence D'Oliveiro:

    No it isn’t. That’s why we have the fd-based calls in recent POSIX, and in
    Linux. That plugs the holes, and makes it possible to implement privileged file-access software like Samba securely.

    opendir() and readdir() hasn't changed for decades.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Wed Jun 11 15:34:59 2025
    On Wed, 11 Jun 2025 07:07:37 +0200, Bonita Montero wrote:

    Am 11.06.2025 um 01:33 schrieb Lawrence D'Oliveiro:

    No it isn’t. That’s why we have the fd-based calls in recent POSIX, and >> in Linux. That plugs the holes, and makes it possible to implement
    privileged file-access software like Samba securely.

    opendir() and readdir() hasn't changed for decades.

    And they are not enough.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Scott Lurndal@3:633/280.2 to All on Wed Jun 11 23:41:11 2025
    Reply-To: slp53@pacbell.net

    Bonita Montero <Bonita.Montero@gmail.com> writes:
    Am 11.06.2025 um 01:33 schrieb Lawrence D'Oliveiro:

    No it isn’t. That’s why we have the fd-based calls in recent POSIX, and in
    Linux. That plugs the holes, and makes it possible to implement privileged >> file-access software like Samba securely.

    opendir() and readdir() hasn't changed for decades.


    That turns out to not be true. fdopendir(3) was added in Issue
    7 of the Single Unix Specification (aka POSIX).

    https://pubs.opengroup.org/onlinepubs/9799919799/functions/fdopendir.html

    ftw(3)/nftw(3) are used more often than opendir(3) in real world code.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: UsenetServer - www.usenetserver.com (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Thu Jun 12 01:23:16 2025
    On 2025-06-11, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    Kaz Kylheku <643-408-1753@kylheku.com> writes:
    On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    Kaz Kylheku <643-408-1753@kylheku.com> writes:
    On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    I find the reservation of potential errno macro names annoying.

    If the standard contained /no/ statements about what a given header
    file may reserve, then /any/ identifier whatsoever would be a potential >>>> clash.

    The errno reservation is kind of good because implementors often extend >>>> the set of errno constants. POSIX has a lot more of them than ISO C, and >>>> there are some vendor-specific ones.

    Anyway, you can safely ignore the reservation theatre, and just
    deal with clashes that happen, when they happen. (If you're lucky,
    that could just be never).

    You can do that, but a new clash could happen when your code is
    compiled on a system that defines an errno macro that you haven't
    seen before.

    A new CRASH could happen too, and any number of things.

    Sure, but a compilation failure is more likely.

    This clash would be literally one of the first roadblocks, if not the
    first one, that we would see when just exploring the possibility whether
    our code might not run on that system.

    At that point we could be months away from declaring that a supported
    platform.

    Sure, but why not skip that first roadblock?

    Because:

    1. The roadblock is not a sure thing; in fact it is improbable.

    2. The severity/impact is trivial.

    3. There are dowsides to skipping it:

    - tiny amount of effort, which occurs with 100% probability.

    - giving up a desired name.

    Anyway, ISO C, POSIX and vendors have historically introduced new
    identifiers in spaces that were not previously declared as reserved.
    If you're ever hit by that, you will feel like a completel sucker if
    you've religiously adhered to namespaces from your end.

    Yes, that can happen, but no, I won't feel like a complete sucker.

    If I define my own strfoo() function and a new edition of the standard
    defines strfoo() in <string.h>, the clash is my fault,and I could have
    avoided it by defining str_foo().

    But, my point is, that maybe you could have called it kidneybeans() and
    still have a clash.

    Certainly, I've already acknowledged that.

    But surely an identifier that the standard says is reserved is less
    likely to cause a clash than one that isn't.

    The probabilities are not precisely quantified, but low.

    The probability that your #define ELMER_FUDD will clash with something
    out of <errno.h> is vanishingly low, as is the probability that #define BUGS_BUNNY will clash with something in spite of not intruding into
    a reserved namespace.

    We have no way to quantitfy the probabilities, and they are so low that
    even if one could be determined to be 100 times the other, why
    prioritize the concern over that difference over any other naming consideration? (Like that maybe Looney Tunes characters aren't very good

    In fact, if you are writing new string functions that are the same sort
    of stuff like the standard ones, you should use the str prefix,
    for consistency.

    If your code is influential enough, they might be standardized one
    day---and then they are ready with the proper naming, so early adopters
    of your functions won't have to change anything; just in their build
    system drop the third party code and switch to what their library now
    provides.

    I see your point, but ... meh. To me, a name matching "str[a-z]*"
    fairly strongly suggests a function declared in <string.h> in ISO C.
    Of course it's not an absolute rule; see strlcpy(), for example
    (which is now part of POSIX).

    Note that the guys who made strlcpy did (almost) exactly what I say
    above. They deliberately introduced the function into that namespace,
    which made it more nicely 'standardizable". I say almost because they
    are systems implementors working on OpenBSD, and so they are using the namespace as designed. However, the use of those functions spread beyond OpenBSD; application codebases started defining those for themselves.

    Even a str*() identifier that never clashes with ISO C's <string.h>
    can still clash with POSIX, or glibc, or BSD, or ....

    I would have been happier if POSIX were less intrusive on the
    C standard library, but the way C and POSIX evolved didn't make
    that feasible.

    But POSIX has to use *some* kind of names. No matter what you call a
    function, it's going to start with either an underscore, or an upper or
    lower case letter. So if it doesn't intrude into the _* space, it will
    intrude into a*. Or else if not into that one, then b*, ... and so on. Everything is in some space, and could step on something in an
    application.

    Religiously sticking to certain spaces can uglify the API. Imagine
    everything newer than 1990 in POSIX were called posix_<something>.
    Yuck! (The whole pthread_* thing is actually curious that way).

    Namespaces offer a solution. They are not available in C, and in many
    ways are a solution in search of a problem.

    It's amazing how far C development is going, into code bases of millions
    of lines and even orders of magnitude more, without a package system.

    What helps is that there are no clashes between:

    - static symbols in separate translation units.
    - symbols in separate programs
    - unexported symbols among shared libraries

    It's also amazing how just even a small naming convention reduces
    the occurrences of clashes. E.g. four letter prefix of your company's
    acronym, and you're mostly good. Writing code for Broadcom? Just
    call things brcm_*.

    Speaking of POSIX, again, if you use ALL_CAPS variable names in shell
    scripts, Makefiles, or your environment you are in treading in reserved namespace! Yet everyone deos this all the time and the sky does not
    fall.

    Just because POSIX says that it will not define lower-cased environment varaibles doesn't mean everyone should rush to define their own
    variables there.

    The "user" and "vendor" roles can be fluid. You might define a
    lower cased environment variable, thinking you are a user, in order not
    to clash with vendors. Next thing you know, you have users who are
    buying a complete system solution for you, including your app with
    lower-cased environment variables. You're now "vendor" and doing it
    wrong.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Thu Jun 12 01:32:06 2025
    On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    I find the reservation of potential errno macro names annoying.

    Perhaps more annoying is the idea that all _t typedef names are reserved
    by POSIX.

    But, you have to look at it from a different point of view. POSIX
    essentially says that when it introduces types names, they will stick a
    _t suffix on them. I.e. that they will conform with a common practice.
    This is good! We want that!

    That doesn't mean everyone should panic and abandon the same good
    practice.

    Suppose two computer philosophers live on separate islands and are
    thinking of what to name a type. One comes up with "foo" and the
    other with "bar". If they meet and integrate their code, there will
    not be a clash.

    Now suppose that they are conscious of conventions; because they
    are naming a type, they both add "_t".

    That, ipso facto, is not going to *introduce* a clash!

    Everyone adding a common suffix to a class of identifiers will
    not introduce clashes in that class. Likewise, removing a common suffix
    will not introduce a clash.

    Now sure, if organization A uses _t, and B entirely avoids it, their
    type names cannot clash; velvet_underground and velvet_underground_t
    are distinct. But that's a bad reading of the situation.

    I want types in C programs to have _t whether they are coming
    from POSIX, third party vendors, or the local code base.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Bonita Montero@3:633/280.2 to All on Thu Jun 12 01:33:21 2025
    Am 11.06.2025 um 15:41 schrieb Scott Lurndal:

    That turns out to not be true. fdopendir(3) was added in Issue
    7 of the Single Unix Specification (aka POSIX). https://pubs.opengroup.org/onlinepubs/9799919799/functions/fdopendir.html ftw(3)/nftw(3) are used more often than opendir(3) in real world code.

    That doesn't make a difference for the discussed point.


    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Chris M. Thomasson@3:633/280.2 to All on Thu Jun 12 04:57:41 2025
    On 6/10/2025 3:09 PM, Keith Thompson wrote:
    Kaz Kylheku <643-408-1753@kylheku.com> writes:
    On 2025-06-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
    I find the reservation of potential errno macro names annoying.

    If the standard contained /no/ statements about what a given header
    file may reserve, then /any/ identifier whatsoever would be a potential
    clash.

    The errno reservation is kind of good because implementors often extend
    the set of errno constants. POSIX has a lot more of them than ISO C, and
    there are some vendor-specific ones.

    Anyway, you can safely ignore the reservation theatre, and just
    deal with clashes that happen, when they happen. (If you're lucky,
    that could just be never).

    You can do that, but a new clash could happen when your code is
    compiled on a system that defines an errno macro that you haven't
    seen before.

    Anyway, ISO C, POSIX and vendors have historically introduced new
    identifiers in spaces that were not previously declared as reserved.
    If you're ever hit by that, you will feel like a completel sucker if
    you've religiously adhered to namespaces from your end.

    Yes, that can happen, but no, I won't feel like a complete sucker.

    If I define my own strfoo() function and a new edition of the standard defines strfoo() in <string.h>, the clash is my fault,and I could have avoided it by defining str_foo().

    Nothing can prevent all possible name clashes, but I like to follow the
    rules in the standard that let me prevent some of them.


    Wrt to prepending to artificially create a namespace in C, ct, ala
    ct_*_*_* is fine with me. For your new addition how about a keith_thompson_*_*_* for your namespace? Or even a kt_* ? ;^)

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Lawrence D'Oliveiro@3:633/280.2 to All on Thu Jun 12 11:33:18 2025
    On Wed, 11 Jun 2025 17:33:21 +0200, Bonita Montero wrote:

    [fdopendir] doesn't make a difference for the discussed point.

    It’s a key part of the defence against symlink-related vulnerabilities.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Tim Rentsch@3:633/280.2 to All on Thu Jun 12 13:15:26 2025
    Richard Heathfield <rjh@cpax.org.uk> writes:

    On 28/05/2025 13:41, Tim Rentsch wrote:

    Richard Heathfield <rjh@cpax.org.uk> writes:

    On 24/05/2025 06:32, Tim Rentsch wrote:

    Richard Heathfield <rjh@cpax.org.uk> writes:

    On 23/05/2025 13:43, Tim Rentsch wrote:

    Richard Heathfield <rjh@cpax.org.uk> writes:

    On 20/05/2025 10:18, Keith Thompson wrote:

    C90 will never be extended.

    And for that reason it will always be valuable. Stability
    has a value all its own.

    C99 is just as stable as C90, and has been for well over a
    decade.

    Sure, but it's a different stable.

    If it were the same stable, it would be C90.

    C99 isn't C90, therefore it isn't the same stable.

    If you tell me C99 is a rock, I will not doubt you. But the C90
    rock it most certainly isn't.

    Now you're being silly.

    No, sir. If you want to play that game, you can play it with
    yourself. I know that you are perfectly capable of polite
    conversation, so I see no reason to endure the opposite.

    I don't think I'm being impolite.

    Then we are again in disagreement, and it seems obvious that it would
    be foolishly optimistic of me to expect to be able to resolve the
    matter. I'll tell Thunderbird to leave it there.

    Apparently my words were taken with a meaning I didn't intend.
    I'm sorry that this happened.

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Tim Rentsch@3:633/280.2 to All on Wed Jul 2 03:09:11 2025
    Richard Heathfield <rjh@cpax.org.uk> writes:

    On 30/05/2025 10:20, David Brown wrote:

    On 29/05/2025 14:38, Richard Heathfield wrote:

    This really is a very simple point, but perhaps a simple analogy
    will help to clarify it. You don't throw out your 3/4" just
    because you've bought a 19mm. There is room for both in the
    toolbox, and why write 3/4" on your new spanner? It /isn't/ a
    3/4" spanner even though it's very like it, so why pretend
    otherwise?

    Your analogy does not cover C99 vs C90.

    It does if we can construct a program that is legal C90 but not
    legal C99, which is easy enough, or (slightly harder but still not
    that hard) a program that is legal in both dialects but which
    gives different output under C99 than it does for C90.

    $ cat c9099.c; \
    gcc -W -Wall -ansi -pedantic -o c90 c9099.c; \
    gcc -o c99 c9099.c; \
    ./c90; \
    ./c99
    #include <stdio.h>

    int main(void)
    {
    int a = 42;

    int b = a //* comment */ 6;
    ;
    printf("Soln = %d\n", b);

    return 0;
    }
    Soln = 7
    Soln = 42

    It's a straightfoward exercise to write a program that discovers
    whether a given .c file has this potential ambiguity. Of course,
    essentially no actual source code will, but the point is the
    problem is easy to detect, and also correct.

    This observation suggests a related question. Is there a source
    of potential ambiguity between C90 and C99 that is not so easy to
    detect and correct? I can think of one, but it falls into the
    realm of depending on implementation-specific behavior, so could
    just as easily be seen as a portability issue rather than a
    language version issue.

    Obviously it's a contrived example, but then examples pointing out
    the consequences of language differences invariably are.

    Some are. Some are not. In the case of C90 and C99, probably
    all such cases are contrived, but certainly for other language
    pairs there are cases that might arise unintentionally, even for
    similar languages (notably C and C++).

    --- MBSE BBS v1.1.1 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From Jakob Bohm@3:633/280.2 to All on Mon Aug 18 05:04:11 2025
    On 2025-05-21 12:00, Paul Edwards wrote:
    "Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message news:100jhor$2lgt3$4@dont-email.me...
    On Wed, 21 May 2025 10:23:27 +1000, Paul Edwards wrote:

    ...

    The C90 standard deferred to MVS - probably still does -
    and says that you can't open a file as "w", then read it as
    "rb" and write (a new file) as "wb", and still access (the
    new file) with "r".

    I was shocked when I saw IBM's C library lose the newlines
    when I did the above, and went to look at the standard to
    show that IBM was violating C90 - but it turns out they
    weren't.

    That sort of means you can't write a "zip" program portably,
    against the theoretical C90 file system. Or you would have
    to have flags to say which files need to be opened as text
    or binary.


    I believe the Info-Zip group's ZIP program overcame this problem, by
    somehow enhancing the same feature that handles the difference between
    line endings on UNIX (LF), CP/M (CRLF) and MacOsClassic (CR), but I
    haven't checked .

    Also, the file system peculiarity is probably the same one I experienced
    when transferring some of my old work from VM/CMS to MS-DOS decades ago.

    I do not agree with IBM's C library, and PDPCLIB does
    not have that behavior, so that constraint could potentially
    be dropped in a C90+ standard.

    BFN. Paul.




    Enjoy

    Jakob

    --
    Jakob Bohm, MSc.Eng., I speak only for myself, not my company
    This public discussion message is non-binding and may contain errors
    All trademarks and other things belong to their owners, if any.

    --- MBSE BBS v1.1.2 (Linux-x86_64)
    * Origin: Privat (3:633/280.2@fidonet)
  • From Jakob Bohm@3:633/280.2 to All on Mon Aug 18 06:34:30 2025
    On 2025-05-22 07:14, Keith Thompson wrote:
    Lawrence D'Oliveiro <ldo@nz.invalid> writes:
    On Thu, 22 May 2025 02:20:36 +0200, Jakob Bohm wrote:
    The later UNIX-like file system NTFS ...

    It was (and is) hard to describe NTFS as “Unix-like”. Yes, it had
    hierarchical directories and long(ish) file names, but not much else.
    Drive letters were inherited (indirectly) from DEC OSes, of all things,
    along with an insistence on having filename extensions, restrictions on
    characters allowed in names etc.

    I consider NTFS UNIX-like because it is built around inodes (called MFT entries) and inode numbers, with no inherent special treatment of MSDOS metacharacters in the fundamental logic, except the few places that
    parse user supplied path strings such as symlink targets or passed
    through path strings from API calls .

    When the CP/M style directory listing operations are done on an NTFS directory, the NTFS code loads the file names and inode number from the directory storage, then checks the inode to fill in details such as
    MS-DOS file attributes and POSIX-style time stamps (using 64 bit time
    since 1600-01-01 00:00:00 GMT), next the user mode API logic converts filenames to the locale character set, discards the unwanted time stamps
    and convert the rest to the API encoding (which may be MS-DOS API locale
    time since 1980 or POSIX time since 1970 or Win32 FILETIME which is same
    as NTFS time).


    I don't believe that NTFS requires filename extensions.
    My understanding is that a file name is stored as a single string
    (with some restrictions).

    Symlinks were not even added until Windows Vista. And you have to have
    special privileges to create them.


    The mechanism for symlinks (NTFS reparse points) was included from the
    start, but exposure of that to user mode was always limited . I'm
    unsure if the crippled POSIX subsystem in the NT 3.10 release included symlinks or only hardlinks .


    Enjoy

    Jakob

    --
    Jakob Bohm, MSc.Eng., I speak only for myself, not my company
    This public discussion message is non-binding and may contain errors
    All trademarks and other things belong to their owners, if any.

    --- MBSE BBS v1.1.2 (Linux-x86_64)
    * Origin: Privat (3:633/280.2@fidonet)
  • From Kaz Kylheku@3:633/280.2 to All on Mon Aug 18 10:30:35 2025
    On 2025-05-21, Paul Edwards <mutazilah@gmail.com> wrote:
    Do note one more thing.

    The C90 standard deferred to MVS - probably still does -
    and says that you can't open a file as "w", then read it as
    "rb" and write (a new file) as "wb", and still access (the
    new file) with "r".

    You mean:

    - write a text file, close it; then
    - open it as a binary file and copy the bytes to another, new binary file; and - finally, read the new binary file in text mode?

    I don't see how that would be allowed to lose any newlines.

    You made a bitwise copy of the file.

    The worst thing that can happen is this: stdio implementations are not
    required to keep the exact length of a binary file down to a byte.

    Binary files can be rounded up and have padding bytes at the end.

    E.g. you write 37 byte, but the file ends up 256 bytes long.

    If an implementation has this issue, it probably will still represent
    text files in such a way that when you copy a binary file, including
    any gratuitous padding, the text file will come out right.

    A recent draft of ISO C says "A binary stream is an ordered sequence of characters that can transparently record internal data. Data read in
    from a binary stream shall compare equal to the data that were earlier
    written out to that stream, under the same implementation. Such a stream
    may, however, have an implementation- defined number of null characters appended to the end of the stream."

    I have C90 somewhere, I can look that up too, but I suspect it was
    the same.

    I was shocked when I saw IBM's C library lose the newlines
    when I did the above, and went to look at the standard to
    show that IBM was violating C90 - but it turns out they
    weren't.

    Losing the newlines in the above scenario (bit copy made of text
    file as a binary file) makes no sense.

    If it is true, someone went out of their way to fuck up something
    simple. (IBM would never do that, right?)

    If we copy a text file as binary and newlines change it suggests that
    the implementation is falling afoul of the "binary stream is an
    ordered sequence of characters that can transparently record
    internal data".

    That sort of means you can't write a "zip" program portably,
    against the theoretical C90 file system.

    Or you would have
    to have flags to say which files need to be opened as text
    or binary.

    This is probably a good idea anyway; you don't want to be compressing
    the proprietary-format binary images of text files, if they are to
    decompress correctly on another system.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca

    --- MBSE BBS v1.1.2 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)
  • From James Kuyper@3:633/280.2 to All on Wed Aug 20 08:09:48 2025
    On 2025-08-17 20:30, Kaz Kylheku wrote:
    On 2025-05-21, Paul Edwards <mutazilah@gmail.com> wrote:
    Do note one more thing.

    The C90 standard deferred to MVS - probably still does -
    and says that you can't open a file as "w", then read it as
    "rb" and write (a new file) as "wb", and still access (the
    new file) with "r".

    You mean:

    - write a text file, close it; then
    - open it as a binary file and copy the bytes to another, new binary file; and
    - finally, read the new binary file in text mode?

    I don't see how that would be allowed to lose any newlines.

    You made a bitwise copy of the file.
    ....
    A recent draft of ISO C says "A binary stream is an ordered sequence of characters that can transparently record internal data. Data read in
    from a binary stream shall compare equal to the data that were earlier written out to that stream, under the same implementation. Such a stream
    may, however, have an implementation- defined number of null characters appended to the end of the stream."

    I have C90 somewhere, I can look that up too, but I suspect it was
    the same.

    It was.

    This can interact with text mode, if the representation of new-lines in
    text mode involves null characters. I know of two different ways that
    have actually been used where this could be a problem. One method uses
    null characters to represent a single new-line. The other method stores
    lines in fixed-length blocks, with the end of a line indicated by
    padding to the end of the block with null characters. Either way, the
    padding bytes that may be added in binary mode could be interpreted as
    extra newlines in text mode. That does not match Paul's problem:

    I was shocked when I saw IBM's C library lose the newlines
    when I did the above, and went to look at the standard to
    show that IBM was violating C90 - but it turns out they
    weren't.

    It would help if Paul would identify the clauses from C90 that he
    interpreted as permitting such behavior.

    --- MBSE BBS v1.1.2 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)