ESP8266 (ESP-07), DHT22, web server - After some time, the page does not display.

sq9etc wrote:

I debugged a piece of code converting time from a uint32_t type variable to a text string, and in this form the program ran for over 3 days.
In the original version, cobbled together from the two I presented on the listing, there was one uncool thing. Namely, the time server was queried as often as the sensor, i.e. every 10 seconds.
I have now changed this so that the synchronisation occurs once a day after midnight according to winter time.

.
Presumably there is some memory leakage in this time format conversion procedure. Now it won't be apparent so soon. What does this conversion function look like at the moment?
Do you check the size of the rudders as I described in the previous post?

khoam wrote:

sq9etc wrote:

I debugged a piece of code converting the time from a uint32_t type variable to a text string, and in this form the program ran for over 3 days.
In the original version, cobbled together from the two I presented on the listing, there was one uncool thing. Namely, the time server was queried as often as the sensor, i.e. every 10 seconds.
I have now changed this so that the synchronisation occurs once a day after midnight according to winter time.

.
Presumably there is some memory leakage in this time format conversion procedure. Now it won't be apparent so soon. What does this conversion function look like at the moment?
Do you check the size of the rudders as I described in the previous post?

.

.
With this conversion but without downloading the time from the server it was fine, as I wrote above.
Leakage tests I have not done so far.

sq9etc wrote:

With this conversion, but without retrieving the time from the server it was fine, as I wrote above.

.
How do you initialise the size of the dateTime buffer into which characters are copied by sprintf()?

khoam wrote:

How do you initialise the size of the dateTime buffer into which the characters are copied by sprintf()?

.
Yes:
.

In the code from post #13 it shows: I understand that you have already changed this and are allocating an appropriately sized buffer for this text string.

khoam wrote:

In the code from post #13 it shows:

Code: C / C++

Log in, to see the code

I understand that you have already changed this and are allocating an appropriately sized buffer for this text string.

.
This was previously the case, but I changed it and it is now as in the post I posted above.

sq9etc wrote:

This was previously the case, but I changed it and it is now as in the post I posted above.

.
This could have been the cause of random reboots or program hangs - sprintf() was writing to memory in random places.

Is this possible with ATOM + PlatformIO + Arduino framework kit for ESP 8266 and the following declarations:
.
That all three variables will point to the same memory area?
I just made this up to have an indication of when the last module restart and the last synchronisation occurred. The code looked good. Seemingly everything is read when needed, but all three variables always had the same value.
I changed the above definitions to the following:
.
and immediately everything started to play.
It looks like some kind of optimisation to me.

sq9etc wrote:

It looks to me like some kind of optimisation.

It looks like this. Since all three text strings are the same I haven't yet encountered a case where pointers are "optimised" in this way.
However, it is better to set the size of the text string buffer using char[size] (an array of characters) to guard against such side effects: char[] can be cast to char*, so and use in sprintf().

In the last code you have pointers and literals. The latter are read-only, and it is, after all, the pointers that point to them. If you tried to perform such an operation in Windows, for example, you would get a memory access violation error. In such a situation you should define an array: And in your case probably better like this: .

LED5W wrote:

In the last code you have pointers and literals. The latter are read-only, and it is, after all, the pointers to them.

char* is a modifiable (mutable) pointer to a modifiable text string.
const char* is a modifiable pointer to a non-modifiable text string.
The author used char*, so he could modify the contents of the string as long as those modifications did not extend beyond the size of the string.
The problem was that the compiler "decided" that since the contents of these strings were identical (at initialisation), so it assigned the same value to the 3 pointers i.e. they pointed to the same area of memory - each could independently modify the same area of memory.

Attempting to compile the code: results in a warning: .

khoam wrote:

char* is a modifiable (mutable) pointer to a modifiable text string.

Exactly. And the author assigned an unmodifiable string there and modified it. That was the problem, not that,

khoam wrote:

[...] that the compiler "decided" that since the contents of these strings were identical (at initialisation), so it assigned the same value to the 3 pointers i.e. they pointed to the same area of memory - each of them could independently modify the same area of memory.

The compiler correctly assumed that these strings would not be modified, because they could not.

LED5W wrote:

The compiler correctly assumed that these strings would not be modified, because they cannot.

.
Since the variable is of type char*, not const char*, the compiler cannot "assume" that the text string pointed to by this pointer cannot be modified. This is like assuming that the elements of an array of characters pointed to by char* or char[] cannot be modified.
https://stackoverflow.com/questions/9834067/difference-between-char-and-const-char

It can and even should. This is essentially the same as .
The compiler reported that the types don't match. You can assign any address to a pointer, but that doesn't mean the compiler will put a variable of the correct type there. That's what the notation with [] is for, to allocate an array, not just a pointer.

khoam wrote:

