On Fri, Jan 13, 2017 at 6:36 PM, Bill O'Donnell <billodo@xxxxxxxxxx> wrote:
> On Wed, Dec 07, 2016 at 02:27:23PM +0100, Jan Tulak wrote:
>> Trying to cover all possible values in a single data type is impossible,
>> so convert the field from long long type to union. This requires
>> also some small changes in supporting code, otherwise it would not compile.
>>
>> Signed-off-by: Jan Tulak <jtulak@xxxxxxxxxx>
>> ---
>> mkfs/xfs_mkfs.c | 812 +++++++++++++++++++++++++++++++++++---------------------
>> 1 file changed, 504 insertions(+), 308 deletions(-)
>>
>> diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
>> index 7ffe8ff..afc63d1 100644
>> --- a/mkfs/xfs_mkfs.c
>> +++ b/mkfs/xfs_mkfs.c
>> @@ -121,6 +121,231 @@ unsigned int sectorsize;
>> #define M_RMAPBT 3
>> #define M_REFLINK 4
>>
>> [snip]
>>
>> @@ -576,13 +831,15 @@ struct opt_params {
>> },
>> .subopt_params = {
>> { .index = L_AGNUM,
>> + /* FIXME custom type xfs_agnumber_t? */
>
> Does something really need to be fixed here?
>
Maybe: xfs_agnumber_t is defined as __uint32_t, while the code there
is using unsigned int. Which could possibly cause some issues if a
compiler would not treat int as 32 bits. Though we have a lot of other
custom/generic types mismatches around in the code, and it seems
unlikely that GCC or Clang would ever change how big int is... so
perhaps we can let it be. Or maybe let's change the definition of the
union so instead of unsigned int it is __uint32_t?
--
Jan Tulak
jtulak@xxxxxxxxxx / jan@xxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
