How to use C89 with certain C99 features

[David Brown]

On 06/04/2011 10:05, Steffen Dettmer wrote:
> On Tue, Apr 5, 2011 at 5:44 PM,<richardcavell@mail.com>  wrote:
>>> We have such situations where the platforms w/o vaargs are
>>> "small" anyway and the overhead for __FILE__ in the binaries is
>>> bad anyway, so simple solution is to simply on those platforms do
>>> /not/ use file and line; two implementations of myfunc: one with
>>
>> Well, because it's a Wikipedia bot, it's entirely foreseeable that the
>> program will encounter an error through no fault of its own (Internet
>> connection goes down, Wikipedia servers lag, unusual activity on Wikipedia
>> results in rare unhandled error, etc).  Error conditions have to be
>> reported, and __FILE__ is a part of that.
>
> So it seems suited to run it on a system supporting a compiler
> with vaargs.
>
> Yes, failure conditions have to be reported, but I disagree
> that __FILE__ is part of a failure message, because the user
> should not be expected to read the sources to understand a
> message (also, a source code identifier, such as a unique version
> number, is additionally needed in this case).
> Why not include __FUNCTION__, __func__ or __PRETTY_FUNCTION__, if
> avialable? I think usually very helpful (if avialable) but also
> not portable (to C89), AFAIK.
>
> BTW, interesting to read this argument in C language context
> (usually it comes from Java people [and some
> InternalUnknownErrorException, thrown in File.open() in
> File.java:12345] and I have the impression that often it is used
> only as excuse for not writing meaningful, well-thought-out and
> carefully written messages. SCNR.).
>
>>> {
>>>    struct timeval t = { 0 };
>>>    t.tv_sec = seconds;
>>> }
>>
>> Okay, but what about if I have const members?
>
> You cannot have const members with runtime data.
> As I understand it, the "small old" compilers may locate
> const data into ROM (or other RO memory), which makes it
> impossible to initialize it with runtime data, so again the
> problem may not be the compiler language / version, but
> properties of the equipment. If you want your code to be runable
> on such systems, you cannot use it.
>
> Is this right? I hope someone on the list corrects me?
>

Well, as an embedded developer I wouldn't say "small old" compilers 
allocate const data to ROM - I'd say many compilers targeting systems 
with ROM or flash will try to put const data in ROM or flash.  That 
includes gcc for such targets - hardly a "small" or "old" compiler!

C rules do not specify that "const" data /must/ go in unmodifyable 
memory - it can be put in ram, and it can be generated at run-time.  But 
once created, the const data cannot be modified (or rather, any attempts 
at modification are undefined).  So you /can/ create a local structure 
with const parts that are initialised, and which you later cannot change 
- just as the OP wants.  And you cannot set up such structures in the 
C89 fashion.

So this case /is/ something that you can do with C99, but not with C89.

The big questions are whether it is a good idea in the first place, and 
if it is worth doing.

Your other suggestions have given the OP a way to let people take 
advantage of C99 if they have it, but let the code compile with C89 if 
necessary.  Using const in structures like this makes the code C89 
incompatible - and it doesn't really add much benefit (though it's 
always nice to use const where you can).

Since it is always legal to cast to const (but not to cast away const), 
it is possible to define two structs - one with all the const in place, 
and one without (const in the pointed-to part of members is fine).  Make 
your local structure of the non-const type, using C89-style 
initialisation.  Then cast it to the const type and use that if you want 
protection from accidentally changing the const data.

> But, as told here by someone else before, it should be checked
> whether the price of less good code is worth the potential
> possibility to run it on exotic platforms. Maybe it is simply not
> needed to be able to run a Wikipedia Web Bot on a microwave oven?
> :)
>
> oki,
>
> Steffen
>