[U-Boot] [PATCH v2 1/3] Add limits.h to hold basic limits

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Le 21/10/2011 23:12, Simon Glass a ?crit :
> Hi Albert,
>
> On Fri, Oct 21, 2011 at 2:00 PM, Albert ARIBAUD
> <albert.u.boot@aribaud.net>  wrote:
>> Le 21/10/2011 22:19, Simon Glass a ?crit :
>>>
>>> Hi Albert,
>>>
>>> On Fri, Oct 21, 2011 at 12:54 PM, Albert ARIBAUD
>>> <albert.u.boot@aribaud.net>    wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> Le 10/10/2011 21:22, Simon Glass a ?crit :
>>>>>
>>>>> This brings a basic limits.h implementation into U-Boot.
>>>>>
>>>>> Signed-off-by: Simon Glass<sjg@chromium.org>
>>>>> ---
>>>>>   fs/ubifs/ubifs.h |    4 +---
>>>>>   include/limits.h |   40 ++++++++++++++++++++++++++++++++++++++++
>>>>>   2 files changed, 41 insertions(+), 3 deletions(-)
>>>>>   create mode 100644 include/limits.h
>>>>
>>>> Apparently, in all the U-Boot codebase, only one file required standard
>>>> limit names, and gets them with three lines of code. Is it worth adding
>>>> 40
>>>> lines of code for this?
>>>
>>> Well 2/3 is the license header - and I thought it best to add all the
>>> limits in one go. I can add just those few if you like.
>>>
>>> This file is used later in the patch series.
>>
>> I don't see much use of these in the subsequent patches either -- and those
>> few uses could be discussed, such as for instance the use of INT_MAX as the
>> maximum buffer size for some *printf() functions -- actually, anything very
>> big would fit just as well, would it not?
>
> Yes it would, it's doesn't really need to be INT_MAX. Then again,
> limits.h is a fairly standard file to have around, and INT_MAX is an
> efficient 'large' value to load on many architectures.
>
> In any case it seems wrong to me that ubifs is defining its own
> INT_MAX and U-Boot doesn't have one.

My point is precisely that as standard as limits.h is, U-Boot has 
managed to survive not having it around so far, which kind of shows 
limits.h is not needed.

> Regards,
> Simon

Amicalement,
-- 
Albert.