Hi Bruno,
>> Currently, --disable-rpath will add directly $found_so to the compilation
>> line. However, on AIX, this will result on the path being hardcoded in
>> the built binaries.
>> The only way to avoid hardcoded paths without using linker flags (like
>> -Wl,-bnoipath) is to add -l$name.
>
On 2/17/20 4:53 AM, Bruno Haible wrote:
> Paul Eggert wrote:
>> if GCC generated warnings for that sort of thing, the warnings would be false
>> alarms.
>
> Yes, and this in turn means that the ability to produce useful warnings via
> 'restrict' is limited. In this example:
> =
On 2/16/20 3:49 PM, Bruno Haible wrote:
I'm after warnings that point to undefined behaviour, and since passing a
'char *' in place of an 'unsigned char *', 'FILE *', or similar already
generates a compiler warning, using 'restrict' here does not offer an
advantage.
It can still offer an advan
Hi Paul,
> > I'm after warnings that point to undefined behaviour, and since passing a
> > 'char *' in place of an 'unsigned char *', 'FILE *', or similar already
> > generates a compiler warning, using 'restrict' here does not offer an
> > advantage.
>
> It can still offer an advantage, since GC
Hi Tim,
> > Yes, and this in turn means that the ability to produce useful warnings via
> > 'restrict' is limited. In this example:
> > ===
> > #include
> > extern void memmcpy (void *restrict, const void *restrict, size_t);
> >
> >
Thanks to Paul and all for the enlightening discussion about what 'restrict'
actually means.
What I intend to do it gnulib is:
* In the function *definitions*, do not use 'restrict' at all.
Rationale:
- Gnulib code is not time-critical. 'restrict' enables micro-
optimizations
On 2/17/20 12:55 PM, Bruno Haible wrote:
it's pretty rare that people use 'void *' pointers and cast them
to pointers of different types.
It's not rare in some of the code I write. :-) Plus, my example had no casts.
Also, even a small variation of this code does not produce a warning any mor
