Fortran client for the public CEP API http://git.cep.is/fortran/atom?h=main 2026-07-27T23:38:46Z 2026-07-27T23:38:46Z Murilo Ijanc murilo@ijanc.org 2026-07-27T23:38:46Z urn:sha1:3506a69f15fdf1c1c80acec26e906e6f25eeff14 A CEP that fails is rarely a random number. It is usually someone who knows the city and guessed the digits, and the classic guess is the -000 that 957 municipalities never received. Answering that with a bare "not found" throws away what the API already knows: which municipality the number would have fallen under. The 404 now carries an optional faixa, and it is exposed the way geo already is — a derived type behind a logical flag on the address, because the API omits the block entirely rather than sending null. It stays a 404: found is still false and the status is still CEPIS_ERR_NOT_FOUND. The band is context for the failure, never an address. cep_ini and cep_fim are the smallest and largest CEP that actually exist there, not the bounds the Correios publish — the published start for Areal is 25845000, exactly the CEP that fails. The pair is not a list either: 118 CEPs over some 4,900 numbers, which is what ceps is for. Parsing is deliberately silent about every failure. A body that is not JSON, or a faixa that is absent, null, not an object or empty, leaves has_faixa false. Turning any of those into an invalid-response error would tell the caller to retry a CEP that will never exist. 2026-07-26T17:15:37Z Murilo Ijanc murilo@ijanc.org 2026-07-26T17:15:37Z urn:sha1:ef1e5586a47002a6f21f43871b5fcfdb2c60af5d The caveat lived only in the cepis_http module header. Anyone porting this to another platform reads the README, not the source of the transport module — and on an ABI that passes variadic arguments on the stack the binding fails by corrupting the option value, not by refusing to compile. 2026-07-26T15:52:43Z Murilo Ijanc murilo@ijanc.org 2026-07-26T15:52:43Z urn:sha1:42d8c12d2bd88462df8c3aac9449abbf98400084