Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Under C89/C90 rules, realloc(ptr, 0) definitely frees the object
> pointed to by ptr (assuming it had been allocated properly). The
> standard doesn't clearly say what realloc() returns in that case.

The C90 standard does say what realloc() returns in that case (of
course whether it says so clearly is a subjective question). The
return value is dictated by the two penultimate sentences in the
general description at the beginning of section 7.10.3, "Memory
management functions":

[...] If the space cannot be allocated, a null pointer is
returned. If the size of the space requested is zero, the
behavior is implementation-defined; the value returned shall
be either a null pointer or a unique pointer. [...]

That description is consistent with the 'Returns' portion of
section 7.10.3.4 "The realloc function", which says:

The realloc function returns either a null pointer or a
pointer to the possibly moved allocated space.

> Common sense suggests that it behaves like malloc(0), so it
> returns either a null pointer or a unique pointer (and the choice
> is implementation-defined, so it must be documented).

I don't think any common sense is needed. There is nothing in the
description under 7.10.3.4 that contradicts the general description
given in 7.10.3, so that specification must be followed.

Incidentally, note that it is always possible for realloc(ptr,0) to
return a non-null value (when ptr is non-null), because if nothing
else the original value of ptr could be returned, to be the 'unique
pointer'. The same is true for any other call to realloc() when
the requested size is less than or equal to the current size.

David Brown <david.brown@hesbynett.no> writes:
> On 11/04/2023 21:50, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> The only real use I have seen for non-prototype function declarations
>>> is a "general" function pointer in arrays containing mixed function
>>> pointer types. Such use is no longer allowed in C23. Is that what
>>> you are concerned about? Normally a better choice of general function
>>> pointer is "void foo(void)", rather than "int foo()". (In C23, the
>>> later would now mean "int foo(void)".)
>> I haven't often had a need for a generic function pointer type (as
>> void*
>> is a generic object pointer type), but I suggest that using a return
>> type that's not used elsewhere might be safer. If you use `void(void)`
>> as a generic function type, there's a risk that a call without a cast
>> will quietly compile.
>
> That would be even better, yes. But would you not want the
> non-existent type to be used for a parameter, rather than the return
> type? (You could use it for both.)

You're right, using the nonexistent type for a parameter would catch
more errors; I didn't think about calls in void context.

For example:

struct DO_NOT_USE { int n; };
typedef void func(struct DO_NOT_USE);

You could use it for the return type too, but I don't think that adds
anything.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On Wednesday, April 12, 2023 at 5:36:03 AM UTC-4, Tim Rentsch wrote:
> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
> > On Tuesday, April 11, 2023 at 10:46:24?PM UTC-4, Tim Rentsch wrote:
> >
> >> James Kuyper <james...@alumni.caltech.edu> writes:
> >
> > ...
> >
> >>> The fundamental problem is that, in C, a typedef is nothing more
> >>> than an synonym for a type. In any context where you use a typedef,
> >>> you could also use the explicit type itself. [...]
> >>
> >> Strictly speaking this assertion isn't quite right. Here is an
> >> example:
> >>
> >> typedef long Elongator( int );
> >>
> >> extern const Elongator *elongator;
> >
> > I'm confused by that declaration - what is the 'const' supposed to
> > mean in that context?
> 'Elongator' is a function type (that maps an int to a long).
>
> 'const Elongator' is a 'const' function type; in other words the
> qualifier 'const' applies to the function type as a whole, not
> just to the return type of the function.

Which is even more meaningless.

> > Normally, I would read that declaration as
> > saying that elongator is an identifier with external linkage, and
> > that (*elongator)(5) returns a "const long", which makes no sense to
> > me.
> If 'elongator' had been declared as follows:
>
> const long (*elongator)( int );
>
> that would give the result you describe. But in effect the
> declaration of 'elongator' is the following (not legal C, but
> meant to show what is taking place):
>
> extern const (long (int)) *elongator;
>
> so the 'const' modifies the function type itself as a whole, and
> not just the return type of the function. The syntax used there
> is not allowed in C, which is why a typedef is needed.

Sorry - I'd misunderstood what you were trying to get at, mainly because
it's so patently absurd. True, the standard imposes no requirements
when the behavior is undefined, so in particular it allows an
implementation to interpret that declaration in that way. But so would
any other construct with undefined behavior, such as division by 0.
There's really no point in discussing code with undefined behavior
beyond identifying that it does have undefined behavior.
..
> >> There is no way to declare the pointer object 'elongator' without
> >> the use of a typedef.
> >> It may be worth noting that using a type qualifier directly on a
> >> function type is explicitly undefined behavior (but not a constraint
> >> violation).
> >
> > gcc shares my confusion about that declaration, referring to
> > precisely that rule:
> > elongator.h:2:25: warning: ISO C forbids qualified
> > function types [-Wpedantic]
> > 2 | extern const Elongator *elongator;
> > | ^~~~~~~~~
> Actually I think gcc is not confused, but has (for some unknown
> reason) chosen to give a confusing error message. In point of
> fact ISO C does not forbid qualified function types, but simply
> says they are undefined behavior.

You are correct - the C standard never forbids any code; it only specifies
what can and cannot be expected of a conforming implementation if it
processes such code. I agree, it would be better if the message had
instead identified the declaration as having undefined behavior.
However, that's not really relevant to my point - gcc correctly identified
this code has having a serious problem, that it described the problem
incorrectly is far less important.

> > That error message disappears if I move the 'const', so that it
> > qualifies elongator, which makes a lot more sense to me:
> > extern Elongator * const elongator;
> >
> > and it accepts, as compatible, the following declaration of the
> > same identifier:
> >
> > extern long(*const elongator)(int);
> Yes, moving 'const' to the other side of the '*' changes the
> meaning of the declaration, just like the two declarations
>
> const int *pci;
> int *const cpi;
>
> have different meanings for the types of the respective items
> being declared.

