alt Hacker NewsNice thing about this one is that we have the implementation details right in the article:
mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g));
Or do you just add it to the list of C crimes, that "passing storage length and pointer" is maybe the worst possible way to return written-to storage from a function :-)
Replies
At first glance I almost misread this as a different C crime, since the declarations aren't in scope... uint8_t dhm_p[2048]; and uint8_t *dhm_p = (...)malloc(2048); both make dhm_p a reasonable pointer to 2k bytes of storage and are totally suitable for that argument, but sizeof the first one is 2048 and sizeof the second one is 4 (or more likely 8 these days, but this is specifically code from an embedded web server so I can say 4 :-)
But no, the actual problem was so much less subtle.
[flagged]
Yeah, this is just C doesn't have fat pointers. Fat pointers were proposed for C89. In some alternate universe C89 has fat pointers and in that universe probably by now many of the weird 0-terminated APIs we're frustrated by work on fat pointers instead and we're all better off for it.
A fat pointer is one ordinary thin pointer, plus a pointer-sized blob of extra information, commonly a length. Examples would be Rust's &[T] slice reference, its &str string reference and a pointer for dynamic dispatch &dyn Shape in which that extra blob is pointing to a v-table of functions for how this particular type implements the Shape trait.