[torstenvl]

I disagree. This is an artificial limitation that severely hampers the library's capabilities. That kind of discipline may be fine for normal linear string-crunching, but it's cumbersome to an asinine degree if your library needs to do any sort of complex ADT manipulation.

[jgtrosh]

It calls to mind Fortran-style function docs which would give a formula to compute the size of a work array for the caller to provide. That really ties the implementation to the header. It was really boring to work with, though it often pushed you to understand what was going on inside.

[pletnes]

This kind of interface was common in fortran 77. I’m guessing you’ve used BLAS/LAPACK? In more modern fortran, it’s not so usual. Also, Fortran is much more high level than C, and how memory is allocated etc is compiler dependent to a much larger degree than for C.

I’d recommend writing a Fortran 95 wrapper which creates work arrays for you if you really need to use such routines.

[enriquto]

Most often you do not need any sort of "complex ADT"; in that case the no-malloc advice is good but harmless.

Sometimes, you can probably do without any "complex ADT"; in that case, the no-malloc advice forces you to find the clean solution without complex ADT, thus it is really great.

In the rare cases when you intrinsically need a complex ADT, then you do it. The advice is a spirit, not an unbreakable constraint. Just like not using goto.

[marssaxman]

It's also necessary if you want to use the library at all in situations where you can't assume that a heap allocator is available.

[stochastic_monk]

If you need aligned memory (e.g., for SIMD operations), it can be better to assume control of allocation.