Hi,
I have been wondering whether it makes sense to add a small utility trying
to make typecasts in C as type-safe as possible.
The problem is that typecasts are sometimes unavoidable. For an example,
let's take a look at the following snippet using Gnulib's xlist module:
struct foo
{
int bar
On 4/6/21 4:24 AM, Paul Eggert wrote:
> grep -Fvf file2 file1
I started with that, too, but it is problematic because:
a) it doesn't do a whole-word search ... and 'grep -w' seems not to be portable,
b) it doesn't limit the matching on the key field.
And messing with regular expressions seems to b
On 4/6/21 2:40 AM, Bernhard Voelker wrote:
grep -Fvf file2 file1
I started with that, too, but it is problematic because:
a) it doesn't do a whole-word search ... and 'grep -w' seems not to be portable,
b) it doesn't limit the matching on the key field.
And messing with regular expressions seems
On 4/6/21 12:18 AM, Marc Nieper-Wißkirchen wrote:
So what I have in mind are macros that do a type conversion from A to B and
that signal an error on modern compilers if the input is not of type A. For
this, the C11 construct _Generic can be used.
Not sure it's worth the aggravation. Most of th
On 4/5/21 11:48 PM, Marc Nieper-Wißkirchen wrote:
SIZE_MAX < (uintmax_t) nbytes
Eeuuw! That's a cure worse than the disease. Among other things, there
is no guarantee that PTRDIFF_MAX <= UINTMAX_MAX so in theory the
comparison could go completely awry with a sufficiently-large NBYTES.
"Don'
Hi Paul,
thanks!
By the way, the snippet you gave is not portable C code, as it assumes
> that 'void *' and 'struct foo *' have the same machine representation.
> This is not necessarily true on (admittedly now-rare) machines that have
> different flavors of pointers. I suspect the main problem h
On 4/6/21 12:13 PM, Marc Nieper-Wißkirchen wrote:
gl_list_iterator_next has to return two things: An element (represented by
a const void *) and a boolean value. As elements may be NULL
Ah, OK, then that's the problem. The API shouldn't allow null elements.
They're not that useful anyway. If t
Am Di., 6. Apr. 2021 um 21:05 Uhr schrieb Paul Eggert :
> On 4/5/21 11:48 PM, Marc Nieper-Wißkirchen wrote:
> > SIZE_MAX < (uintmax_t) nbytes
>
> Eeuuw! That's a cure worse than the disease. Among other things, there
> is no guarantee that PTRDIFF_MAX <= UINTMAX_MAX so in theory the
> comparison c
On Tue, Apr 6, 2021 at 12:18 AM Marc Nieper-Wißkirchen
wrote:
> I have been wondering whether it makes sense to add a small utility trying to
> make typecasts in C as type-safe as possible.
I've found a few macros for casts useful over years. PSPP uses
CONST_CAST and UP_CAST from the file below
CCing Bruno because of his involvement with the Gnulib list modules.
Disallowing NULL list elements could break existing code that actually uses
them but returning elements with type void * instead of const void * would
be much less incompatible. Code can trivially be ported to such an updated
int
Ben Pfaff wrote:
> I've found a few macros for casts useful over years. PSPP uses
> CONST_CAST and UP_CAST from the file below quite a bit:
> https://git.savannah.gnu.org/cgit/pspp.git/tree/src/libpspp/cast.h
Other projects may want to use these macros as well.
That would make a great contribution
On 4/6/21 12:23 PM, Marc Nieper-Wißkirchen wrote:
Where is the flaw in my reasoning?
Oh, you're right; any nonnegative signed integer value will fit into
uintmax_t. (Perhaps this wasn't always true in older standards, but it's
true of the recent C standard.)
So that cast should work. Still,
Paul Eggert wrote:
> > gl_list_iterator_next has to return two things: An element (represented by
> > a const void *) and a boolean value. As elements may be NULL
>
> Ah, OK, then that's the problem. The API shouldn't allow null elements.
> They're not that useful anyway.
I disagree very much wi
On 4/6/21 1:28 PM, Bruno Haible wrote:
But when designing a general utility, for all kinds of programs to use,
it is inappropriate to say "storing null elements is not useful".
I'm afraid we'll have to disagree here. But then I don't use the API so
my comments aren't all that important.
Hi Ben,
> I've found a few macros for casts useful over years. PSPP uses
> CONST_CAST and UP_CAST from the file below quite a bit:
> https://git.savannah.gnu.org/cgit/pspp.git/tree/src/libpspp/cast.h
That's pointing to a nice solution to the problem that casts don't warn in C.
I use to write code
> > But when designing a general utility, for all kinds of programs to use,
> > it is inappropriate to say "storing null elements is not useful".
>
> I'm afraid we'll have to disagree here.
In some of my uses of the gl_list module, the element is in fact a small
integer, cast to an 'uintptr_t' an
Paul Eggert wrote:
> Yes, 'awk' is the way to go if you want more 'join' capability (not just
> treating the entire line as the key). But if the data are not large and
> each key takes up the whole line, 'grep' should work fine.
The data is large, unfortunately. The two input files contain lists
Marc Nieper-Wißkirchen wrote:
> gl_list_iterator_t i = gl_list_iterator (list);
> struct foo *elt;
> while (gl_list_iterator_next (&i, (const void **) &elt, NULL))
> ++elt->bar;
This cast is dangerous: It silences the warning "passing argument 2 of
'gl_list_iterator_next' from incompatible poin
Am Di., 6. Apr. 2021 um 23:04 Uhr schrieb Bruno Haible :
> > > But when designing a general utility, for all kinds of programs to use,
> > > it is inappropriate to say "storing null elements is not useful".
> >
> > I'm afraid we'll have to disagree here.
>
> In some of my uses of the gl_list modul
I wrote:
> So far we have been lacking type-casts that warn for invalid use;
> it is well possible that with the PSPP macros (or with Marc's approach
> of _Generic), we can design a type-safe wrapper around gl_list.h
Here is a simplified test case: The simplest container type is a box type,
that c
* lib/backupfile.c: Include intprops.h.
(numbered_backup): Grow buffer by the usual 50%, not 100%.
This is easier to do now that we have xalloc_count_t.
* modules/backup-rename, modules/backupfile: Depend on intprops.
---
ChangeLog | 6 ++
lib/backupfile.c | 6 --
modules/
* lib/group-member.c: Include intprops.h.
(get_group_info): Use INT_MULTIPLY_WRAPV instead of
xalloc_oversized (which does a multiplication) followed by the
same multiplication. The code was OK as-is; this is just
conceptual simplification, possible now that we have xalloc_count_t.
* modules/group
* lib/xalloc-oversized.h (__xalloc_oversized, xalloc_oversized):
* lib/xmalloca.h (nmalloca):
Comment re restrictions on arg types.
* lib/xalloc-oversized.h (xalloc_count_t): Rename from
__xalloc_count_type; all uses changed. This publicizes the type.
---
ChangeLog | 9 +
li
On POSIX systems the GNU make jobserver is implemented as a pipe,
and these two unexpected descriptors make test-execute-child fail.
Workaround this by making all unexpected descriptors cloexec in
test-execute-main so they are not inherited by test-execute-child.
* tests/test-execute-main.c (cloe
24 matches
Mail list logo
