Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #87023
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: CHAR_BIT is not eight |
| Message-ID | <20221016191833.00003f69@reddwarf.jmc.corp> (permalink) |
| References | (11 earlier) <tie65c$2n1ei$1@dont-email.me> <20221015124549.000031e1@reddwarf.jmc.corp> <tih6ga$35lhr$1@dont-email.me> <20221016163414.000003a9@reddwarf.jmc.corp> <tihcrc$3683u$3@dont-email.me> |
| Organization | Jupiter Mining Corporation |
| Date | 2022-10-16 19:18 +0100 |
On Sun, 16 Oct 2022 18:51:56 +0200
David Brown <david.brown@hesbynett.no> wrote:
> On 16/10/2022 17:34, Mr Flibble wrote:
> > On Sun, 16 Oct 2022 17:03:38 +0200
> > David Brown <david.brown@hesbynett.no> wrote:
> >
> >> On 15/10/2022 13:45, Mr Flibble wrote:
> >>> On Sat, 15 Oct 2022 13:39:24 +0200
> >>> David Brown <david.brown@hesbynett.no> wrote:
> >>>
> >>>> On 14/10/2022 22:01, Mr Flibble wrote:
> >>>>> On Fri, 14 Oct 2022 14:58:54 -0000 (UTC)
> >>>>> Muttley@dastardlyhq.com wrote:
> >>>>>
> >>>>>> On Fri, 14 Oct 2022 14:47:46 +0100
> >>>>>> Mr Flibble <flibble@reddwarf.jmc.corp> wrote:
> >>>>>>> On Fri, 14 Oct 2022 15:27:13 +0200
> >>>>>>> David Brown <david.brown@hesbynett.no> wrote:
> >>>>>>>> Yes, it is always /possible/. But the complications and
> >>>>>>>> effort involved is unlikely to be worth the effort, and
> >>>>>>>> you'd still end up with something taking a massive amount of
> >>>>>>>> code space. (With "massive" being relative to the small code
> >>>>>>>> memories of such systems.)
> >>>>>>>>
> >>>>>>>> It's not uncommon in my coding to build up a few lists at the
> >>>>>>>> startup of the system - lists of "run" functions or software
> >>>>>>>> timers, etc. Modules might register such callbacks or
> >>>>>>>> functions when initialised. In "big system" C++, you might
> >>>>>>>> just use a vector for that - adding your timer objects to
> >>>>>>>> your vector as needed. It's simple and easy in the code.
> >>>>>>>>
> >>>>>>>> But in a resource-constraint embedded system, where
> >>>>>>>> efficiency of code space, ram space and run-time is
> >>>>>>>> important (though run-time efficiency is usually less
> >>>>>>>> important for startup code), that's not what you would do.
> >>>>>>>> You make your timer class have the required list link
> >>>>>>>> pointers in the class, have each registering function
> >>>>>>>> declare their timer object with static lifetime, and your
> >>>>>>>> registration function links them together.
> >>>>>>>>
> >>>>>>>> There's no doubt that this takes a bit more effort to write
> >>>>>>>> than an off-the-shelf std::vector. But it is vastly simpler
> >>>>>>>> than faffing around making your own allocator, avoids the use
> >>>>>>>> of any kind of dynamic memory (using neither the standard
> >>>>>>>> heap nor a home-made allocation system), and pulls in a tiny
> >>>>>>>> fraction of the amount of library code.
> >>>>>>>>
> >>>>>>>> std::array<> is free - it's just a nice wrapper around a
> >>>>>>>> plain C-style array.
> >>>>>>>
> >>>>>>> List link pointers? Again there is no reason to not use
> >>>>>>> std::list with a suitable allocator even on such resource
> >>>>>>> constrained hardware and I disagree that the resultant text
> >>>>>>> size and ram usage would be any worse than anything you could
> >>>>>>> come up with by hand.
> >>>>>>
> >>>>>> If the memory layout is hard coded at boot time why even bother
> >>>>>> pulling in std::list or any kind of container as you don't need
> >>>>>> their generic functionality which will almost certainly waste
> >>>>>> EEPROM space. With embedded development you often literally
> >>>>>> have to worry about every byte you use both in ROM and RAM and
> >>>>>> whether the mainloop is going to be fast enough to do its job.
> >>>>>>
> >>>>>
> >>>>> In C++ you don't pay for what you don't use: in the case of a
> >>>>> C++ class template only the member functions instantiated will
> >>>>> exist in the text segment.
> >>>>>
> >>>>
> >>>> There are always /lots/ of other functions that get pulled in
> >>>> from libraries. Remember, for small embedded systems the
> >>>> libraries are not shared dynamic libraries that you don't see.
> >>>>
> >>>> Just for a quick test, I made a minimal C++ main() function and
> >>>> compiled for a modern microcontroller. With an empty main(), it
> >>>> was about 8400 bytes code of common library code. Adding a
> >>>> "std::list<int>" object and using a couple of pops and pushes
> >>>> adds about 7 KB code to the program.
> >>>>
> >>>> If you are making a lot of use of the standard containers, that's
> >>>> fine - and there's a lot of overlap and sharing in this extra
> >>>> code. But in small systems, this kind of stuff can get
> >>>> significant - microcontrollers with 32 KB flash are common, and
> >>>> it's nice to be able to program them in C++. In the C++
> >>>> /language/, you pay very little (not quite nothing) for features
> >>>> that you don't use, but that does not apply equally to the more
> >>>> advanced standard library classes.
> >>>>
> >>>> It's the same in C, of course - call just one little time
> >>>> conversion function and you can find half your flash is used for
> >>>> locale handling and time zones.
> >>>>
> >>>> The needs of embedded systems vary enormously - for many, the
> >>>> cost in code space or run-time efficiency for using a std::list
> >>>> or std::vector is negligible. But for others, it is very far
> >>>> from negligible.
> >>>>
> >>>> (It is relatively rare that you have to worry about /every/ byte
> >>>> of code or data space, however - though it does happen.)
> >>>
> >>> Try using std::list with a custom allocator as I originally
> >>> suggested; also your quote of 7KB sounds highly dubious and
> >>> anecdotal.
> >>
> >> Of course the example of 7 KB is anecdotal - I told you I made a
> >> quick test. It doesn't get more anecdotal than that. But no, it
> >> is not "highly dubious" - it is really what I got.
> >>
> >> Every programmer works in a particular area, or small set of areas
> >> - /nobody/ has experience and knowledge of all kinds of
> >> programming. The trick to having realistic conversations and not
> >> appearing arrogant and ignorant is to understand your limitations.
> >> You simply don't know what you are talking about when it comes to
> >> small-systems embedded programming, and some of the challenges or
> >> limitations involved that are different from the kind of
> >> programming you are used to. (And similarly there is plenty about
> >> the kind of coding /you/ do that I am ignorant about.)
> >>
> >> So it is /fine/ for you to ask "why don't you just use a std::list
> >> with a custom allocator". It is /not/ fine for you to claim people
> >> are wrong when they tell you why they don't do that.
> >>
> >> Why don't I write a custom allocator for std::list and then use
> >> that instead of the pointer-based "home made" linked list I have
> >> now? I don't do so because it is a lot of effort and will result
> >> in bigger, slower, wasteful and vastly more complicated code than
> >> the two dozen or so lines of shared C and C++ code I have at the
> >> moment that has worked fine for the last 20+ years. It's not
> >> unlikely that with a custom allocator and disabled exceptions I
> >> could probably get the overhead of std::list down to 2 or 3 KB
> >> rather than 7 KB. But that only makes it not quite as inefficient
> >> - it still is not close to the efficiency and convenience of the
> >> custom solution. And that would come after writing far more code
> >> to make the "standard" container work than it took to make a
> >> completely custom solution.
> >
> > So you admit that you *might* be able to get it down to 2KB; so I
> > was correct in my analysis and it is you who is arrogant not me.
>
> Sorry, you seem to be having trouble understanding the conversation.
> No, your analysis was not correct - the 7 KB was not "highly
> dubious", but an actual measurement on real code that was compiled
> and linked (with a case sample size of 1). Disabling exceptions
> would have been simple, and it is common practice on small embedded
> systems - just as avoiding most standard library containers (and much
> of the C and C++ standard libraries) is common practice on small
> embedded systems. Leaving exceptions enabled is a fairer test,
> however, as it would be realistic for the kind of programmer who
> thinks std::list<> and custom allocators is a good idea for the task
> in hand.
>
> > I am also
> > well aware of the constraints involved in embedded programming and
> > your assumption that I am not is another sign of your arrogance.
> >
>
> I can only assume based on what you write - and you do not write as
> someone who has experience in small-systems embedded programming.
>
> > It is highly unlikely that your solution is more performant than
> > std::list; a double linked list is hardly rocket science and
> > standard library implementations are generally written by people
> > who know what they are doing.
>
> It would not surprise me if my solution is an order of magnitude
> better performing than std::list<>. (Not that I claim the difference
> would be significant for the use in question. std::list<> is going
> to be pretty efficient, but a very simple custom single linked list
> can be considerably more efficient.) As you say, a linked list is
> not rocket science - there's no need for custom allocators and
> standard library containers when all that's needed is a "pointer to
> next node" field in the node structure.
>
> >
> > So you can either apologize or fuck off.
> >
>
> You are joking, yes? You think I should apologize for your
> misunderstandings, your unwarranted assumptions, your accusations of
> dishonesty and your belief that you know better than anyone else
> about fields of programming that are completely beyond your
> experience?
>
> I'm will try to avoid posting more in this subthread unless it
> contributes something positive. Hopefully you'll do the same.
I know Fedora isn't an embedded target but I was interested to see what
the difference using std::list makes to elf binary size (symbols
stripped):
int main()
{
}
[leigh@fedora ~]$ g++ foo.cpp
[leigh@fedora ~]$ strip a.out
[leigh@fedora ~]$ ls -l a.out
-rwxr-xr-x 1 leigh leigh 14952 Oct 16 19:09 a.out
#include <list>
int main()
{
std::list<int> l;
l.push_back(42);
}
[leigh@fedora ~]$ g++ foo.cpp
[leigh@fedora ~]$ strip a.out
[leigh@fedora ~]$ ls -l a.out
-rwxr-xr-x 1 leigh leigh 15192 Oct 16 19:10 a.out
[leigh@fedora ~]$ g++ -fno-exceptions foo.cpp
[leigh@fedora ~]$ strip a.out
[leigh@fedora ~]$ ls -l a.out
-rwxr-xr-x 1 leigh leigh 15088 Oct 16 19:10 a.out
So that is just 240 extra bytes to binary file size when using
std::list ctor, dtor and push_back; and even less bytes if we disable
exceptions.
Again, feel free to apologize or fuck off; and don't assume I don't
know what I am talking about again; it is just civilised and basic good
manners to assume the person opposite isn't a dumb fuck.
/Flibble
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-12 15:57 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-12 16:01 -0700
Re: CHAR_BIT is not eight Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-10-12 17:16 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 11:38 +0200
Re: CHAR_BIT is not eight Michael S <already5chosen@yahoo.com> - 2022-11-16 06:24 -0800
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-17 11:04 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-11-17 16:40 +0000
Re: CHAR_BIT is not eight Richard Damon <Richard@Damon-Family.org> - 2022-11-17 23:23 -0500
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-18 08:16 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-11-18 16:33 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-18 18:54 +0100
Re: CHAR_BIT is not eight Michael S <already5chosen@yahoo.com> - 2022-11-18 03:47 -0800
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-11-18 14:52 +0000
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-11-18 16:32 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-18 19:05 +0100
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-11-18 18:16 +0000
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-13 08:02 +0000
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-13 08:08 +0000
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 11:35 +0200
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 02:53 -0700
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 11:57 +0200
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 03:05 -0700
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-17 06:18 +0000
Re: CHAR_BIT is not eight Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-17 15:29 -0500
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-13 02:06 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 11:42 +0200
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-13 15:36 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 23:06 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-13 22:30 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-14 15:27 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-14 14:47 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-14 14:58 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-14 21:01 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 10:28 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-15 13:39 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 12:45 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:18 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:24 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:34 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:39 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:53 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:55 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:57 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:59 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-17 15:27 +0000
Re: CHAR_BIT is not eight "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-10-17 09:04 -0700
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-17 16:13 +0000
Re: CHAR_BIT is not eight red floyd <no.spam.here@its.invalid> - 2022-10-17 09:44 -0700
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-17 17:47 +0100
Re: CHAR_BIT is not eight Manfred <noname@add.invalid> - 2022-10-18 01:10 +0200
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-17 16:22 -0700
Re: CHAR_BIT is not eight Paul N <gw7rib@aol.com> - 2022-10-18 05:13 -0700
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-18 15:04 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-18 17:40 +0100
Re: CHAR_BIT is not eight "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-10-18 12:14 -0700
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-19 15:12 +0000
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-10-19 15:35 +0000
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-20 16:16 +0000
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 20:13 +0200
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 20:11 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 20:03 +0100
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-16 07:51 +0200
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 17:03 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 16:34 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 18:51 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 18:11 +0100
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 19:18 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 22:02 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 21:19 +0100
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-10-16 21:24 +0000
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 14:38 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 14:48 -0700
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 22:39 +0100
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-10-16 23:49 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-17 09:54 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-17 17:31 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-17 19:56 +0200
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-17 15:29 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-17 17:33 +0100
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 11:55 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-15 13:06 -0700
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 15:42 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 19:10 +0200
Re: CHAR_BIT is not eight Vir Campestris <vir.campestris@invalid.invalid> - 2022-10-16 21:28 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-17 10:09 +0200
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 13:35 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 13:36 -0700
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-02 17:46 -0700
Re: CHAR_BIT is not eight Bo Persson <bo@bo-persson.se> - 2022-10-13 11:10 +0200
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-13 10:49 +0000
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-13 12:05 +0000
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-13 06:34 -0700
Re: CHAR_BIT is not eight Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-13 15:24 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 15:59 +0200
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-14 05:54 +0000
Re: CHAR_BIT is not eight Paavo Helde <eesnimi@osa.pri.ee> - 2022-10-14 09:16 +0300
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-16 05:41 -0800
Re: CHAR_BIT is not eight Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-16 10:38 -0800
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-05 11:42 -0800
Re: CHAR_BIT is not eight Öö Tiib <ootiib@hot.ee> - 2022-12-06 01:03 -0800
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-28 20:49 -0800
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-14 00:17 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-14 15:33 +0200
Re: CHAR_BIT is not eight Vir Campestris <vir.campestris@invalid.invalid> - 2022-10-16 21:37 +0100
Re: CHAR_BIT is not eight Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-17 15:24 -0500
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 11:34 +0200
csiph-web