Wolfgang Denk wrote:
Adding spaces to the variable value? This makes little sense to me. It's just a waste of storage space and boot time.
Well, I can agree with you, however I have already seen this case...
If you feel your environment is so complicated to read that you want such "formatting", then rather structure your envrionment (see proposals on the list), and/or help improving the printenv capabilities to add sorting etc.
Ok, understood. I will change to support something like
<whitespaces>variable<whitespaces>value
Who says that TAB would not be allowed?
..probably is more stranger as to have spaces....
Of course it is. There is virtually no restriction on the content of the value of a variable. The only character that cannot be part of the value is '\0'.
[Of course it is not a wise decision to add non-printing or control characters, but you can do this, if you like.]
As I saw some leading whitespaces in a variable, I cannot remember a case where I saw a TAB in a variable. But as it is not forbidden, probably there is still this case !
- char dump[128];
Ouch! That's short! Why do we need such an arbitrary limit?
We do not need a small value, but I have to set a value for fgets. A bigger value should be enough, reporting an error if the line is too long.
But your code is not set up to handle the remainder of too long lines. It would be read as the next line and cause confusion.
Ah, ok, I get now the point.
Why do you have to run this in two spearate passes at all - first scan, then process.
Why cannot you process each variable when you read it? The we would not need any array or list at all.
There is a reason, please tell me how good it is ;-)
I thought the code could be used not only as it is, but integrated in an application linking the required object (only one, fw_env.o). An application could internally generate a list of pairs variable/values and needs a function to set them in the u-boot environment. This is the reason of the int fw_setenv_multiple(fw_env_list *list, int count) function. No need to use an external file, no need to call fw_setenv as external process. An application could link fw_env.o and call fw_setenv_multiple().
I agree with you that I can do everything in a single pass if we do not provide such kind of external interface.
Best regards, Stefano Babic