Agreed - it's just that I thought that you had made a mistake, since the
code you actually wrote had undefined behavior, so I assumed that
you must have meant something else. That you would actually
present such code as if it constituted a meaningful rebuttal to my
claim was so ridiculous I hadn't considered it.

Richard Damon <Richard@Damon-Family.org> writes:

> On 4/4/23 11:10 PM, Opus wrote:
>
>> Le 05/04/2023 at 04:36, Ben Bacarisse a ecrit:
>>
>>> I don't think the code was ever perfectly reasonable, but I took
>>> their point to be simply that it was not undefined as it will
>>> become.
>>
>> Yeah, to be fair, in standard versions before C17, this was a bit of
>> a grey area. While the behavior of realloc (like malloc and calloc)
>> *regarding the new allocation* was clearly implementation-defined,
>> the behavior as to the old object passed as parameter was, at best,
>> implicit.
>>
>> "The realloc function deallocates the old object pointed to
>> by ptr and returns a pointer to a new object that has the
>> size specified by size."
>>
>> The implicit part is that we could assume from the above that
>> whatever the size parameter is, the realloc function starts by
>> deallocating the old object, and what happens after that is
>> implementation-defined if size is 0.
>>
>> C17 makes it more explicit and definitely makes it clear that even
>> the deallocation is implementation-defined in this case. So this
>> was at least known for sure with C17 that the deallocation itself
>> was implementation-defined. Nothing new.
>>
>> But the old phrasing was so unexplicit that it was reasonable not
>> to count on any particular behavior.
>>
>> Reading the article and the point about the cost of the standard,
>> it's not completely clear the author(s) had really read the
>> previous versions very attentively anyway.
>>
>> What it really shows IMO and is backed up by experience is that
>> many, if not most C developers have never read the C std anyway and
>> many assume they know C from their own experience and the behavior
>> of the particular tools they have used.
>>
>> Whether this would change if the standard became a free download
>> remains to be seen. I am skeptical. Drafts are not hard to get
>> ahold of and late drafts are usually close enough to the final
>> text.
>
> The issue is that realloc DOESN'T start by deallocating the old
> buffer, but must allocate the new buffer (possibly just resizing
> the existing buffer in place), and then copying the data if
> needed.
>
> One key point is that if the new allocation failed, then the old
> buffer was guaranteed to still be allocated and was usable, and
> this was indicated by returning a null pointer.
>
> We thus have a conflict in the definition of the API for realloc.
> If a zero size parameter means act like free, then realloc has no
> non-null value it can return to indicate "success", so needs to
> return null, but that means that a null return doesn't mean the
> input pointer is still valid.
>
> Thus the speciification, and code trying hard to conform to that
> specification, needs a lot of words/code to handle the size 0
> final case.

This summary description is somewhere between misleading and wrong.
It implies some things that aren't true, and it glosses over some
aspects that are critical to understanding what actually transpired.

In the original C standard (ANSI C, aka C89), there is no question
that a realloc() call with a size of zero will free() a non-null
argument. It is implementation-defined what value is returned in
such cases: the return value can be a null pointer, or it can be
a "unique pointer", which means a pointer value distinct from any
other pointer value obtained by other means (including specifically
pointer values returned by other calls to malloc(), realloc(), etc).
But the key point is that the original object is always free()'d,
and there is no question or ambiguity about that.

Ten years later, in C99, the description for realloc() changed. The
C99 description says "If memory for the new object cannot be
allocated, the old object is not deallocated and its value is
unchanged," and does not call out a size of zero as a specific case.
A reasonable conjecture is that some implementation was not
following the C89/C90 requirement to free the old space in some
cases where the new size is zero, and rather than sticking to their
guns the ISO C committee changed the rule to accommodate these
non-conforming implementations. (I should add that I have not gone
looking for evidence to support this conjecture. Still it does seem
reasonable as a conjecture.)

But notice something else. The revised wording says "If memory for
the new object cannot be allocated, ...". But whenever the new size
is no larger than the old size, memory for "the new object" always
/can/ be allocated, because if nothing else the original pointer
could be returned unchanged. There is even an explicit statement in
the standard that the pointer to the new object "may have the same
value as a pointer to the old object". Wording in the C99 standard
doesn't allow the possibility that realloc() with a size of zero
could misbehave in the sense that a null pointer could be returned
but the old object was not free()'d (in the as-if sense).

To be fair, presumably this consequence was unintentional. The C17
standard gives a tacit admission of that oversight in the 'Returns'
portion of the realloc() description, changing "or a null pointer if
the new object /could/ not be allocated" to "or a null pointer if
the new object /has/ not been allocated" (emphasis added). Still,
for more than a decade after C99, and years after C11, a reasonable
reading of the C standard could give the impression that realloc()
with a size of zero would never give a "faulty" return value, and
the old pointer value passed to realloc() could safely be forgotten.

> Also, this goes back to the idea that malloc could return unique
> 0-byte allocations as an implementation option (because some chose
> to to that way back when). This is a option that has some uses,
> but also makes some code harder to maintain. And for such a
> system, a call with a 0 size would return a non-null pointer, so
> realloc(ptr, 0) wasn't the equivalent of a free, as it returned a
> pointer that should eventually be actually free'd.

The idea that unique-pointers-for-size-zero makes code harder to
maintain is backwards. Presumably if one knew in advance that the
allocation size is zero either malloc() would not be called or
rather than calling realloc() the code would just call free()
directly. The point is what happens when the size is the result
of a calculation, so we don't know in advance that it will be zero.
In that case what we /want/ in a non-null pointer, pointing to an
object that corresponds to the size requested.

Personally I am not a fan of the "unique pointer" style of malloc()
and realloc(), but it is consistent and from that perspective makes
code easier to maintain, not harder. That is of course assuming no
"faulty" return values for realloc() with a size of zero. The ISO C
committee should have the courage to require realloc() with a size
of zero simply cannot "fail", and always returns a non-null value
on those implementations for which malloc(0) can return a non-null
value. The proposal that realloc() with a size of zero be undefined
behavior is at best remarkably shortsighted.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> cross@spitfire.i.gajendra.net (Dan Cross) writes:

[context: "Catch-23: The New C Standard,Sets the World on Fire"
by Terence Kelly https://queue.acm.org/detail.cfm?id=3588242 ]

>> The authors, bluntly, wrong: the behavior of realloc() when
>> the size argument is 0, the implementation is, as it always
>> has been since C89, implementation defined.
>
> I got the impression they knew that. However, in C89,
> realloc(ptr, 0) must behave like free(ptr). That changed, I
> think, in C99 with the removal of that guarantee. There is
> some evidence that they are little confused about that
> guarantee having been lost, thought of course it is still
> permitted.
[...]
>> The authors tried to make it out like their code was portable
>> and well-defined. It was not.
>
> I did not get that impression. I thought their point was
> simply that the code is not undefined and that being
> implementation defined is safer than being undefined.
>
> I think the code is poor, and I would not want it in any code
> base of mine.

The point of the code is to illustrate a pattern. There are
obvious ways to improve the code for serious development, but
those changes would complicate the presentation without offering
any help to illustrating the pattern.

> It can leak memory (in two different ways) but it does not have
> formally undefined behaviour.

Isn't it the case that whether there are memory leaks depends on
what one takes the interface specification to be? In C90, for
example, doesn't the rule about always free()ing eliminate the
possibility of memory leaks? Is there something I've missed
here? (Note that I am assuming the 'sizeof (int) == 1' problem
is not a factor for this question.)

cross@spitfire.i.gajendra.net (Dan Cross) writes:
> That combined with the little quips about "neurodivergent" ideas

You've put that word in quotes, yet I don't see it in the article.
Has the article changed, or have you just dereferenced a null pointer?

However, oh my, that example code they include is almost comically ugly,
and I'd even go as far as to say unidiomatic for the language:
https://dl.acm.org/cms/attachment/html/10.1145/3588242/assets/html/db9_fig1.png
That's even more hilarious given their later emphasis on use of idioms.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

In article <87leirkotx.fsf@zotaspaz.fatphil.org>,
Phil Carmody <pc+usenet@asdf.org> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> That combined with the little quips about "neurodivergent" ideas
>
>You've put that word in quotes, yet I don't see it in the article.
>Has the article changed, or have you just dereferenced a null pointer?

The text appears to have been changed, and "neurodivergent"
removed. My comment on the DL site quoted the original, if
anyone wants to see what it said:
https://dl.acm.org/doi/10.1145/3588242

It's rather disappointing that they did it with no
acknowledgement, but I'm happy to see it gone.

>However, oh my, that example code they include is almost comically ugly,
>and I'd even go as far as to say unidiomatic for the language:
> https://dl.acm.org/cms/attachment/html/10.1145/3588242/assets/html/db9_fig1.png
>That's even more hilarious given their later emphasis on use of idioms.

Yes, atrocious, isn't it?

The entire argument is a straw-man: the recently discussed
`realloc0` would have made the code perfectly portable and
eliminated the argument entirely.

- Dan C.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

[context]

>> "Catch-23: The New C Standard,Sets the World on Fire"
>> https://queue.acm.org/detail.cfm?id=3588242

> I agree with the authors that the change declaring realloc(..., 0)
> to be undefined is worrying, but I can't follow their reasoning
> about the history. They suggest something had already happened in
> C17 that set C on a course towards this "breaking change" but I
> can't find what they refer to.

After reviewing the paper again, and also consulting the C17
draft (n2176), I believe they meant to refer to this item, in
section 7.31.12, paragraph 2:

Invoking realloc with a size argument equal to zero is an
obsolescent feature.

The change to being obsolescent is mentioned in the paper, along
with a reference to the n2176 draft, in the last sentence of the
second to last paragraph before the "Muddling Through" section.

Phil Carmody <pc+usenet@asdf.org> writes:

[...]

> However, oh my, that example code they include is almost comically
> ugly, and I'd even go as far as to say unidiomatic for the language:
> https://dl.acm.org/cms/attachment/html/
> 10.1145/3588242/assets/html/db9_fig1.png
> That's even more hilarious given their later emphasis on use of
> idioms.

The code in the paper is written not to be an example of production
quality code but to illustrate what the authors are saying about
using realloc(). The code is knowingly simplified to do that. The
paper points out this simplification later on, in point 1 of the
"Drills" section: "Figure 1's stack sacrifices speed for clarity
and brevity", along with a reference to Kernighan and Pike's book
"The Practice of Programming". I suspect lots of people react to
the paper mainly on the basis of their impression of this code,
without understanding why the code is there or what it is meant to
illustrate.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Phil Carmody <pc+usenet@asdf.org> writes:
>
> [...]
>
>> However, oh my, that example code they include is almost comically
>> ugly, and I'd even go as far as to say unidiomatic for the language:
>> https://dl.acm.org/cms/attachment/html/
>> 10.1145/3588242/assets/html/db9_fig1.png
>> That's even more hilarious given their later emphasis on use of
>> idioms.
>
> The code in the paper is written not to be an example of production
> quality code but to illustrate what the authors are saying about
> using realloc(). The code is knowingly simplified to do that.

You've confused simplification with uglification. You've even overlooked
that the freakish ugliness wasn't even consistent.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <87355d576v.fsf@bsb.me.uk>,
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> [snip]
>>> Clearly if push() is called when N == SIZE_MAX (which is possible
>>> only if sizeof (int) == 1) then the code misbehaves. To me this
>>> eventuality is more like an unlikely corner case than it is an
>>> implementation assumption. Granted, the misbehavior can occur
>>> only on some implementations, but the problem is that the code is
>>> wrong, not that it has an implementation dependency. That said,
>>> I see now how this situation fits with what you said earlier
>>> mentioning "a puzzle" (although it still feels like the phrase
>>> "implementation assumptions" is more misdirection than it is
>>> something else).
>>
>> I wouldn't say that the code is wrong. It may never have been
>> written to be portable and there may even be a static assert or
>> some other test that checks the assumptions the programmer made.
>> At least that's how I see it.
>
> It was presented as _idiomatic_ and representative of an
> "exemplary pattern" (the authors words).

I believe you are misunderstanding what is being represented
here. The claim is not that the code in the three function
bodies is idiomatic and exemplary (which the paper itself makes
clear later in the "Drills" section). Rather it is that the
style of use of realloc() is idiomatic and exemplary, which
surely is the case for semantics of realloc() that is under
discussion.

> They put in a tiny hedge by saying it worked for systems
> with "zero-NULL" semantics, but it's clear they thought it
> widely applicable.

Certainly it /was/ applicable for at least the ten years between
the C89 standard and the C99 standard, and probably generally
applicable for at least several years on either side of that
range. As far as the expectations of the user community go,
probably it was perceived as being applicable until some time
between the C11 standard and the C17 standard.

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <86v8i54yk5.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> I think you misunderstood my comment. I didn't mean to say
>> anything about what the authors say about the evolution of
>> realloc(). I meant only that the code they gave works just fine
>> (not counting the problem when 'sizeof (int) == 1' that Ben B
>> pointed out) -- importantly, under the assumptions that the
>> authors explicitly stated -- and that they didn't say anything
>> about whether the code is portable or well-defined if considered
>> outside of those assumptions. The authors may have some opinions
>> about whether the code /should/ work in general, but they don't
>> make any claims about whether it /does/ work in general, and that
>> point is the only one I mean to address.
>
> No, I understood that, but I disagree: I believe that they were
> trying to make a more general statement, beyond simply the
> circumstances they outlined.

Then I think that either you are misreading what they say
or you are seeing something that isn't there. I went back
and thoroughly reviewed the paper, carefully reading each
sentence. In no case did any statement fall outside the
bounds I outlined above.

Phil Carmody <pc+usenet@asdf.org> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Phil Carmody <pc+usenet@asdf.org> writes:
>>
>> [...]
>>
>>> However, oh my, that example code they include is almost comically
>>> ugly, and I'd even go as far as to say unidiomatic for the language:
>>> https://dl.acm.org/cms/attachment/html/
>>> 10.1145/3588242/assets/html/db9_fig1.png
>>> That's even more hilarious given their later emphasis on use of
>>> idioms.
>>
>> The code in the paper is written not to be an example of production
>> quality code but to illustrate what the authors are saying about
>> using realloc(). The code is knowingly simplified to do that.
>
> You've confused simplification with uglification. You've even
> overlooked that the freakish ugliness wasn't even consistent.

I'm stating their view, not my own.

In article <86a5vq1s8y.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <86v8i54yk5.fsf@linuxsc.com>,
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> I think you misunderstood my comment. I didn't mean to say
>>> anything about what the authors say about the evolution of
>>> realloc(). I meant only that the code they gave works just fine
>>> (not counting the problem when 'sizeof (int) == 1' that Ben B
>>> pointed out) -- importantly, under the assumptions that the
>>> authors explicitly stated -- and that they didn't say anything
>>> about whether the code is portable or well-defined if considered
>>> outside of those assumptions. The authors may have some opinions
>>> about whether the code /should/ work in general, but they don't
>>> make any claims about whether it /does/ work in general, and that
>>> point is the only one I mean to address.
>>
>> No, I understood that, but I disagree: I believe that they were
>> trying to make a more general statement, beyond simply the
>> circumstances they outlined.
>
>Then I think that either you are misreading what they say
>or you are seeing something that isn't there. I went back
>and thoroughly reviewed the paper, carefully reading each
>sentence. In no case did any statement fall outside the
>bounds I outlined above.

Maybe I am; truthfully, I haven't given it (the article) much
thought since it came up months ago now.

Let's look at the relevant section of the article (thankfully it
has been edited since initially published to remove some of the
more offensive language: the slur about "neurodivergent ideas"
is gone), with some commentary about where I'm coming from
interspersed:

|The C89 and C99 standards committees strongly recommended that
|allocation interfaces malloc, calloc, and realloc return a null
|pointer in response to zero-byte requests.3,6 This implies that
|realloc(p,0) should unconditionally free(p) and return NULL: No
|new allocation happens in this case, so there's no possibility
|of an allocation failure. For brevity, let "zero-null" denote
|allocator implementations that comply with the C89/C99
|guidance.

Ok. Here the author suggests that the C89 and C99 standards
suggest that `malloc(0)` really ought to return NULL.

|The Swiss-Army-knife aspect of realloc is daunting at first,
|but this interface rewards patient study. Soon you realize that
|zero-null realloc was thoughtfully designed to enable elegant
|dynamic arrays that do exactly the right thing under all
|circumstances, obviating the need for clunky and error-prone
|code to handle grow-from-zero and shrink-to-zero as special
|cases.

This seems specious, at best. Doug McIlroy implemented realloc
and this is the opposite of what he requested when it was
standardized:
https://www.tuhs.org/pipermail/tuhs/2015-September/007452.html

Note that the original author of `realloc` requested that
`realloc(0)` retun something other than NULL. That directly
contradicts the author's suggestion that `realloc` was
"thoughtfully designed to enable elegant dynamic arrays".

Moreover, the `realloc0` function that was discussed here does
not strike me as either "clunky" or "error-prone", and makes the
authors' code well-defined on any implementation. Given their
noxious code style, it's litearlly a one-line fix. Sure, I
suppose it's subjective?

|Figure 1 illustrates idiomatic realloc via a simple stack that
|grows with every push() and shrinks with every pop(). Pointer S
|and counter N (lines 1 and 2) represent the stack: S points to
|an array of N strictly positive ints. Because they are
|statically allocated, initially the pointer is NULL and the
|counter is zero, indicating an empty stack. Function resize
|(lines 4-10) resizes the stack to a given new capacity,
|checking for arithmetic overflow (line 6) before calling
|realloc and checking the return value for memory exhaustion
|(line 8). Allocation failure is inferred when a nonzero new
|size is requested but NULL is returned; zero-null realloc also
|returns NULL when the second argument is zero, but this does
|not indicate an allocation failure because no allocation was
|attempted. (Checking errno doesn't enable portable code to
|detect allocation failure because the C standards don't say
|how out-of-memory affects errno.) Thanks to zero-null realloc's
|versatility, the resize function need not consider whether the
|stack is growing from zero or shrinking to zero or re-sizing in
|some other way; everything Just Works regardless.

