![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/8140dda6-9512-4297-ac17-d303638c90a6.png)
Read official docs, then rewrite some small own project in it.
Read official docs, then rewrite some small own project in it.
It’s not a responsibly of the format, so, at most, it’s a mere side effect. In any practical process which could result with truncated data, even if it handles data with such property, it should be wrapped in a container which includes length. At the very least, it would allow to trace the source of truncation, e.g. was the data originally truncated, or was it truncated in the process, and change the format without shooting in oneselves foot. And the generating side should always provide success flag which should be properly handled, since it may produce syntactically correct, but semantically invalid data. Such as checking exit code of process which generates json/yaml in question
You just check the exit code, no? The other process may fail while generating syntactically correct data too, regardless of format.
That’s not a problem of a format and should be handled by transport or storage.
Agreed, and I have more arguments against commit signing.
filter-branch
ed away, again invalidating the signatures.BTW this topic has common considerations with now mandatory (on GH and more places) 2FA. For the latter reason, and also for own convenience and for reducing risk of losing access to your account (which I assess as much higher than risk of leaking my password to third parties) I make second factor public, effectively reverting to 1FA.
Why would you need to flesh it out
it the first place? If you have serious projects I take it you’re not total beginner, so don’t waste time on projects with no purpose.
Neither. A button should show action it performs.