On 18/11/2021 12:56, Malcolm McLean wrote:
> On Thursday, 18 November 2021 at 09:50:36 UTC, David Brown wrote:
>> On 18/11/2021 05:46, William Ahern wrote:

> I tend to use C++ for strings because C++ strings are assignable, destructible,
> returnable, and C++ manages the buffer. C isn't a good language for doing
> string processing in (though it is a good language for implementing string
> processing algorithms themselves in).

None of that is the slightest help to the OP. C++ classes that manage
dynamic memory are easier to get right than manual memory management in
C - but there are still useless if you want (with good reason) to avoid
any use of heap memory.

>>
>>> The way to avoid string buffer errors is to avoid strings and stick to
>>> concrete data types or to process data in a rigorously streaming fashion.
>> The way to avoid string buffer errors is the same as you avoid any other
>> errors - good development practices. That runs the whole gamut from
>> high level concerns to low-level details. It includes making sure you
>> have clear specifications for the code you are writing, making sure the
>> programmer is appropriately qualified, having code review practices,
>> testing regimes, automatic checking tools, making sure the data coming
>> into your code is appropriate, making sure you correctly handle all
>> cases (including worst cases and pathological cases), and so on. It's
>> just like any other coding error.
>>
> This all costs money, it demands management skills and resources
> the company may not have, and it can lead to programmers feeling
> over-managed.

You pick details that match the needs of the project and the
capabilities of the company. A small company might not have a large
enough programming team to make code reviews possible. The quality
control you need for a simple desktop program is going to be different
from what you need for controlling a car engine. And so on.

> A very important factor is the testability of the code, and the consequences
> of an error. You can over-engineer processes as well as actual code.
>

Of course. Lots of bugs have occurred by people putting in "just in
case" test code that is untestable in the lab, but fails at some point
after deployment.

Thiago Adams <thiago.adams@gmail.com> writes:

> One problem of std::string tries to do two different jobs at the same
> time using the same object. One job is "string builder" and a the
> other "string holder"
>
> Using std::string as string holder is a waste of memory. For instance:
> std::map<std::string, something>
> Map doesn't want build string, it just need to hold a string.

Why would you write that if you wanted just to reference the strings?
You'd use std::map<std::string &, something>, or similar. Your
builder/holder distinction is unclear to me.

--
Ben.

On 2021-11-17, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
> Depending on the context, "generally" can mean either "usually" or
> "always". I've found that people generally interpret it in the most
> inconvenient way possible.

So, do you mean that people *usually* interpret it in the most
inconvenient way possible or that people *always* interpret it in the
most inconvenient way possible?

I find that generally people can be very imprecise with their language.

--
Jeremy Brubaker

On Thursday, November 18, 2021 at 1:38:46 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams <thiago...@gmail.com> writes:
>
> > One problem of std::string tries to do two different jobs at the same
> > time using the same object. One job is "string builder" and a the
> > other "string holder"
> >
> > Using std::string as string holder is a waste of memory. For instance:
> > std::map<std::string, something>
> > Map doesn't want build string, it just need to hold a string.
> Why would you write that if you wanted just to reference the strings?
> You'd use std::map<std::string &, something>, or similar. Your
> builder/holder distinction is unclear to me.

We can create a map<const char*, something> or create a small
string class RAII for it. But this is a workaround and represents
exceptions of usage and more rules. (when use/not to use std::string)

If you try std::map<std::string &, something> then a lot of operations will
become different.

e.g

std::map<std::string&, X> map;
map["a"] = X(1);

will give you 10 lines of error.

If you have a map of references the string must live in some place.
They must live more than the map. I never tried to do this, but now
just to see what happens it is hard to make it work.

https://godbolt.org/z/r95M1Tn6W

>Your builder/holder distinction is unclear to me.
If std::string wants to build the string (manage the size and allocation/deallocation)
concatenate string using += + etc.. more data is necessary. For instance, the capacity of
the buffer is also included inside the string object.

On the other hand, if you have a string just to hold a string (like char*) this is enough
for a key in a map and we will never need concatenated etc this object after its creation.
So it is waste of memory. Even size is not necessary in this case.

