[Info-vax] C99 stuff (Re: The Road to V9.0)

[Stephen Hoffman]

On 2019-06-07 15:10:08 +0000, John Reagan said:

> On Friday, June 7, 2019 at 10:26:42 AM UTC-4, Stephen Hoffman wrote:
>> On 2019-06-06 23:44:44 +0000, Steven Schweda said:
>> 
>>>> 
>>>> [...] I get tired of dragging around my own home-grown versions of stdint.h
>>> 
>>> I know the feeling.  Is there any chance of a C macro in some place 
>>> like <inttypes.h> or <[decc$]types.h> (or somewhere) which would reveal 
>>> the existence of <stdint.h> at compile time?  Or will some __DECC_VER 
>>> value be the clue?
>> 
>> I'd hope it'd be the expected __STDC_VERSION__ >= 199901L for this 
>> check, but that ship may well have already sailed.
>> 
>> The compiler itself has been C99 since the ~millennium.
>> 
>> It's been the RTL and the headers that have lagged C99.
>> 
>> And as I've suggested before, I'd prefer to make the folks that don't 
>> want to update their code have to take some minor steps—setting some 
>> system parameter, tweaking a compiler CLD, defining some logical name 
>> (gag), whatever other LTS-enable scheme—to re-establish the old 
>> defaults for the old and unmodified compilations, and leave the 
>> defaults to be the most current compiler support available.  Drag this 
>> old mess forward best speed, and don't make those of us that are 
>> maintaining and updating our code pay extra and forever, versus not 
>> making the folks that aren't maintaining and updating pay even a little 
>> bit just once.
> 
> This isn't just "define a few new symbols/macros" that can be guarded 
> (at least without making the headers even uglier).  <inttypes.h> comes 
> with C99 as does <stdint.h>.  Any inclusion of <inttypes.h> (at least 
> to me) is the confirmation that you want the C99 names added to your 
> namespace.  We just didn't do all of them in the past.  We do now.  
> Don't want C99 names?  Don't include C99 headers.  No different than 
> any Linux box.  Putting "-ansi" on gcc doesn't keep you from shooting 
> yourself in the foot with an include of <inttypes.h> or <stdint.h>.

So long as it's C99 and works like C99 and has C99 functions and 
headers and I don't have to drag along my existing baggage to make the 
environment more C99-ish, that's fine.

I can and do expect to have to hack out my existing C99-ish baggage.

But I don't want to have to special-case builds for new development to 
select C99.  Or similarly, to eventually special-case to select C11 or 
C18.  __STDC_VERSION__ >= 199901L or whatever, and off I go.

For the folks that need to stay on C89/C90 and for whatever reason, 
provide a way to allow the compiler invocation to select that, if there 
are to be source or build-incompatible changes.

Make the folks that want/need compatibility do some work, rather than 
foisting that complexity off on the rest of us that are updating.

Make the defaults the most current.  Not the oldest and the roughest.

I'd prefer y'all deprecate the existing rats-nest of headers too, and 
force a migration to modern headers.  Keep the old headers around 
somewhere and for a while and maybe the old RTL if that too gets 
trashed, and let folks modify their environments to use those.  Prolly 
with the arrival of x86-64 and Clang, there.

Default to the most current C available.



-- 
Pure Personal Opinion | HoffmanLabs LLC