11–20 of 30 posts
if (scanf("%9lu",&len) 999999999 bytes is bad */ if (getchar() != ':') barf(); buf = malloc(len + 1); /* malloc(0) is not portable */ if (!buf) barf(); if (fread(buf,1,len,stdin) Ah, the wonders of error-handling in C. Also, I wonder what's wrong with buf = malloc(len ? len : 1);
Seems like a coherent, sensible proposal, as one might expect from djb. Any notable protocols use them?
Especially since it only grows with the log of the thing it bounds. So, we could easily have s fixed length length field that covers all ever possible length values.
I’ve done plenty of wire protocol work, and length prefixed strings are great to work with. I’ve also been lucky that those strings were typically contained within a broader payload. To that end, I’ve not had to think about the case of many strings one after another.
I don't like formats that look like text buy may actually contain binary data - that's only going to tempt implementations that will choke when the string actually contains arbitrary data. Would be safer to encode the length and/or separator as something more obviously binary, which will also make the thing easier to parse in low-level implementations.
https://people.csail.mit.edu/rivest/pubs/RL96.ver-1.0.pdf
He has it as a hexadecimal length preceded by a pound sign (#), a colon, and the raw octet data.
This is very similar to a notation occuring in Ronald Rivest's S-Expression proposal from 1996. https://people.csail.mit.edu/rivest/pubs/RL96.ver-1.0.pdf He has it as a hexadecimal length preceded by a pound sign (#), a colon, and the raw octet data.
if (scanf("%9lu",&len) 999999999 bytes is bad */ if (getchar() != ':') barf(); buf = malloc(len + 1); /* malloc(0) is not portable */ if (!buf) barf(); if (fread(buf,1,len,stdin) Ah, the wonders of error-handling in C. Also, I wonder what's wrong with buf = malloc(len ? len : 1);
if (len == 0)
return null_buffer_singleton; /* special shared representation for 0: */Making the thing that describes the bounds of an arbitrary length thing itself arbitrary length sound like an unnecessarily risky complication to me. Especially since it only grows with the log of the thing it bounds. So, we could easily have s fixed length length field that covers all ever possible length values.
In other words, values beyond that are not forbidden by the spec, but are outside of the conformance requirements. It is a quality of implementation issue whether a given implementation handles more than required.