Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Martin Uecker <uecker@tugraz.at>]

Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
> 
> On 11/13/22 14:33, Alejandro Colomar wrote:
> > Hi Martin,
> > 
> > On 11/13/22 14:19, Alejandro Colomar wrote:
> > > > But there are not only syntactical problems, because
> > > > also the type of the parameter might become relevant
> > > > and then you can get circular dependencies:
> > > > 
> > > > void foo(char (*a)[sizeof *.b], char (*b)[sizeof *.a]);
> > > 
> > > This seems to be a difficult stone in the road.

But note that GNU forward declarations solve this nicely.

> > > 
> > > > I am not sure what would the best way to fix it. One
> > > > could specifiy that parameters referred to by
> > > > the .identifer syntax must of some integer type and
> > > > that the sub-expression .identifer is always
> > > > converted to a 'size_t'.
> > > 
> > > That makes sense, but then overnight some quite useful thing came to my mind 
> > > that would not be possible with this limitation:
> > > 
> > > 
> > > <https://software.codidact.com/posts/285946>
> > > 
> > > char *
> > > stpecpy(char dst[.end - .dst], char *src, char end[1])
> 
> Heh, I got an off-by-one error.  It should be dst[.end - .dst + 1], of course, 
> and then the result of the whole expression would be 0, which is fine as size_t.
> 
> So, never mind.

.end and .dst would have pointer size though.

> > > {
> > >      for (/* void */; dst <= end; dst++) {
> > >          *dst = *src++;
> > >          if (*dst == '\0')
> > >              return dst;
> > >      }
> > >      /* Truncation detected */
> > >      *end = '\0';
> > > 
> > > #if !defined(NDEBUG)
> > >      /* Consume the rest of the input string. */
> > >      while (*src++) {};
> > > #endif
> > > 
> > >      return end + 1;
> > > }
> > And I forgot to say it:  Default promotions rank high (probably the highest) in 
> > my list of most hated features^Wbugs in C. 

If you replaced them with explicit conversion you then have
to add by hand all the time, I am pretty sure most people
would hate this more. (and it could also hide bugs)

> > I wouldn't convert it to size_t, but 
> > rather follow normal promotion rules.

The point of making it size_t is that you then
do need to know the type of the parameter to make
sense of the expression. If the type matters, then you get
mutual dependencies as in the example above. 

> > Since you can use anything between INTMAX_MIN and UINTMAX_MAX for accessing an 
> > array (which took me some time to understand), I'd also allow the same here. So, 
> > the type of the expression between [] could perfectly be signed or unsigned.
> > 
> > So, you could use size_t for very high indices, or e.g. ptrdiff_t if you want to 
> > allow negative numbers.  In the function above, since dst can be a pointer to 
> > one-past-the-end (it represents a previous truncation; that's why the test 
> > dst<=end), forcing a size_t conversion would disallow that syntax.

Yes, this then does not work.

Martin


> > Cheers,
> > 
> > Alex
> > 
> 
> -- 
> <http://www.alejandro-colomar.es/>