Jeremy Brubaker <jbrubake@orionarts.invalid> writes:
> On 2021-11-17, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>> Depending on the context, "generally" can mean either "usually" or
>> "always". I've found that people generally interpret it in the most
>> inconvenient way possible.
>
> So, do you mean that people *usually* interpret it in the most
> inconvenient way possible or that people *always* interpret it in the
> most inconvenient way possible?

Yes.

> I find that generally people can be very imprecise with their language.

Yes.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Thiago Adams <thiago.adams@gmail.com> writes:
> On Thursday, November 18, 2021 at 1:38:46 PM UTC-3, Ben Bacarisse wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>>
>> > One problem of std::string tries to do two different jobs at the same
>> > time using the same object. One job is "string builder" and a the
>> > other "string holder"
>> >
>> > Using std::string as string holder is a waste of memory. For instance:
>> > std::map<std::string, something>
>> > Map doesn't want build string, it just need to hold a string.
>> Why would you write that if you wanted just to reference the strings?
>> You'd use std::map<std::string &, something>, or similar. Your
>> builder/holder distinction is unclear to me.
>
> We can create a map<const char*, something> or create a small
> string class RAII for it. But this is a workaround and represents
> exceptions of usage and more rules. (when use/not to use std::string)

Two const char* values can be unequal but refer to the same string value.

[...]

> On the other hand, if you have a string just to hold a string (like
> char*) this is enough for a key in a map and we will never need
> concatenated etc this object after its creation. So it is waste of
> memory. Even size is not necessary in this case.

A char* value doesn't *hold* a string, it *refers to* a string. And a C
string, unlike a C++ std::string, cannot contain null characters (which
may well be perfectly ok for most applications).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

In article <sn2lvp$sl7$1@dont-email.me>,
pozz <pozzugno@gmail.com> wrote:

> Many times I need to construct a string through a call to sprintf and
> pass it to an external function.