This paragraph is the root of my objection; particularly the
first sentence. This code is described as "idiomatic", but
according to whom? Moreover, that sentence doesn't explicitly
mention "zero-null realloc"; they defer discussion of that
until later in the paragraph (if it were me, I'd have prefaced
the entire thing with something like, "For implementations that
provide zero-null semantics, ..."). Critically, they _don't
describe what happens outside of their zero-null semantic
model_. Would replacing the `realloc` call in their code with
the ternary expression discussed earlier in this thread not be
"idiomatic"? Could an argument be made that it is even more
idiomatic to use an `if` statement here to guard against the
`realloc(0)` case?

They go on:

|The code of figure 1 follows a few simple rules implicit in the
|semantics of zero-null realloc. Functions push and pop (lines
|12-23) access the stack only via subscripts on S, because
|realloc may move the array to a different location in memory.
|They never dereference S when N is zero. The resize function
|resists the temptation of reckless S = realloc(S,...), which
|destroys the entry point into the array when allocation fails,
|thereby leaking memory and losing data.

It strikes me that every thing they mention in this paragraph is
equally applicable outside of the zero-null semantic model they
defined.

|I've been seeing code resembling figure 1 for 30 years,
|starting with the work of an older schoolmate who had bothered
|to read the fine manual; the clarity and simplicity of his code
|left a deep impression. In the decades since then I have
|repeatedly found idiomatic realloc in serious production code,
|usually while scanning for p = realloc(p,...) bugs.

What does this mean? What fine manual did the author's
schoolmate read? What does it mean to have used this code (or
something rather like it for 30 years) if not that it was
portable? Were the authors using the same platform the entire
time, with no upgrades? I very much doubt it.

|Imagine, then, my dismay when I learned that C23 declares
|realloc(ptr,0) to be undefined behavior, thereby pulling the
|rug out from under a widespread and exemplary pattern
|deliberately condoned by C89 through C11. So much for stare
|decisis. Compile idiomatic realloc code as C23 and the compiler
|might maul the source in most astonishing ways and your machine
|could ignite at runtime.

"...thereby pulling the rug out from under a widespread and
exemplary pattern deliberately condoned by C89 through C11."
Say what now? This pattern has been implementation defined-
defined, and thus always fraught, for decades now. The scenario
mentioned (upgrading a compiler or library) could blow the code
up with C11, too; granted, the failure case might not be so
dramatic as spontaneous combustion; recompilation or relinking
with an upgraded compiler or library could change to "zero
non-null" semantics and mask allocation failures.

I think a reasonable reader could see the language and use of
words like, "widespread", "exemplary" and "condoned" by earlier
standards, not to mention "idiomatic" and conclude the authors
suggest there is some level of portability to this code that is
not, in fact there. For the record, a reasonable reader could
conclude the opposite, as well; I merely suggest that it is
ambiguous.

When combined with their incorrect statements about the
motivation behind the design of `realloc` and the overall tone
of the article, I'm not giving them the benefit of the doubt.

I did talk to JeanHyde about the motivation, and it sure seemed
reasonable to me: the root issue has caused production failures
in the wild. In other words, code like the authors' "exemplary"
example caused real outages. Everyone agreed that the situation
with regard to making `realloc` UB sucked, but it was the best
of a set of bad options. The people on the committee are not
ignorant fools, after all.

- Dan C.

On Thu, 20 Jul 2023 22:35:33 -0000 (UTC), cross@spitfire.i.gajendra.net
(Dan Cross) wrote in <u9ccrl$i2q$1@reader2.panix.com>:

> (thankfully it has been
> edited since initially published to remove some of the more offensive
> language: the slur about "neurodivergent ideas" is gone)

I can attest to seeing that in one of the
earlier releases of the document.

I wonder if the ACM ever published a post
mortem / mea culpa for any of that...or did they sweep it
under the rug and hope nobody noticed?

I've done a smattering of C programming
since the 90's. I hope they don't ruin the language,
its stability is part of its appeal.

Learned C using "Learn C Now" from Microsoft in the 90's.
This was a C editor and compiler, but you couldn't
save the executables, only run them.

Anyway, many years later, while using gcc, I ran into a
problem: I was using string constants to allocate
string space, and gcc stopped allowing that by default.
"-fwriteable-strings I think is the flag to
allow it, but it got me thinking about safety
in software, and I learned to not be as
foolish with my programming.

So some changes to C are good,
sometimes -- just not sure these kids
can steer nowadays. ;)

--
-v

vallor <vallor@cultnix.org> writes:

> Anyway, many years later, while using gcc, I ran into a
> problem: I was using string constants to allocate
> string space, and gcc stopped allowing that by default.
> "-fwriteable-strings I think is the flag to
> allow it, but it got me thinking about safety
> in software, and I learned to not be as
> foolish with my programming.

Did you know you can write

char writable[] = "this string determines the size and initial value";

?

--
Ben.

vallor <vallor@cultnix.org> writes:
[...]
> Anyway, many years later, while using gcc, I ran into a
> problem: I was using string constants to allocate
> string space, and gcc stopped allowing that by default.
> "-fwriteable-strings I think is the flag to
> allow it, but it got me thinking about safety
> in software, and I learned to not be as
> foolish with my programming.

gcc removed the -fwritable-strings option in 2004. I don't know what
release that change appeared in.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On Sat, 22 Jul 2023 16:28:00 -0700, Keith Thompson
<Keith.S.Thompson+u@gmail.com> wrote in
<87edkzmsqn.fsf@nosuchdomain.example.com>:

> vallor <vallor@cultnix.org> writes:
> [...]
>> Anyway, many years later, while using gcc, I ran into a problem: I was
>> using string constants to allocate string space, and gcc stopped
>> allowing that by default.
>> "-fwriteable-strings I think is the flag to allow it, but it got me
>> thinking about safety in software, and I learned to not be as foolish
>> with my programming.
>
> gcc removed the -fwritable-strings option in 2004. I don't know what
> release that change appeared in.

guess I'm showing my age...started the company in 1994.

--
-v

On Sat, 22 Jul 2023 22:04:17 +0100, Ben Bacarisse <ben.usenet@bsb.me.uk>
wrote in <87wmyrmze6.fsf@bsb.me.uk>:

> vallor <vallor@cultnix.org> writes:
>
>> Anyway, many years later, while using gcc, I ran into a problem: I was
>> using string constants to allocate string space, and gcc stopped
>> allowing that by default.
>> "-fwriteable-strings I think is the flag to allow it, but it got me
>> thinking about safety in software, and I learned to not be as foolish
>> with my programming.
>
> Did you know you can write
>
> char writable[] = "this string determines the size and initial value";
>
> ?

<facepalm> Well, I do now...though I never
even thought to try it, as anything that seems like writing
to an actual string constant appears to
be a 3rd rail to me now...

I wrote a proof-of-concept program to compare behavior
for writing past bounds for strings declared in this way,
strdup()'ed, and malloc()'ed. valgrind segfaults on
it, but it compiles and runs on its own. (Would
be willing to post it with the caveat that its
behavior is undefined.)

--
-v

In article <u9gjin$3pvhi$1@dont-email.me>, vallor <vallor@cultnix.org> wrote:
>On Thu, 20 Jul 2023 22:35:33 -0000 (UTC), cross@spitfire.i.gajendra.net
>(Dan Cross) wrote in <u9ccrl$i2q$1@reader2.panix.com>:
>
>> (thankfully it has been
>> edited since initially published to remove some of the more offensive
>> language: the slur about "neurodivergent ideas" is gone)
>
>I can attest to seeing that in one of the
>earlier releases of the document.
>
>I wonder if the ACM ever published a post
>mortem / mea culpa for any of that...or did they sweep it
>under the rug and hope nobody noticed?

To my knowledge, no; it was just silently removed.

- Dan C.

cross@spitfire.i.gajendra.net (Dan Cross) wrote:

> In article <u9gjin$3pvhi$1@dont-email.me>, vallor <vallor@cultnix.org> wrote:
>> On Thu, 20 Jul 2023 22:35:33 -0000 (UTC), cross@spitfire.i.gajendra.net
>> (Dan Cross) wrote in <u9ccrl$i2q$1@reader2.panix.com>:
>>> [ https://queue.acm.org/detail.cfm?id=3588242 ]
>>> (thankfully it has been edited since initially published to remove
>>> some of the more offensive language: the slur about "neurodivergent
>>> ideas" is gone)
>>
>> I can attest to seeing that in one of the earlier releases of the document.
>>
>> I wonder if the ACM ever published a post mortem / mea culpa for any
>> of that...or did they sweep it under the rug and hope nobody noticed?
>
> To my knowledge, no; it was just silently removed.

Archive.org still has a snapshot from 2023-04-04 with that in it:

As C89 was taking shape, the neurodivergent notion of a
"zero-length object" was making the rounds: Proponents argued
that a non-null pointer to such an object should be returned for
zero-byte allocation requests.

https://web.archive.org/web/20230404195105/https://queue.acm.org/detail.cfm?id=3588242

But the 2023-04-09 version has been edited to remove it:

As C89 was taking shape, the notion of a "zero-length object"
was making the rounds: Proponents argued that a non-null pointer
to such an object should be returned for zero-byte allocation
requests.

https://web.archive.org/web/20230409001708/https://queue.acm.org/detail.cfm?id=3588242

On 2023-07-26, Otto J. Makela <om@iki.fi> wrote:
> cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> In article <u9gjin$3pvhi$1@dont-email.me>, vallor <vallor@cultnix.org> wrote:
>>> On Thu, 20 Jul 2023 22:35:33 -0000 (UTC), cross@spitfire.i.gajendra.net
>>> (Dan Cross) wrote in <u9ccrl$i2q$1@reader2.panix.com>:
>>>> [ https://queue.acm.org/detail.cfm?id=3588242 ]
>>>> (thankfully it has been edited since initially published to remove
>>>> some of the more offensive language: the slur about "neurodivergent
>>>> ideas" is gone)
>>>
>>> I can attest to seeing that in one of the earlier releases of the document.
>>>
>>> I wonder if the ACM ever published a post mortem / mea culpa for any
>>> of that...or did they sweep it under the rug and hope nobody noticed?
>>
>> To my knowledge, no; it was just silently removed.
>
> Archive.org still has a snapshot from 2023-04-04 with that in it:
>
> As C89 was taking shape, the neurodivergent notion of a
> "zero-length object" was making the rounds: Proponents argued
> that a non-null pointer to such an object should be returned for
> zero-byte allocation requests.
>
> https://web.archive.org/web/20230404195105/https://queue.acm.org/detail.cfm?id=3588242
>
> But the 2023-04-09 version has been edited to remove it:

Haha! Who is the neuro? He who can wrap his head around the concept of
zero, or he who struggles with zero length due to a learning disability?

Of course they removed it; ranting against a straightforward concept
that neurotypical grade school children can wrap their heads around made
them look like fools, separately from the remark also being offensive to
some people.

Note that they didn't replace "neurodivergent" with something else like
"puzzing", "odd", "counterintuitive" or any other mild pejorative;
it was just removed.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <86a5vq1s8y.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>
>>> In article <86v8i54yk5.fsf@linuxsc.com>,
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> I think you misunderstood my comment. I didn't mean to say
>>>> anything about what the authors say about the evolution of
>>>> realloc(). I meant only that the code they gave works just fine
>>>> (not counting the problem when 'sizeof (int) == 1' that Ben B
>>>> pointed out) -- importantly, under the assumptions that the
>>>> authors explicitly stated -- and that they didn't say anything
>>>> about whether the code is portable or well-defined if considered
>>>> outside of those assumptions. The authors may have some opinions
>>>> about whether the code /should/ work in general, but they don't
>>>> make any claims about whether it /does/ work in general, and that
>>>> point is the only one I mean to address.
>>>
>>> No, I understood that, but I disagree: I believe that they were
>>> trying to make a more general statement, beyond simply the
>>> circumstances they outlined.
>>
>> Then I think that either you are misreading what they say
>> or you are seeing something that isn't there. I went back
>> and thoroughly reviewed the paper, carefully reading each
>> sentence. In no case did any statement fall outside the
>> bounds I outlined above.
>
> Maybe I am; truthfully, I haven't given it (the article) much
> thought since it came up months ago now.
>
> Let's look at the relevant section of the article (thankfully it
> has been edited since initially published to remove some of the
> more offensive language: the slur about "neurodivergent ideas"
> is gone), with some commentary about where I'm coming from
> interspersed:

I appreciate you making an effort to write a thoughtful reply. I
will try to respond in kind.

> |The C89 and C99 standards committees strongly recommended that
> |allocation interfaces malloc, calloc, and realloc return a null
> |pointer in response to zero-byte requests.3,6 This implies that
> |realloc(p,0) should unconditionally free(p) and return NULL: No
> |new allocation happens in this case, so there's no possibility
> |of an allocation failure. For brevity, let "zero-null" denote
> |allocator implementations that comply with the C89/C99
> |guidance.
>
> Ok. Here the author suggests that the C89 and C99 standards
> suggest that `malloc(0)` really ought to return NULL.

Note that he doesn't say the C89/C99 standards but the standards
committees. The comments he's talking about are given in the C
Rationale documents (and so indicated by the footnote numbers),
which of course were written by committee members. You might
want to take a look at those documents, or at least the later
one, C99 Rationale V5 (dated April 2003); there are five or six
paragraphs talking about this question.

> |The Swiss-Army-knife aspect of realloc is daunting at first,
> |but this interface rewards patient study. Soon you realize that
> |zero-null realloc was thoughtfully designed to enable elegant
> |dynamic arrays that do exactly the right thing under all
> |circumstances, obviating the need for clunky and error-prone
> |code to handle grow-from-zero and shrink-to-zero as special
> |cases.
>
> This seems specious, at best. Doug McIlroy implemented realloc
> and this is the opposite of what he requested when it was
> standardized:
> https://www.tuhs.org/pipermail/tuhs/2015-September/007452.html
>
> Note that the original author of `realloc` requested that
> `realloc(0)` retun something other than NULL. That directly
> contradicts the author's suggestion that `realloc` was
> "thoughtfully designed to enable elegant dynamic arrays".

The paper does not say that. What it does say (with my emphasis
added) is that "_zero-null_ realloc was thoughtfully designed" to
have the mentioned property, which I believe it was. Personally
I find dynamic arrays done using zero-null realloc semantics to
be cleaner than those using McIlroy-style semantics (and also
cleaner than those that have to work with both). The paper does
not make any statement that I can see about the design process
of zero-nonnull realloc; clearly that version of realloc is
considered worse, in the paper's view, than zero-null realloc,
but it doesn't say anything about how that version was designed.

> Moreover, the `realloc0` function that was discussed here does
> not strike me as either "clunky" or "error-prone", and makes the
> authors' code well-defined on any implementation. Given their
> noxious code style, it's litearlly a one-line fix. Sure, I
> suppose it's subjective?

You are offering a different comparison than what he is talking
about. There is no question that having to write an extra
function (whether realloc0 or a similar one) takes more effort
and is more likely to cause error than simply layering on top of
a zero-null realloc (which always does a free and returns null
for a requested size of zero). The sentence you quote is talking
about the zero-null style of realloc, and nothing more than that.

> |Figure 1 illustrates idiomatic realloc via a simple stack that
> |grows with every push() and shrinks with every pop(). Pointer S
> |and counter N (lines 1 and 2) represent the stack: S points to
> |an array of N strictly positive ints. Because they are
> |statically allocated, initially the pointer is NULL and the
> |counter is zero, indicating an empty stack. Function resize
> |(lines 4-10) resizes the stack to a given new capacity,
> |checking for arithmetic overflow (line 6) before calling
> |realloc and checking the return value for memory exhaustion
> |(line 8). Allocation failure is inferred when a nonzero new
> |size is requested but NULL is returned; zero-null realloc also
> |returns NULL when the second argument is zero, but this does
> |not indicate an allocation failure because no allocation was
> |attempted. (Checking errno doesn't enable portable code to
> |detect allocation failure because the C standards don't say
> |how out-of-memory affects errno.) Thanks to zero-null realloc's
> |versatility, the resize function need not consider whether the
> |stack is growing from zero or shrinking to zero or re-sizing in
> |some other way; everything Just Works regardless.
>
> This paragraph is the root of my objection; particularly the
> first sentence. This code is described as "idiomatic", but
> according to whom?

I believe you are misunderstanding the author's intent. He means
the usage of realloc() is idiomatic, not that the example code is
idiomatic. And I think that calling the way realloc() is used
here idiomatic is a fair statement; certainly I expect there
would be no problem finding plenty of examples in existing code
that employ a similar usage.

> Moreover, that sentence doesn't explicitly
> mention "zero-null realloc"; they defer discussion of that
> until later in the paragraph (if it were me, I'd have prefaced
> the entire thing with something like, "For implementations that
> provide zero-null semantics, ...").

I think this suggested re-write changes the meaning. Clearly the
paragraph is making a point about zero-null semantics, but the
code is not meant to be limited to using zero-null realloc.

> Critically, they _don't
> describe what happens outside of their zero-null semantic
> model_. Would replacing the `realloc` call in their code with
> the ternary expression discussed earlier in this thread not be
> "idiomatic"? Could an argument be made that it is even more
> idiomatic to use an `if` statement here to guard against the
> `realloc(0)` case?

The code is there to help make a point a zero-null realloc, so I
think it's fair that it doesn't talk about what happens under a
McIlroy-style realloc. However, the code is written so as to be
usable under both kinds of realloc, so let's look at what the
behavior is under the various C standards. The code always
works without any problems on systems that have a zero-null
malloc and realloc. On systems that have a McIlroy-style
allocator:

Under C89/C90 rules, the code always works without any problems.

Under C99 and C11 rules, the code always works, except that it
can have an undiagnosed memory leak (on some but not all of those
systems) if a resize to zero cannot allocate a new object.

Under C17 rules, there is basically an implementation-defined
choice between C89/C90 rules and C99/C11 rules. So if the choice
is one way the code always works, and if the choice is the other
way an undiagnosed memory leak is possible (depending on the
particular implementation-defined choices made).

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

> On Wednesday, April 12, 2023 at 5:36:03?AM UTC-4, Tim Rentsch wrote:
>
>> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
>>
>>> On Tuesday, April 11, 2023 at 10:46:24?PM UTC-4, Tim Rentsch wrote:
>>>
>>>> James Kuyper <james...@alumni.caltech.edu> writes:
>>>
>>> ...
>>>
>>>>> The fundamental problem is that, in C, a typedef is nothing more
>>>>> than an synonym for a type. In any context where you use a typedef,
>>>>> you could also use the explicit type itself. [...]
>>>>
>>>> Strictly speaking this assertion isn't quite right. Here is an
>>>> example:
>>>>
>>>> typedef long Elongator( int );
>>>>
>>>> extern const Elongator *elongator;
>>>
>>> I'm confused by that declaration - what is the 'const' supposed to
>>> mean in that context?
>>
>> 'Elongator' is a function type (that maps an int to a long).
>>
>> 'const Elongator' is a 'const' function type; in other words the
>> qualifier 'const' applies to the function type as a whole, not
>> just to the return type of the function.
>
> Which is even more meaningless.
>
>>> Normally, I would read that declaration as
>>> saying that elongator is an identifier with external linkage, and
>>> that (*elongator)(5) returns a "const long", which makes no sense to
>>> me.
>>
>> If 'elongator' had been declared as follows:
>>
>> const long (*elongator)( int );
>>
>> that would give the result you describe. But in effect the
>> declaration of 'elongator' is the following (not legal C, but
>> meant to show what is taking place):
>>
>> extern const (long (int)) *elongator;
>>
>> so the 'const' modifies the function type itself as a whole, and
>> not just the return type of the function. The syntax used there
>> is not allowed in C, which is why a typedef is needed.
>
> Sorry - I'd misunderstood what you were trying to get at, mainly because
> it's so patently absurd. True, the standard imposes no requirements
> when the behavior is undefined, so in particular it allows an
> implementation to interpret that declaration in that way. But so would
> any other construct with undefined behavior, such as division by 0.
> There's really no point in discussing code with undefined behavior
> beyond identifying that it does have undefined behavior.
> .
>
>>>> There is no way to declare the pointer object 'elongator' without
>>>> the use of a typedef.
>>>> It may be worth noting that using a type qualifier directly on a
>>>> function type is explicitly undefined behavior (but not a constraint
>>>> violation).
>>>
>>> gcc shares my confusion about that declaration, referring to
>>> precisely that rule:
>>> elongator.h:2:25: warning: ISO C forbids qualified
>>> function types [-Wpedantic]
>>> 2 | extern const Elongator *elongator;
>>> | ^~~~~~~~~
>>
>> Actually I think gcc is not confused, but has (for some unknown
>> reason) chosen to give a confusing error message. In point of
>> fact ISO C does not forbid qualified function types, but simply
>> says they are undefined behavior.
>
> You are correct - the C standard never forbids any code; it only
> specifies what can and cannot be expected of a conforming
> implementation if it processes such code. I agree, it would be
> better if the message had instead identified the declaration as
> having undefined behavior. However, that's not really relevant to
> my point - gcc correctly identified this code has having a serious
> problem, that it described the problem incorrectly is far less
> important.
>
>>> That error message disappears if I move the 'const', so that it
>>> qualifies elongator, which makes a lot more sense to me:
>>> extern Elongator * const elongator;
>>>
>>> and it accepts, as compatible, the following declaration of the
>>> same identifier:
>>>
>>> extern long(*const elongator)(int);
>>
>> Yes, moving 'const' to the other side of the '*' changes the
>> meaning of the declaration, just like the two declarations
>>
>> const int *pci;
>> int *const cpi;
>>
>> have different meanings for the types of the respective items
>> being declared.
>
> Agreed - it's just that I thought that you had made a mistake,
> since the code you actually wrote had undefined behavior, so I
> assumed that you must have meant something else. That you would
> actually present such code as if it constituted a meaningful
> rebuttal to my claim was so ridiculous I hadn't considered it.

I wasn't offering a rebuttal, simply correcting an incorrect
statement. And my comments were meaningful, even if the meaning
is not one you are interested in.

Furthermore there is another, related case that does not have
undefined behavior, and which I had hoped you would be perceptive
enough to discover for yourself. But as usual you were more
concerned with feeling like you were winning the argument than in
discovering what is true.

Am 04.04.2023 um 01:20 schrieb Lynn McGuire:
> "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly
> with Special Guest Borer Yekai Pan
>    https://queue.acm.org/detail.cfm?id=3588242
>
> "The Good News
>
> A new major revision of the C language standard, C23, is due out this
> year. We'll tour the highs and lows of the latest draft9 and then drill
> down on the mother of all breaking changes. Sidebars celebrate C idioms
> and undefined behavior with code and song, respectively."
>
> "Unfilled Potholes and Festering Sores
>
> Laws should be freely available, intelligible, and agreeable to the
> governed, and they should keep pace with changing times. C23 lacks these
> virtues."
>
> Wow.
>
> Lynn

I don't even know why people are still trying
to save C - it can no longer be saved.