Re: [EXT] Initialization of "vbuf" in function "token_match_attr"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08.09.20 16:03, Amit anand wrote:
Hi,

On Tue, Sep 8, 2020 at 6:23 PM Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote:
Hi!

vbuf is initialized: It has some address on the stack, so "if (value != vbuf)" is comparing adresses, if I got it right...
vbuf having some address on stack and "if(value!=vbuf)" is comparing addresses doesn't necessarily implies that vbuf is initialized.
I am still not clear about where vbuf is initialized.

It is initialized with the strscpy() call.

The comparison just compares the pointer in *value (+) with the ADDRESS of "vbuf"!

(+) Please ignore my previous remark. I don't know what I had been smoking at that time!

So if "value" does not point at "vbuf", it points at some other buffer, but the data in that buffer should be in "vbuf", so the contents of the buffer "value" points at is copied into the buffer named "vbuf"!

If "value" points at "vbuf", the call to "sd_device_get_sysattr_value" would have  already put the data into "vbuf" and thus the strscpy() would not be needed, as it would copy "vbuf" into itself.

HTH,

Josef

Also, expecting some information regarding my queries in below mail.

Thanks,
Amit

>>> Amit anand <amit.table@xxxxxxxxx> schrieb am 08.09.2020 um 13:56 in Nachricht
<CAMkFpM5NFmN+pc_cztmMZW=j1vn2RYC16AgJ3LYL6RSgdqP1eA@xxxxxxxxxxxxxx>:
> Hi systemd-devel team,
>
> I am trying to understand where "vbuf" is initialized in function
> "token_match_attr()" in file udev-rules.c
>
> Below code snippet :
> static bool* token_match_attr*(UdevRuleToken *token, sd_device *dev,
> UdevEvent *event) {
>  *char* nbuf[UTIL_NAME_SIZE], *vbuf*[UTIL_NAME_SIZE];     // Here, vbuf is
> defined, however not initialized.
> *const char* *name, **value;        *// Here, value is declared to be of
> type const char *, however, not initialized.
> ...
> ... // some code
> ...
> switch (token->attr_subst_type) {   // *Event 1* : This evaluates to
> SUBST_TYPE_PLAIN
> ...
> case *SUBST_TYPE_PLAIN*:   if (sd_device_get_sysattr_value(dev, name,
> &value) < 0)   // *Event 2* :The if condition evaluates to false.
>                                                  return false;
>  break;
> ...// some code
> ...
> }
>
>         if (token->attr_match_remove_trailing_whitespace) {      // *Event
> 4*: If condition evaluates to true
>                 if (value != vbuf) {      //  *Event 5* : vbuf and value
> are both declared but not initialized. Comparison is done without
> initializing "vbuf" and "value".
>                         strscpy(vbuf, sizeof(vbuf), value);
>                         value = vbuf;
>                 } // End of if.
>
>                 delete_trailing_chars(vbuf, NULL);         // *Event 6*:
> trying to delete trailing chars from "vbuf" which is not initialzed. ??
>         } // End of outer if.
> ... // some code
> } /End of function : *token_match_attr()*
>
> Below are my queries :
> 1. *Event 5 *above, we are comparing two resources ("value" and "vbuf")
> even before initializing them.
>     Are we doing this comparision to do decision making based on whether
> the pointer type variable "value" is pointing to "vbuf" or not.
> *Query*: Kindly confirm whether my understanding is correct.
>
> 2. *Event 6* above, delete_trailing_chars(vbuf, NULL) is called outside  *if
> (value != vbuf).*
>     This implies there may occur a situation where:
>               step 1 ) *if (value != vbuf) *condition fails  --> step 2 )
> *vbuf* is not initialzed inside the *if(value != vbuf)  *--> step 3 )
> delete_trailing_chars(*vbuf*, NULL).
> Here, delete_trailing_chars() called for "*vbuf*" which is not necessarily
> initiazlied.
> *Query*: Kindly let me know if my understanding is correct or I am missing
> something.
>
> Thanks,
> Amit





_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux