[U-Boot] RFC: introduce malloc_cleared() ?
Hello,
instead of adding or having the sequence of
malloc(), memset()
in all places where a definitely sane initialized structure is required it would make more sense to introduce a single function doing both. (The standard "calloc()" does not suit well here.) Overall that should even slightly decrease code size.
Reinhard
Dear Reinhard Meyer,
In message 4CB6A110.6080101@emk-elektronik.de you wrote:
instead of adding or having the sequence of
malloc(), memset()
in all places where a definitely sane initialized structure is required it would make more sense to introduce a single function doing both. (The standard "calloc()" does not suit well here.) Overall that should even slightly decrease code size.
And why exactly does calloc() not fit?
Best regards,
Wolfgang Denk
Wolfgang Denk schrieb:
Dear Reinhard Meyer,
In message 4CB6A110.6080101@emk-elektronik.de you wrote:
instead of adding or having the sequence of
malloc(), memset()
in all places where a definitely sane initialized structure is required it would make more sense to introduce a single function doing both. (The standard "calloc()" does not suit well here.) Overall that should even slightly decrease code size.
And why exactly does calloc() not fit?
It has two parameters... Produces more code to always supply an extra "1"...
I am game with using calloc(). That's all.
But for malloc() in such driver init situations, another code saving function with error message would be more effective. I don't see any possible way of continuing u-boot when malloc() for a relatively small structure already fails, and a (apparently) needed driver cannot be initialized.
I am not talking about malloc()'s for buffers or similar where continuing of u-boot might be possible.
Reinhard
Wolfgang Denk schrieb:
Dear Reinhard Meyer,
In message 4CB6A110.6080101@emk-elektronik.de you wrote:
instead of adding or having the sequence of
malloc(), memset()
in all places where a definitely sane initialized structure is required it would make more sense to introduce a single function doing both. (The standard "calloc()" does not suit well here.) Overall that should even slightly decrease code size.
And why exactly does calloc() not fit?
It has two parameters... Produces more code to always supply an extra "1"...
I am game with using calloc(). That's all.
But for malloc() in such driver init situations, another code saving function with error message would be more effective. I don't see any possible way of continuing u-boot when malloc() for a relatively small structure already fails, and a (apparently) needed driver cannot be initialized.
I am not talking about malloc()'s for buffers or similar where
continuing
of u-boot might be possible.
I would borrow the naming from linux and call it mallocz
Jocke
Dear Joakim Tjernlund,
In message OF32166834.809C7D71-ONC12577BC.0031112B-C12577BC.00313F63@transmode.se you wrote:
I would borrow the naming from linux and call it mallocz
... except that Linux does not use any "mallocz" anywhere :-)
I guess you mean [k]zalloc() ?
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote on 2010/10/14 11:38:57:
Dear Joakim Tjernlund,
In message <OF32166834.809C7D71-ONC12577BC.0031112B-C12577BC. 00313F63@transmode.se> you wrote:
I would borrow the naming from linux and call it mallocz
... except that Linux does not use any "mallocz" anywhere :-)
I guess you mean [k]zalloc() ?
Yes, memory played tricks on me :)
On Thursday, October 14, 2010, Reinhard Meyer u-boot@emk-elektronik.de wrote:
Wolfgang Denk schrieb:
Dear Reinhard Meyer,
In message 4CB6A110.6080101@emk-elektronik.de you wrote:
instead of adding or having the sequence of
malloc(), memset()
in all places where a definitely sane initialized structure is required it would make more sense to introduce a single function doing both. (The standard "calloc()" does not suit well here.) Overall that should even slightly decrease code size.
And why exactly does calloc() not fit?
It has two parameters... Produces more code to always supply an extra "1"...
I am game with using calloc(). That's all.
But for malloc() in such driver init situations, another code saving function with error message would be more effective. I don't see any possible way of continuing u-boot when malloc() for a relatively small structure already fails, and a (apparently) needed driver cannot be initialized.
The failed malloc can cause the dailed driver to unload malloc'd memory and print a warning to the console. User intervention (changing environment variables to avoid the out-of-memory on reboot for example) can still be possible even though the driver failed.
I am not talking about malloc()'s for buffers or similar where continuing of u-boot might be possible.
Regards,
Graeme
Dear Reinhard Meyer,
In message 4CB6C3D3.7050403@emk-elektronik.de you wrote:
And why exactly does calloc() not fit?
It has two parameters... Produces more code to always supply an extra "1"...
Ah.
But for malloc() in such driver init situations, another code saving function with error message would be more effective. I don't see any
Would it? You still need to check the return code of the allocation function then, because you want to breeak out of the caller.
possible way of continuing u-boot when malloc() for a relatively small structure already fails, and a (apparently) needed driver cannot be initialized.
Maybe, maybe not. As mentioned before: network access may not be so important at all.
I am not talking about malloc()'s for buffers or similar where continuing of u-boot might be possible.
Continuing U-Boot without network access is also possible. If someone pulls the cable you also continue, or don't you?
Best regards,
Wolfgang Denk
participants (4)
-
Graeme Russ -
Joakim Tjernlund -
Reinhard Meyer -
Wolfgang Denk