The extension name is wrongly sanitized

[kabasset]

Hi,

I think I found a bug, and associated fix ;-)

As of today, it is possible to create an extension named A.B (which is valid), but the name is parsed as A_B at read-time (which is wrong).

In PyFITSObject_get_hdu_info the extname variable -- which I think holds the value of the EXTNAME keyword -- is sanitized by convert_keyword_to_allowed_ascii.

This function converts everything which is not a letter or digit or - to _. Yet, it seems to me that all ASCII characters are valid as keyword values, like the dot, and the function should only be applied to keyword names. Or did I completely miss something?

Hope it helps!

[esheldon]

I think this was implemented to deal with problem headers.

I'd be happy to change this to just converting non-ascii values. That function is only used for this purpose now, it is no longer used for sanitizing keywords, so it won't break anything.

So basically change the logic to check if cval < 0 || cval > 127

[grizonnetm]

Hi,

we're using the fitsio in the frame of the Euclid ground segment and we're affected by this issue due extension name.

We've implemented for now a temporary patch to circumvent the issue but it will be easier for us to rely on a released version of fitsio which fix this issue. We're using the fitsio package available via conda.

Have you scheduled a release (1.1.7) which includes this patch?

In any case, thanks a lot for all the work you're doing maintaining the fitsio package.

Cheers,

[esheldon]

I will release 1.1.7 today

[esheldon]

done, and uploaded to pypi. Will show up on conda forge later today