linux-kernel - Re: [PATCH v3 2/4] staging: exfat: drop duplicate date_time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 8 Sep 2019 19:50:31 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Valentin Vidic <vvidic@...entin-vidic.from.hr>
Cc:     devel@...verdev.osuosl.org,
        Valdis Kletnieks <valdis.kletnieks@...edu>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/4] staging: exfat: drop duplicate date_time_t struct

On Sun, Sep 08, 2019 at 05:35:37PM +0000, Valentin Vidic wrote:
> Use timestamp_t for everything and cleanup duplicate code.

Wait, how are these "duplicate"?  The fields are in different order,
don't these refer to things on-disk?

Did you test this?

> -struct date_time_t {
> -	u16      Year;
> -	u16      Month;
> -	u16      Day;
> -	u16      Hour;
> -	u16      Minute;
> -	u16      Second;
> -	u16      MilliSecond;
> -};
> -
>  struct part_info_t {
>  	u32      Offset;    /* start sector number of the partition */
>  	u32      Size;      /* in sectors */
> @@ -289,6 +279,16 @@ struct file_id_t {
>  	u32      hint_last_clu;
>  };
>  
> +struct timestamp_t {
> +	u16      millisec;   /* 0 ~ 999              */
> +	u16      sec;        /* 0 ~ 59               */
> +	u16      min;        /* 0 ~ 59               */
> +	u16      hour;       /* 0 ~ 23               */
> +	u16      day;        /* 1 ~ 31               */
> +	u16      mon;        /* 1 ~ 12               */
> +	u16      year;       /* 0 ~ 127 (since 1980) */
> +};

They really look "backwards" to me, how are these the same?  What am I
missing?

thanks,

greg k-h