Netstrings (1997)(cr.yp.to)
cr.yp.to
Netstrings (1997)
https://cr.yp.to/proto/netstrings.txt
10 comments
Here's a HTML viewer (not mine; use it at your own risk): <https://html-preview.github.io/?url=https://raw.githubuserco...>
if (scanf("%9lu",&len) < 1) barf(); /* >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) < len) barf();
if (getchar() != ',') barf();
buf = malloc(len ? len : 1);Or even:
if (len == 0)
return null_buffer_singleton; /* special shared representation for 0: */Because then the caller needs to treat it differently from non-empty buffers.
No, it doesn't. It calls:
void buffer_free(void *buf)
{
if (buf != null_buffer_singleton)
free(buf);
}...which treats it differently from non-empty buffers :)
But frankly, having a 1-byte buffer, pointer to which can serve as a sentinel value à la NULL (but dereferenceable!), and which you can pass to free() without it being deallocated is indeed rather useful.
But frankly, having a 1-byte buffer, pointer to which can serve as a sentinel value à la NULL (but dereferenceable!), and which you can pass to free() without it being deallocated is indeed rather useful.
this supports up to <1GB. give me an unlimited size implementation, with streaming. thank you for participating in my code golf contest [;
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.
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.
Or you could just have the standard have a "Conformance Limits" section where it says something similar to "Every implementation shall support a length field value of at least 9223372036854775807, with an unlimited number of leading zeros".
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.
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.
That the spec is lenient and the conformance test strict makes ot only worse.
So much of the terse, utilitarian, DJB Way was overpowered by bloated corporate crap 8-/
One still functional example exists in voidlinux's init system.
There was never any need for systemd 8-/
Except leveraging RedHat/IBM's domination of the linux user space ecosystem...
One still functional example exists in voidlinux's init system.
There was never any need for systemd 8-/
Except leveraging RedHat/IBM's domination of the linux user space ecosystem...
I’ve near infinite respect for DJB, so I’m assuming I’ve missed something obvious here. Why is ‘,’ being used as a termination byte. Is it just a backstop? If buf[len+1] != ‘,’ then there’s a line error?
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’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.
For this I made a tlv format, where string is encoded in byte prefixed chunks with length between 0 and 222 for final chunk and between 223 and 255 for intermediate chunks.
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.
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.
Right, in later drafts he changed to decimal with no # prefix:
https://www.ietf.org/archive/id/draft-rivest-sexp-04.html
https://www.ietf.org/archive/id/draft-rivest-sexp-04.html
Seems like a coherent, sensible proposal, as one might expect from djb. Any notable protocols use them?
BitTorrent's bencoding format, used in .torrent files, effectively uses netstrings-- but without the trailing commas, so it uses "5:hello" to represent filenames and similar.
[deleted]
Not sure if it counts as notable, but SCGI uses it too: https://python.ca/scgi/protocol.txt
Php serialized uses
s:size:value;
zurl and mongrel2 are using it.
Another string length O(1) encoding format like Pascal strings that were len (unsigned byte) + data. Limited to 255 characters however.
Dollar, NUL, and other terminated strings, by contrast, are string length O(N).
Dollar, NUL, and other terminated strings, by contrast, are string length O(N).
fast cgi has a good one, length then binary follows, if the length is 127 or less, the length is contained within one byte, if not the length is contained in 4 bytes, then the data follows. Midi has a similar scheme for representing some numbers, the high order bit denotes if there's another byte of the number following or something like that lol
strlen for netstring is O(log n).
(1997) -DJB
Most of the links have bitrotted and I don't think it ever got much traction, but I did always like how simple it was. There's a copy someone grabbed of the original spec here: https://raw.githubusercontent.com/ged/tnetstrings.info/refs/...