If it's too crippled to have malloc, you can do your own. Many
systems have blank common or bss after the end of all memory
initialised with code and data. You might even have the extern
address 'edata' for the bss start and 'end' for bss end. If so
you can use that as a heap:
void *heap = edata, *heapend = end;
If all else fails, use the load map to determine the maximum N
char heap[N]; char *heapend = heap+N;
with cc -DN=biggestthatloads ...
Once you got your heap area, you can do something cheap like
void *marker = 0;
void *mark (size_t n) {
void *address = marker ? marker : heap;
if (address+n>=heapend) return 0;
marker = address+n; return address;
}
void release (void *address) {
marker = address;
}
.....
char *s = mark(strlen(yourname)
+strlen("Hi %s, today is %d/%d/%d"_
+4+2+2+1;
sprintf(s, "Hi %s, today is %d/%d/%d",
yourname, day, month, year);
lcd_write(s);
/*string no longer needed*/release(s);

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

Thiago Adams <thiago.adams@gmail.com> writes:

> On Thursday, November 18, 2021 at 1:38:46 PM UTC-3, Ben Bacarisse wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>>
>> > One problem of std::string tries to do two different jobs at the same
>> > time using the same object. One job is "string builder" and a the
>> > other "string holder"
>> >
>> > Using std::string as string holder is a waste of memory. For instance:
>> > std::map<std::string, something>
>> > Map doesn't want build string, it just need to hold a string.
>> Why would you write that if you wanted just to reference the strings?
>> You'd use std::map<std::string &, something>, or similar. Your
>> builder/holder distinction is unclear to me.
>
> We can create a map<const char*, something> or create a small
> string class RAII for it. But this is a workaround and represents
> exceptions of usage and more rules. (when use/not to use std::string)

That's not my view. It makes what you mean explicit. You either copy
to string into the map or you reference it. Whatever it you do in C
will be (logically) one or the other, but it won't be explicit -- at
least not in the type itself.

> If you try std::map<std::string &, something> then a lot of operations will
> become different.
>
> e.g
>
> std::map<std::string&, X> map;
> map["a"] = X(1);
>
> will give you 10 lines of error.

Yes, sorry. I meant to suggest a pointer. You can't use (raw)
references in maps.

--
Ben.

On 18/11/2021 21:25, Siri Cruise wrote:
> In article <sn2lvp$sl7$1@dont-email.me>,
> pozz <pozzugno@gmail.com> wrote:
>
>> Many times I need to construct a string through a call to sprintf and
>> pass it to an external function.
>
> If it's too crippled to have malloc, you can do your own. Many
> systems have blank common or bss after the end of all memory
> initialised with code and data. You might even have the extern
> address 'edata' for the bss start and 'end' for bss end. If so
> you can use that as a heap:

It is not a matter of a system not having "malloc" and a heap - it is a
matter of deciding not to use it. In small systems with limited ram and
no paging mechanisms, it is quite realistic to either run out of heap
space or - worse, since it is harder to find by testing - for heap
fragmentation to mean that memory allocations may fail as there is not
enough consecutive free space. And in embedded systems, failure to get
the memory you need often means failure of the system - the device does
not do its job.

Thus a 0 return from malloc can be as bad as a string buffer overflow or
any other error - the system is broken, the car crashes, the microwave
burns your food, the washing machine eats your socks. And while you can
avoid the string buffer overflow by making sure your buffer is large
enough and your string is limited in length, making sure your heap can
/never/ get fragmented is typically either extremely difficult, or
impossible. The solution is to avoid dynamic memory in any situation
where failure to get the memory is not tolerable.

In article <sn6jgl$val$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:

> It is not a matter of a system not having "malloc" and a heap - it is a
> matter of deciding not to use it. In small systems with limited ram and

So you cut off your hand and now you want to be told how to
fashion a hook. Got it. Good luck.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

On Friday, 19 November 2021 at 01:22:36 UTC, Siri Cruise wrote:
> In article <sn6jgl$val$1...@dont-email.me>,
> David Brown <david...@hesbynett.no> wrote:
>
> > It is not a matter of a system not having "malloc" and a heap - it is a
> > matter of deciding not to use it. In small systems with limited ram and
> So you cut off your hand and now you want to be told how to
> fashion a hook. Got it. Good luck.
>
David Brown probably didn't take the decision himself not to use malloc.
Dynamic memory is often banned, by over-all coding requirements that
are decided upon by senior mangement or customers.

The question then is what to do when you have a string whose length isn't
known at compile time.

On Wednesday, November 17, 2021 at 6:36:09 PM UTC-3, Scott Lurndal wrote:
> David Brown <david...@hesbynett.no> writes:
> >On 17/11/2021 19:21, Scott Lurndal wrote:
> >> David Brown <david...@hesbynett.no> writes:
> >>> On 17/11/2021 16:36, Malcolm McLean wrote:
> >>>> On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
> >>>>> pozz <pozz...@gmail.com> writes:
> >>>>>> Many times I need to construct a string through a call to sprintf and
> >>>>>> pass it to an external function.
> >>>>>>
> >>>>>> char s[32];
> >>>>>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
> >>>>>> lcd_write(s);
> >>>>> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
> >>>>>
> >>>> It depends whether wrong results are better or worse than no results.
> >>>>
> >>>
> >>> Generally, a truncated string on the output is better than a stack
> >>> overflow with your embedded system crashing or going wild. But your
> >>> needs may vary.
> >>
> >> Indeed. Plus a good programmer checks the return value from snprintf.
> >> Always.
> >>
> >
> >Really? I never do. But I make sure my buffers are the right size for
> >the job - or that it doesn't matter if there is truncation (such as for
> >log outputs). I prefer to be sure that my inputs to the function are
> >correct, than to call the function and check for problems afterwards.
> >(Different people can have different requirements here - but that's the
> >way I do it.)
> >
> I often use snprintf in place of strcat. For that purpose, checking the return
> value is required.
>
>
> char buffer[1024];
> char *bp = buffer;
> size_t remaining = sizeof(buffer);
> int diag;
>
> diag = snprintf(bp, remaining, "%s", string_to_append_to_buffer);
> if (diag != -1 && diag < remaining) {
> bp += diag, remaining -= diag;
> } else {
> /* Handle overflow/error as necessary */
> }
>
> ....
>
> The only problem is that the return value for snprintf is 'int', while
> the buffer size is size_t; which means on systems with a 64-bit size_t,
> the return value isn't large enough to express the correct return value
> when the size of the result value exceeds 4GB. Not generally a problem in
> actual code, but something to be aware of.

And there is a warning when we compare the result of snprintf (int)
against sizeof that returns size_t.

I put cast and this is very annoying.

char buffer[10];
if (snprintf(buffer, sizeof(buffer), "%s", psz) >= (int)sizeof(buffer)) {
//error
}

Actually sizeof returning size_t requires more casts in other places
of my code.

On Friday, 19 November 2021 at 13:38:20 UTC, Thiago Adams wrote:
> On Wednesday, November 17, 2021 at 6:36:09 PM UTC-3, Scott Lurndal wrote:
> > David Brown <david...@hesbynett.no> writes:
> > >On 17/11/2021 19:21, Scott Lurndal wrote:
> > >> David Brown <david...@hesbynett.no> writes:
> > >>> On 17/11/2021 16:36, Malcolm McLean wrote:
> > >>>> On Wednesday, 17 November 2021 at 15:34:50 UTC, Scott Lurndal wrote:
> > >>>>> pozz <pozz...@gmail.com> writes:
> > >>>>>> Many times I need to construct a string through a call to sprintf and
> > >>>>>> pass it to an external function.
> > >>>>>>
> > >>>>>> char s[32];
> > >>>>>> sprintf(s, "Hi %s, today is %d/%d/%d", yourname, day, month, year);
> > >>>>>> lcd_write(s);
> > >>>>> One might consider using 'snprintf' instead of 'sprintf'; it is a bit safer.
> > >>>>>
> > >>>> It depends whether wrong results are better or worse than no results.
> > >>>>
> > >>>
> > >>> Generally, a truncated string on the output is better than a stack
> > >>> overflow with your embedded system crashing or going wild. But your
> > >>> needs may vary.
> > >>
> > >> Indeed. Plus a good programmer checks the return value from snprintf.
> > >> Always.
> > >>
> > >
> > >Really? I never do. But I make sure my buffers are the right size for
> > >the job - or that it doesn't matter if there is truncation (such as for
> > >log outputs). I prefer to be sure that my inputs to the function are
> > >correct, than to call the function and check for problems afterwards.
> > >(Different people can have different requirements here - but that's the
> > >way I do it.)
> > >
> > I often use snprintf in place of strcat. For that purpose, checking the return
> > value is required.
> >
> >
> > char buffer[1024];
> > char *bp = buffer;
> > size_t remaining = sizeof(buffer);
> > int diag;
> >
> > diag = snprintf(bp, remaining, "%s", string_to_append_to_buffer);
> > if (diag != -1 && diag < remaining) {
> > bp += diag, remaining -= diag;
> > } else {
> > /* Handle overflow/error as necessary */
> > }
> >
> > ....
> >
> > The only problem is that the return value for snprintf is 'int', while
> > the buffer size is size_t; which means on systems with a 64-bit size_t,
> > the return value isn't large enough to express the correct return value
> > when the size of the result value exceeds 4GB. Not generally a problem in
> > actual code, but something to be aware of.
> And there is a warning when we compare the result of snprintf (int)
> against sizeof that returns size_t.
>
> I put cast and this is very annoying.
>
> char buffer[10];
> if (snprintf(buffer, sizeof(buffer), "%s", psz) >= (int)sizeof(buffer)) {
> //error
> }
>
> Actually sizeof returning size_t requires more casts in other places
> of my code.
>
size_t is a nuisance. The justification for it is that sizes of things in memory
may exceed the range of an int. But it turns into a bulldozer. Every count,
every index variable, as well as sizes of things in bytes, become touched by
size_t.

