> I think that such limits are useful, but are implementation limits, but
> not limits to the spec.
>
> For instance, there's no reason why a user with a big enough storage
> device can't have a string literal that's several terabytes long, if
> they want to. The format spec should allow that; it should be a valid
> instance of the format.
>
> However, it's also perfectly valid for an implementation to say "Hey, I
> can't read strings more than 256 bytes big and I flat out ignore floats
> and I only have 4KiB of RAM to store anything, because I'm running on a
> 16-bit embedded controller".

Once again we agree but Alaric phrased it better than I did :)

John already clarified elsewhere in the thread that he agrees there
should be no hard limits, just cautionary notes about limits likely to
be had in many implementations. So we all agree on the format.

Personally, I find most advisory notes in specifications to be a bit of
a cargo-cult thing. The first thing is they are often speculation, not
tied to actual implementations (notes on actual existing stuff are
useful). Second, they tend to be tied to the decade they are written in.
We would now caution about 32-bit values; a decade from now we might
perhaps caution about 64-bit values. None of those cautions would be
revelatory to readers since they are standard fare for the decade they
are written in. Thirdly, implementations are written for a particular
language and hardware, so the implementor is going to have the numerical
limits that are easiest in that environment; there is no advice we can
give in the spec that changes that. Saying "please implement 64-bit
values", for example, is not useful since people smart enough to
implement a format have already made their mind about what kind of
integer range they want and we can't give them substantial extra
information in a spec to make that decision. Similarly, someone
interfacing to a microcontroller knows the data range of that hardware
and makes decisions based on that. I don't think there is any blanket
advice that is useful. Reading about advisory limits on a
general-purpose format, I would think "given that warnings like this are
usually spurious, is there something I'm missing?". So it just adds more
text and cognitive load. (In all fairness, the same could be said for
much of the email I send.)