-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mqtt rust keywords 4863 v3 #11430
Mqtt rust keywords 4863 v3 #11430
Conversation
THashInitConfig may not allocate array and increase memuse. Such a failure leads to THashShutdown which should not decrease the memuse. Ticket: 7135
So that MQTTTypeCode::CONNECT does not become c_o_n_n_e_c_t
As needed for MQTTTypeCode which accepts both CONNECT uppercase and unassigned lowercase
for easier later matching
Ticket: 4863 On the way, convert some keywords to use the first-class integer support. And imports in pure rust the support for multi-buffer.
There was a typo that version 3 was tested twice
as is done for other keywords
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #11430 +/- ##
==========================================
- Coverage 82.44% 82.41% -0.03%
==========================================
Files 938 922 -16
Lines 248086 247933 -153
==========================================
- Hits 204534 204343 -191
- Misses 43552 43590 +38
Flags with carried forward coverage won't be shown. Click here to find out more. |
Information: QA ran without warnings. Pipeline 21374 |
@@ -105,6 +105,44 @@ extern { | |||
) -> *mut c_void; | |||
} | |||
|
|||
// needed for calls to DetectAppLayerMultiRegister | |||
pub const SIG_FLAG_TOSERVER: u32 = 0x80000; // BIT_U32(19) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is an accident waiting to happen, can we get to a single place to define it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing the need for it in rust, by using a helper function as for regular single buffers
pub unsafe extern "C" fn rs_mqtt_tx_get_connect_clientid( | ||
tx: &MQTTTransaction, buffer: *mut *const u8, buffer_len: *mut u32, | ||
) -> u8 { | ||
unsafe extern "C" fn mqtt_tx_get_connect_clientid( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
style: function naming
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jasonish how do I prevent this function from being exported in headers ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, they are not exported.
Victor, how should I name these internal rust functions ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cf
warning: function `SCMqttGetConnectClientId` should have a snake case name
--> src/mqtt/detect.rs:56:22
|
56 | unsafe extern "C" fn SCMqttGetConnectClientId(
| ^^^^^^^^^^^^^^^^^^^^^^^^ help: convert the identifier to snake case: `scmqtt_get_connect_client_id`
|
= note: `#[warn(non_snake_case)]` on by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are they unsafe extern "C"
if not exported?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because they are callbacks, called from C
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes them exported, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, if only used via function pointer from the same file, they are not exported. No need to follow C naming conventions as they do not live in that name space. pub extern
is when you enter the C name space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, thanks for the explanation. So for these we can use the rust style then, agree?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, thanks for the explanation. So for these we can use the rust style then, agree?
Yes, and so does clippy.. If pub extern it doesn't complain about style, but if just extern C it will. It also means you can avoid the stutter, name it like a pure rust function instead of long prefixes if you like.
pub unsafe extern "C" fn rs_mqtt_tx_get_subscribe_topic( | ||
tx: &MQTTTransaction, i: u32, buf: *mut *const u8, len: *mut u32, | ||
) -> u8 { | ||
static mut UNSUB_TOPIC_MATCH_LIMIT: isize = 100; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why all these all uppercase? Can just be styled like regular globals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
warning: static variable Limit
should have an upper case name
--> src/mqtt/detect.rs:263:12
|
263 | static mut Limit: isize = 100;
| ^^^^^ help: convert the identifier to upper case: LIMIT
|
= note: #[warn(non_upper_case_globals)]
on by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm I see. I don't really like that all uppercase has a very different meaning in our C code (constant / macro) and that we're starting to mix these things too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jasonish some thoughts here ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally I'm in favor of the style promoted by the language as it just makes things easier for everyone IMO.
It's not really a warning I'd want to suppress globally. If it was a constant we'd probably want it upper case.
* \retval 1 on success | ||
* \retval 0 on failure | ||
*/ | ||
static int MQTTProtocolVersionTestParse01(void) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these could all be SV tests, it seems
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why ?
This is just signatures parsing.
It could rather be unit tests of the parsing function, which is just the generic integer one already tested...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, the keyword is already tested in SV with mqtt-pub-rules and mqtt-unsub-rules
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the tests only test that the rules parse w/o error, nothing internal is checked. So it's not really unittesting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the intent was the parsing of the keyword parameters... Proposing something in next version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work. Some comments inline. Function naming comment applies to much of the PR.
Continued in #11467 |
Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/4683
Describe changes:
SV_BRANCH=OISF/suricata-verify#1920
#11374 with needed rebase
@satta approved last version 👍