On 19/11/2021 02:22, Siri Cruise wrote:
> In article <sn6jgl$val$1@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>
>> It is not a matter of a system not having "malloc" and a heap - it is a
>> matter of deciding not to use it. In small systems with limited ram and
>
> So you cut off your hand and now you want to be told how to
> fashion a hook. Got it. Good luck.
>

Eh, no. You haven't got it at all. Small systems embedded programming
is a different world from PC programming - the requirements are
different, the hardware is different, the rules are different. We don't
write code with error handlers that log problems and send debug data
back to the developers - we write code that may have to run for /years/
without a glitch.

(I'm not suggesting embedded programmers don't make mistakes - merely
that it is common to impose restrictions and coding standards to reduce
the risk of errors or their consequences.)

On 19/11/2021 10:46, Malcolm McLean wrote:
> On Friday, 19 November 2021 at 01:22:36 UTC, Siri Cruise wrote:
>> In article <sn6jgl$val$1...@dont-email.me>,
>> David Brown <david...@hesbynett.no> wrote:
>>
>>> It is not a matter of a system not having "malloc" and a heap - it is a
>>> matter of deciding not to use it. In small systems with limited ram and
>> So you cut off your hand and now you want to be told how to
>> fashion a hook. Got it. Good luck.
>>
> David Brown probably didn't take the decision himself not to use malloc.