Since the variable is of type char* and not const char*, the compiler cannot "assume" that the text string pointed to by this pointer cannot be modified.

.
You are wrong. You are thus defining a pointer to a string literal, which in C has type char[]. Modifying a literal, via such a pointer is an undefined operation in C and is wrong. As col. @LED5W wrote, the compiler has every right to concatenate (albeit not necessarily) the same literals. Interestingly, an operation of this type without explicit casting in C++11 is already an error. The operation char change[] = "literals" copies a literal into an array, each time generating a new copy of the text literal. In this case, such an operation should be used.

tmf wrote:

This is how you define a pointer to a string literal, which in C has type char[]. Modifying a literal, via such a pointer, is an undefined operation in C and is wrong.

.
Where did I write that such a modification of a literal is correct? A text string (a string of characters) is not necessarily the same as a literal (an unmodifiable string - a string constant).

tmf wrote:

the compiler has every right to concatenate (albeit not necessarily) the same literals.

.
Exactly what I wrote about in post #39.

tmf wrote:

Interestingly, an operation of this type without explicit casting in C++11 is already an error.

.
With explicit casting it is also a bug i.e. const char* should not be cast to char* - this is dangerous and can end up with a program crash. It is also worth reading what the difference between const in C and C++ is.

tmf wrote:

The operation char change[] = "literal" copies a literal into an array, each time generating a new copy of the text literal. In this case, such an operation should be used.

.
There is no need to do this, just reserve an array of the appropriate size - I wrote about this in also post #39. In the rest of the Author's program, it is sprintf() that takes care of constructing the text string using this array.

I was hoping that colleague @tmf would respond to the following bit of code from colleague @LED5W , which is complete nonsense, instead of assuming in advance that "I am wrong":

LED5W wrote:

This is basically the same as

Code: C / C++

Log in, to see the code

.

.

khoam wrote:

I was hoping that colleague @tmf would respond to the following bit of code from colleague @LED5W, which is complete nonsense, rather than assuming in advance that "I am wrong":

.
I was hoping that a colleague would explain why he thinks something is "nonsense" instead of using epithets.
As for the rest:

khoam wrote:

Since the variable is of type char*, not const char*, the compiler cannot "assume" that the text string pointed to by this pointer cannot be modified. This is like assuming that the elements of an array of characters pointed to by char* or char[] cannot be modified.

.
Here you are wrong and I don't know what you want to argue with. The compiler can assume that a text literal defined as char *txt="ffff" is unmodifiable, or it can concatenate the same literals. Your second sentence is an unauthorised argument - defining char tzt[]="fff", results in the literals being copied into an array, in effect this is where the compiler cannot assume unmodifiability. By means of a pointer to an array defined in this way, it is of course modifiable.

tmf wrote:

I was hoping that a colleague, rather than using epithets, would explain why he thinks something is "nonsense".

const char[] c;

tmf wrote:

There you are wrong and I don't know what you want to argue with.

.
I have no intention of polemicising. A colleague has already established for himself and much better than me what I have written, so the discussion is pointless.

tmf wrote:

Your second sentence is an unauthorised argument

.
and a moment later

tmf wrote:

By a pointer to an array defined in this way, of course it can be modified.

Which also applied to my "second sentence".

But if you can't see the difference between char *txt="dddd", and {char txt[]="ssss"; char *ptxt=txt;} then what else is there to say. In the first case, modification by txt leads to undefined behaviour - most commonly, in the case of MCUs where literals are in FLASH to an error. In the second case, modification by ptxt is as correct as possible.

tmf wrote:

But if you can't see the difference between char *txt="dddd", and {char txt[]="ssss"; char *ptxt=txt;} then what else is there to say.

.
I treat this as a heebie-jeebies and a personal attack. I don't know where such conclusions come from, certainly not from the discussion in this thread.

khoam wrote:

tmf wrote:

I was hoping that a colleague, rather than using epithets, would explain why he thinks something is "nonsense".

const char[] c;

At first I wanted to write in the comment that c is of type const char[] , then I moved it and such a wrong expression came out. Correcting myself:
The key is (and was in the previous code) the second line. It is not exactly the same as assigning a literal to a pointer, but it also allows you to modify a value that should be immutable.

@LED5W Here you have a mistake - if you have the definition const char c[] = "literal";, such a literal cannot be modified via a pointer. This leads to an undefined operation - on ARM there will be an exception, on other MCUs nothing meaningful. On older AVR families this will work, because this literal will be copied to SRAM, but on newer ones it won't, because it will be in FLASH. Without this const it would be ok.

tmf wrote:

This is where you are wrong - if you have a definition const char c[] = "literal";, then such a literal cannot be modified via a pointer.

I am not modifying a literal but an array, which is why I wrote that it is not exactly the same. I used the array to be stored type to make visible what I wrote about in #42 , which is precisely that modifying a literal is a mistake.