Frr: LDPD build fails on maybe-uninitialized rt

[qlyoung]

make  check-am
make[1]: Entering directory '/home/vagrant/frr/ldpd'
  CC       ldp_vty_exec.o
ldp_vty_exec.c: In function ‘show_lib_detail_msg_json.isra.20’:
ldp_vty_exec.c:1226:7: error: ‘rt’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
       log_label(rt->remote_label));
       ^
ldp_vty_exec.c: In function ‘show_lib_detail_msg.isra.21’:
ldp_vty_exec.c:1095:3: error: ‘rt’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
   snprintf(rcvd_buffer + buflen, LDPBUFSIZ - buflen,
   ^
cc1: all warnings being treated as errors

This breaks builds with -Werror.

Presumably due to a switch statement with an empty default:

1049 static int
1050 show_lib_detail_msg(struct vty *vty, struct imsg *imsg, struct show_params *params)
1051 {
1052         struct ctl_rt   *rt;
1053         char             dstnet[BUFSIZ];
1054         static int       upstream, downstream;
1055         size_t           buflen;
1056         static char      sent_buffer[LDPBUFSIZ];
1057         static char      rcvd_buffer[LDPBUFSIZ];
1058
1059         switch (imsg->hdr.type) {
1060         case IMSG_CTL_SHOW_LIB_BEGIN:
1061         case IMSG_CTL_SHOW_LIB_SENT:
1062         case IMSG_CTL_SHOW_LIB_RCVD:
1063         case IMSG_CTL_SHOW_LIB_END:
1064                 rt = imsg->data;
1065                 if (params->family != AF_UNSPEC && params->family != rt->af)
1066                         return (0);
1067                 break;
1068         default:
1069                 break;
1070         }

[rwestphal]

Thanks for the report. It's a rather silly warning because there's no way 'rt' can be used uninitialized in those functions. Initializing 'rt' to NULL in both functions should fix the warning.

I'll open a new PR for ldpd tomorrow which will include a patch for this. If you need to get this fixed before that please let me know.

[qlyoung]

I agree it's silly. On the other hand someone might come along in the future and accidentally make this soft warning into a hard failure. And yep, initializing to null is a workaround. Just opened an issue 'cause you know your code better than I do, figured it's better for you to fix it so I don't screw something up 😉

[rwestphal]

Agreed, even the harmless warnings should be fixed. Will close this once #311 is merged. Thanks again Quentin.

[donaldsharp]

Committed with #311