Note that I am not the OP here - I merely work with a similar kind of
programming as the OP.

> Dynamic memory is often banned, by over-all coding requirements that
> are decided upon by senior mangement or customers.
>
> The question then is what to do when you have a string whose length isn't
> known at compile time.
>

The answer for small-systems embedded programming is to change the
question - make sure you /do/ know the length of the string. Or rather,
know the maximum length you will have to handle, make sure you /can/
handle that length, and make sure that any external input is limited to
that length.

In article <sn8j86$ejj$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:

> >> It is not a matter of a system not having "malloc" and a heap - it is a
> >> matter of deciding not to use it. In small systems with limited ram and
> >
> > So you cut off your hand and now you want to be told how to
> > fashion a hook. Got it. Good luck.
> >
>
> Eh, no. You haven't got it at all. Small systems embedded programming

Yes, I do. If you want to allocate variable sized data, then you
have to allocate variable size data. Blank comman was set up to
do that on machines for more primitive than anything you got.
Blank common got whatever was left in memory after all the code,
initialised data, and overlay buffers were loaded.

The alternative to things like blank common is constant bound
arrays which are expected to be larger than anything that will be
used. That way instead of one large chunk of memory that can be
reused, you scatter the unused memory throughout the data where
it cannot be reused.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

On 19/11/2021 18:00, Siri Cruise wrote:
> In article <sn8j86$ejj$1@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>
>>>> It is not a matter of a system not having "malloc" and a heap - it is a
>>>> matter of deciding not to use it. In small systems with limited ram and
>>>
>>> So you cut off your hand and now you want to be told how to
>>> fashion a hook. Got it. Good luck.
>>>
>>
>> Eh, no. You haven't got it at all. Small systems embedded programming
>
> Yes, I do.

No, you don't get it. This has nothing to do with what /can/ be done
regarding memory - it has to do with what /should/ be done, or not done,
in order to be entirely sure that the program will work and continue to
work, without risk of failures. It doesn't matter that a modern
microcontroller can have more memory than early PC's, never mind earlier
computers. We are not talking about restrictions due to limited hardware.

(Oh, and I can almost guarantee that I have worked with more limited
hardware than you. The smallest device I used had no ram at all -
merely the processor registers and IIRC 32 bytes of eeprom, along with
1K flash for code memory. But again, we are not talking about
limitations due to small memory sizes.)

> If you want to allocate variable sized data, then you
> have to allocate variable size data. Blank comman was set up to
> do that on machines for more primitive than anything you got.
> Blank common got whatever was left in memory after all the code,
> initialised data, and overlay buffers were loaded.
>
> The alternative to things like blank common is constant bound
> arrays which are expected to be larger than anything that will be
> used. That way instead of one large chunk of memory that can be
> reused, you scatter the unused memory throughout the data where
> it cannot be reused.
>

Le 19/11/2021 à 18:00, Siri Cruise a écrit :
> The alternative to things like blank common is constant bound
> arrays which are expected to be larger than anything that will be
> used. That way instead of one large chunk of memory that can be
> reused, you scatter the unused memory throughout the data where
> it cannot be reused.

Memory management is a whole topic in itself and would require hundreds
of pages to be covered decently.

But just to say quickly - small constant reallocations can be much worse
in terms of memory use than a fixe-size allocation used frequently - in
particular in terms of memory fragmentation and execution time.

It's all a very complex, and context-dependent matter.

On 11/19/2021 8:26 AM, David Brown wrote:
> On 19/11/2021 02:22, Siri Cruise wrote:
>> In article <sn6jgl$val$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>> It is not a matter of a system not having "malloc" and a heap - it is a
>>> matter of deciding not to use it. In small systems with limited ram and
>>
>> So you cut off your hand and now you want to be told how to
>> fashion a hook. Got it. Good luck.
>>
>
> Eh, no. You haven't got it at all. Small systems embedded programming
> is a different world from PC programming - the requirements are
> different, the hardware is different, the rules are different. We don't
> write code with error handlers that log problems and send debug data
> back to the developers - we write code that may have to run for /years/
> without a glitch.
>
> (I'm not suggesting embedded programmers don't make mistakes - merely
> that it is common to impose restrictions and coding standards to reduce
> the risk of errors or their consequences.)
>

True. Btw, have you read this:

https://www.stroustrup.com/JSF-AV-rules.pdf

;^o

