Manually fix a pidl bug - that field should be an FT_STRING.

No, I don't know why it's making it FT_NONE; it's a bit of a weird data
type, with a string inside a structure.

Change-Id: I27a6d7577ef4a9f4da8ddad2cad97ad097135e90
Reviewed-on: https://code.wireshark.org/review/5685
Reviewed-by: Guy Harris <guy@alum.mit.edu>

diff --git a/epan/dissectors/packet-dcerpc-nspi.c b/epan/dissectors/packet-dcerpc-nspi.c
index 9eaa17a88467b3883ad1f397e5031071def49f4a..297f792a08de4845d1accf590b8a39a06232560b 100644 (file)
--- a/epan/dissectors/packet-dcerpc-nspi.c
+++ b/epan/dissectors/packet-dcerpc-nspi.c
@@ -10769,7 +10769,7 @@ void proto_register_dcerpc_nspi(void)
        { &hf_nspi_SPropValue_CTR_MVszW,
                { "Mvszw", "nspi.SPropValue_CTR.MVszW", FT_NONE, BASE_NONE, NULL, 0, NULL, HFILL }},
        { &hf_nspi_LPSTR_lppszA,
-               { "Lppsza", "nspi.LPSTR.lppszA", FT_NONE, BASE_NONE, NULL, 0, NULL, HFILL }},
+               { "Lppsza", "nspi.LPSTR.lppszA", FT_STRING, BASE_NONE, NULL, 0, NULL, HFILL }},
        { &hf_nspi_SPropValue_CTR_MVszA,
                { "Mvsza", "nspi.SPropValue_CTR.MVszA", FT_NONE, BASE_NONE, NULL, 0, NULL, HFILL }},
        { &hf_nspi_property_type,