Hello Matthias.

I only answer here..

Matthias Andree via Mutt-dev wrote in
 <[email protected]>:
 |Am 20.04.26 um 18:15 schrieb Steffen Nurpmeso:
 |> Alejandro Colomar via Mutt-dev wrote in
 |>   <aeP4WD47Pch3b5UT@devuan>:
 |>|On 2026-04-18T02:10:17+0200, Steffen Nurpmeso wrote:
 |>|[...]
 |>|> I never used the standard library until i took maintainership of
 |>|> that MUA, really.  (fprintf(3), but only as the last possibility
 |>|> in case of debug havoc.)  We had (or could) -nostdlib (on Linux;
 |>|> but needed -ldl), dtors, ctors, (ifuncs), this all not used
 |>|> (-fno-rtti and all that), so it was wonderful.
 |>|
 |>|Hmmm, then yes, that would count as C89.  It's quite rare, as these days
 |>|almost every program uses POSIX or C99 library stuff, such as
 |>|snprintf(3).
 |>
 |> Libraries seem to have detoriated thus, in that, i think compiling
 |> on a twenty year old system will currently really fail, also
 |> because of snprintf for example.  (Originally there was a "lazy
 |> wrapper" which simply called vsprintf().)
 |> But it is on the list and not forgotten.
 |
 |I would advise not to waste time and brain cycles for open source on 
 |getting network-related code -- or generally code that needs to support 
 |inputs you don't control -- to run on 20-year-old systems with 
 |insufficient library support that make you write 20 lines of situation 
 |and error checking for a job you get done with three in a modern variant 
 |of your programming language and one in another. We've seen mutt 
 |maintainers come and go over the years.

Not having the *at() series of systemcalls is a security problem
for sure.  They are really, really good inventions.

 |> That standard format I/O, for example, i never liked, i will
 |> port the "format codec", one day.  (Just a(n) (restartable)
 |> object that does it, being fed from the front instead of
 |> calling pointer-to-function from the back, as some I/O libraries
 |> implemented the *f() series, at one time, at least.  With it,
 |> non-restartable (eg stack buffer) is then simply
 |>
 |>          Txt::FormatDecoder      fd;
 ...
 |>          _cplen = ((fd.isFinished() || 0 != fd.numberOfConversions())
 ...
 |> which is so much better than anything else thinkable.)
 |
 |Wasting time on solved problems seems to be a hobby project in itself, 
 |but not useful if you don't have it now but want your application (such 
 |as mutt) written and progress.

That code is from before 2003 (it should be from 2001 really).
It is not typesafe, granted, it is a normal format string thing;
i hated QT with their multiple iterations over the buffer in
order to support some marshalled typesafe argument, *if* i recall
that correctly; i have to knock in wood, yes, but i almost never
had problems with format strings, and that even though i do not
use the GNU etc compiler attributes like (iirc) "printflike()"
that let you freely say argument X of that prototype is in fact
a format string.  (Because types would not have matched for one
(only exact bits in %{h{,h},l}u, as in 8,16,32,64..), and some
extensions, like %R to produce a (configurable) newline.)

But yes, this really is one of the problems.  ISO C(++) should
have made official ({..}), and the attributes packed and
aligned(X), and if only that i can use a PACKED macro which
expands to __attribute__((packed, aligned(1))).
You cannot do nothing without these attributes, except maybe using
bit fields and hope for pain-staking standard words and correctly
interpretation thereof.  Not a single over-the-write DNS packet
for example can be interpreted correctly, etc etc etc, but still
these are missing, a quarter of a century later.  (I think.)
(Ah wait, it seems there is now _Alignas(), since C11.)

I am fine with my C++ view objects, it cannot be more efficient --
i hate that "auto" misuse thingy from newer C++, i have no problem
with it -- i mean, it is completely off-topic for mutt, of course,
but your

     for (const auto &[key, value] : mymap) {  /* do something useful with key 
and value */ }

is not backward compatible to anything and looks to my eyes like
a cryptic mess, we nearly come near the "brainfuck" language in
modern C++, at times, as far as i (have to) look at it; where is
the improvement for example to

      cs_dict<char*,TRU1> cdo(auto_type_toolbox<char*>::get_instance());

      for(cs_dict<char*,TRU1>::view cdov(*&cdo); cdov; ++cdov)
         // .key(), .data() [+const], .is_valid(),
         // .is_same_parent(), .set_data(), .find()
         // you name it

Add a typedef more and it is even better (you may need "typename"
then though, see i have no idea, i would have to look whether it
works without "typename", and then the question is, how portable
is it without typename).

I mean, you know, it was some PDF framework .. hm .. a megabyte
large codebase, decades old, and he lost backward compatibility by
adding one (!) instance of your syntax example above.  (That was
years ago, in the meantime he lost more backward compatibility by
using even newer C++ standard stuff.  I have forgotten .. but
still am subscribed to the projects announcements, at times
a message shows up.)

So -- anybody just the way they want, of course, but i do not like
the complicatifications, the immense growth, and anything like
that.  If it would be me there would not even be a reference, but
only pointers.  And not taking into account FOREACH() macros that
i only have for the C base types like

  #define su_CS_DICT_VIEW_FOREACH(SELF) \
        for(su_cs_dict_view_begin(SELF); su_cs_dict_view_is_valid(SELF); 
su_cs_dict_view_next(SELF))

and could be added to C++ also, but i see no reason.
I think certain tools even "know" about foreach() constructs,
likely in order to support developers that hack on Linux, which
makes use of that regulary.
No no, not me.

But sure, i have heard the C++ standard library gained lots of
really good programming facilities, including timezones, and all
that.  Yes.  That is great.  I was, at times, even stunned that
some example program using the STL was effectively not larger than
the same functionality using our stuff, even though STL was fully
template based, whereas here there were always C basic types, or
at least void* based basics, plus fully inlined typesafe wrappers.
Very noisy, all the surroundings, for sure.

But all that off-topic for the mutt MUA, of course.  Sorry.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Reply via email to