On Friday, 19 November 2021 at 20:35:11 UTC, Chris M. Thomasson wrote:
> On 11/19/2021 8:26 AM, David Brown wrote:
> > On 19/11/2021 02:22, Siri Cruise wrote:
> >> In article <sn6jgl$val$1...@dont-email.me>,
> >> David Brown <david...@hesbynett.no> wrote:
> >>
> >>> It is not a matter of a system not having "malloc" and a heap - it is a
> >>> matter of deciding not to use it. In small systems with limited ram and
> >>
> >> So you cut off your hand and now you want to be told how to
> >> fashion a hook. Got it. Good luck.
> >>
> >
> > Eh, no. You haven't got it at all. Small systems embedded programming
> > is a different world from PC programming - the requirements are
> > different, the hardware is different, the rules are different. We don't
> > write code with error handlers that log problems and send debug data
> > back to the developers - we write code that may have to run for /years/
> > without a glitch.
> >
> > (I'm not suggesting embedded programmers don't make mistakes - merely
> > that it is common to impose restrictions and coding standards to reduce
> > the risk of errors or their consequences.)
> >
> True. Btw, have you read this:
>
> https://www.stroustrup.com/JSF-AV-rules.pdf
>
Had a quick look. It's a mixture of useful rules and bans on ridiculous practices which
no-one sane would use (e.g. comments embedded in #include file paths).
It would be nice to get the meaningful gist in shorter form.

On 11/19/2021 9:25 AM, David Brown wrote:
> On 19/11/2021 18:00, Siri Cruise wrote:
>> In article <sn8j86$ejj$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>>>> It is not a matter of a system not having "malloc" and a heap - it is a
>>>>> matter of deciding not to use it. In small systems with limited ram and
>>>>
>>>> So you cut off your hand and now you want to be told how to
>>>> fashion a hook. Got it. Good luck.
>>>>
>>>
>>> Eh, no. You haven't got it at all. Small systems embedded programming
>>
>> Yes, I do.
>
> No, you don't get it. This has nothing to do with what /can/ be done
> regarding memory - it has to do with what /should/ be done, or not done,
> in order to be entirely sure that the program will work and continue to
> work, without risk of failures. It doesn't matter that a modern
> microcontroller can have more memory than early PC's, never mind earlier
> computers. We are not talking about restrictions due to limited hardware.
>
> (Oh, and I can almost guarantee that I have worked with more limited
> hardware than you. The smallest device I used had no ram at all -
> merely the processor registers and IIRC 32 bytes of eeprom, along with
> 1K flash for code memory. But again, we are not talking about
> limitations due to small memory sizes.)

Damn. I remember working with an old version of Quadros a long time ago.
No malloc allowed.

[...]

On 19/11/2021 22:44, Malcolm McLean wrote:
> On Friday, 19 November 2021 at 20:35:11 UTC, Chris M. Thomasson wrote:
>> On 11/19/2021 8:26 AM, David Brown wrote:
>>> On 19/11/2021 02:22, Siri Cruise wrote:
>>>> In article <sn6jgl$val$1...@dont-email.me>,
>>>> David Brown <david...@hesbynett.no> wrote:
>>>>
>>>>> It is not a matter of a system not having "malloc" and a heap - it is a
>>>>> matter of deciding not to use it. In small systems with limited ram and
>>>>
>>>> So you cut off your hand and now you want to be told how to
>>>> fashion a hook. Got it. Good luck.
>>>>
>>>
>>> Eh, no. You haven't got it at all. Small systems embedded programming
>>> is a different world from PC programming - the requirements are
>>> different, the hardware is different, the rules are different. We don't
>>> write code with error handlers that log problems and send debug data
>>> back to the developers - we write code that may have to run for /years/
>>> without a glitch.
>>>
>>> (I'm not suggesting embedded programmers don't make mistakes - merely
>>> that it is common to impose restrictions and coding standards to reduce
>>> the risk of errors or their consequences.)
>>>
>> True. Btw, have you read this:
>>
>> https://www.stroustrup.com/JSF-AV-rules.pdf
>>
> Had a quick look. It's a mixture of useful rules and bans on ridiculous practices which
> no-one sane would use (e.g. comments embedded in #include file paths).
> It would be nice to get the meaningful gist in shorter form.
>

These kinds of rule sets are often a mixture. They typically include a
lot of rules that are banning things that are undefined behaviour in C
(or in this case, C++) and shouldn't be used anyway, as well as things
that are so silly that few programmers would have imagined making such
mistakes. And they also often include things that are downright
unhelpful and contrary to writing good, safe code - perhaps in the name
of portability or because some people have poor quality tools. But they
also have lots of good stuff too.

In many ways, such coding standards are important simply because they
are a standard and enforce a consistency, even if the rules are not all
good.

On Saturday, November 20, 2021 at 6:30:55 AM UTC-6, David Brown wrote:
> On 19/11/2021 22:44, Malcolm McLean wrote:
> > On Friday, 19 November 2021 at 20:35:11 UTC, Chris M. Thomasson wrote:
> >> On 11/19/2021 8:26 AM, David Brown wrote:

> >>> (I'm not suggesting embedded programmers don't make mistakes - merely
> >>> that it is common to impose restrictions and coding standards to reduce
> >>> the risk of errors or their consequences.)
> >>>
> >> True. Btw, have you read this:
> >>
> >> https://www.stroustrup.com/JSF-AV-rules.pdf
> >>
> > Had a quick look. It's a mixture of useful rules and bans on ridiculous practices which
> > no-one sane would use (e.g. comments embedded in #include file paths).
> > It would be nice to get the meaningful gist in shorter form.
> >
> These kinds of rule sets are often a mixture. They typically include a
> lot of rules that are banning things that are undefined behaviour in C
> (or in this case, C++) and shouldn't be used anyway, as well as things
> that are so silly that few programmers would have imagined making such
> mistakes. And they also often include things that are downright
> unhelpful and contrary to writing good, safe code - perhaps in the name
> of portability or because some people have poor quality tools. But they
> also have lots of good stuff too.
>
> In many ways, such coding standards are important simply because they
> are a standard and enforce a consistency, even if the rules are not all
> good.

I agree with this. I've had an uneasy relationship to these strictly specified
rules. Even in situations (ok, 1 situation) where I was in charge and got to
write up the coding standard. There's an inherent risk of fossilization or
"false crystallization" (to borrow from Ouspensky) in making these things.
And yet where would we be without them?? Wandering among foreigners,
all speaking jibberjabber in the ruins of Babel? An army of chained
monkeys playing with typewriters? <additional hyperbole>