search for: int_least32_t

> OK, attempting one more convergence on all this, here's > what I did: > > 1. Reverted back to rev 1.5 of src/libFLAC/ia32/Makefile.am > 2. Applied Matt's last cleanup patch of 8 files. I did not > apply the patch to src/test_unit/main.c since it looks wrong. > main.c is supposed to include the local bitbuffer.h, not > src/libFLAC/private/bitbuffer.h; I think the

...e c_bool from iso_c_binding (Fortran 2003). Fortran compilers store LOGICAL in compiler-dependent ways, and for a long time we got away with assuming that was equivalent to int (so LOGICAL values could be passed to and from with int* on the C/R side). But sometime around GCC 8 they changed to int_least32_t, which on common platforms is the same as int but does not need to be. It seems that in all cases coercion to an integer type coerces false values to 0 and true values to 1 (and this is guaranteed by C23 at least). And C23 guarantees that when coercing from an integer type to bool zero values...

...directory. This generates header files which contain prototypes like int ilaenv_ (int *ispec, char *name, char *opts, int *n1, int *n2, int *n3, int *n4, size_t name_len, size_t opts_len); void dlacn2_ (int *n, double *v, double *x, int *isgn, double *est, int *kase, int *isave); void dlaln2_ (int_least32_t *ltrans, int *na, int *nw, double *smin, double *ca, double *a, int *lda, double *d1, double *d2, double *b, int *ldb, double *wr, double *wi, double *x, int *ldx, double *scale, double *xnorm, int *info); void dlabad_ (double *small, double *large); void drscl_ (int *n, double *sa, double *sx,...

On Sat, May 04, 2019 at 06:42:47PM +0200, Thomas K?nig wrote: > > > - figure out Fortran2003 specification for C/Fortran interoperability > > -- this _sounds_ like the right solution, but I don't think many > > understand how to use it and what is implied (in particular, will > > it require making changes to LAPACK itself?) > > That would actually be fairly

...ry usage and compatibility, "int" was fixed at 32 bits. This meant it was no longer the same size as a pointer, the size of an array index, or the widest native integer type. (Sequence of events simplified for brevity.) The C standard tries to help with a bunch of typedefs: int_fast32_t, int_least32_t, intptr_t, int32_t, size_t, ptrdiff_t, and more. With all these great typedefs, one could imagine that there's no reason anyone should ever use plain "int" ever again. Unfortunately, juggling all these typedefs can be impractical, for several reasons. C doesn't have function over...