C23 reference links
C23 reference links
Posted Jul 24, 2024 14:38 UTC (Wed) by farnz (subscriber, #17727)In reply to: C23 reference links by Wol
Parent article: GNU C Library 2.40 released
UB is defined as "behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements. Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. [Note: permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message)."
"behaving … in a documented manner characteristic of the environment" is the statement that another standard can define things that C leaves as UB, just expressed in ISO standardese.
If you're saying it shouldn't be UB, then it either needs to be implementation-defined behaviour, or unspecified behaviour; but unspecified has the problem that "usually, the range of possible behaviors is delineated by this International Standard".
Posted Jul 24, 2024 14:58 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (5 responses)
That sounds like my DSE. If so, why not say it? Given that realloc (and especially in its form realloc(ptr,0) ) is documented in many places as "well formed code", most of the description of UB does not apply. To declare previously well-formed code as UB is dangerous! To explicitly defer instead to a different standard makes much more sense.
It may still be "here be dragons", but it's tame dragons, not wild ones. And if it requires flags to enable the programmer to specify the behaviour, they are not merely tame, but tamed.
Cheers,
Posted Jul 24, 2024 15:23 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
Because that's how ISO standards work; any standard that is referred to by an ISO standard must be included in the references for that standard. So, to refer to the platform standard from the ISO C standard requires that all the platform standards (including version) that you're referencing are in the reference list for the ISO C standard. This avoids the problem where a standard refers to a document that you can't even identify in order to purchase - if an ISO standard references a document, then a unique identifier for that document at the referenced is present in the references list.
Further, if the dependent standard is updated to a newer version, the reference remains to the older version; you have to issue a new version of the depending standard with updated references to update to the newer standard. Wording like that used by the C standard escapes this, since now the platform standard depends on the C standard, rather than the C standard depending on the platform standard.
Posted Jul 24, 2024 15:29 UTC (Wed)
by khim (subscriber, #9252)
[Link] (3 responses)
No. That's your DSE plus carte blanche to do anything else, too! What would be a lazy implemented doing if one option gives it lots of work and no bonuses and the other one gives less work and faster results on benchmarks, that can be used by marketing team, hmm? Not true. POSIX, in particular, defers to the ISO C standard in that regard. And it incorporates it by reference which means that when C23 would be ratified (expected to happen this year) suddenly, on all POSIX platforms, Neato, isn't it? That's what happens when different people stop talking to each other. P.S. Of course compilers wouldn't start breaking existing programs on the next day after ratification of C23. It would take some time before someone would realise that these programs that call
Posted Jul 24, 2024 21:54 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (2 responses)
> And it incorporates it by reference which means that when C23 would be ratified (expected to happen this year) suddenly, on all POSIX platforms, realloc(ptr,0) would stop being defined.
I thought you said that the original C standard defered to POSIX et al? And that's never been officially changed?
> Neato, isn't it?
It's brilliant :-)
> That's what happens when different people stop talking to each other.
Reality disappearing down the event horizon of a bathtub ...
Cheers,
Posted Jul 24, 2024 22:44 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (1 responses)
In older POSIX standards, the ISO C standard was brought in by reference, and then POSIX imposes requirements on top of ISO C. That's the way round that ISO envisages its standards being used (ISO provide a base, a higher level standard tightens up requirements in ways that work for a specific use case), but POSIX is imposing fewer and fewer requirements on top of ISO over time, which is why this is now a problem.
The ideal case would be for POSIX to impose requirements on realloc that aren't in conflict with ISO; if POSIX said "realloc(ptr, 0); must be the same as free(ptr); return malloc(0);", for example, that would not conflict with C17 or C23, but would tighten up the behaviour and make it defined in a reasonably sane way.
Posted Jul 25, 2024 8:01 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Cheers,
C23 reference links
Wol
C23 reference links
> That sounds like my DSE.
C23 reference links
realloc(ptr,0) would stop being defined.realloc(ptr,0) were always non-portable and since 2024 they are also, formally, broken so why not treat them as non-existing and not optimize well-behaving program (do such programs even exist?) better.C23 reference links
Wol
Relationship between POSIX and C
Relationship between POSIX and C
Wol