On 06/04/2011 10:05, Steffen Dettmer wrote:
On Tue, Apr 5, 2011 at 5:44 PM,<richardcavell@xxxxxxxx> 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
