bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6555: stat enhancement


From: A Burgie
Subject: bug#6555: stat enhancement
Date: Tue, 6 Jul 2010 12:18:16 -0600

Is there any documentation on doing this the right (meaning, GNU) way?
 I've separated out find_mount_point() into a separate .c file,
created a .h file, put both in ./gnulib/lib and linked-to them from
lib, included the .h file in stat.c and df.c, but cannot compile
(w/make).  I believe I still need to modify a makefile to include the
findmountpoint.c file somewhere but have never worked w/make except as
an end user (./configure && make && make install).  Also I do not know
that I am using the correct directories (./gnulib/lib) for my new .c
and .h files.  My current error makes me think I'm missing something
else that's probably obvious:

make[4]: Entering directory `/home/aburgemeister/code/coreutils/lib'
  GEN    configmake.h
make[4]: Leaving directory `/home/aburgemeister/code/coreutils/lib'
make[3]: Leaving directory `/home/aburgemeister/code/coreutils/lib'
make[2]: Leaving directory `/home/aburgemeister/code/coreutils/lib'
Making all in src
make[2]: Entering directory `/home/aburgemeister/code/coreutils/src'
  GEN    fs.h
make  all-am
make[3]: Entering directory `/home/aburgemeister/code/coreutils/src'
  CC     stat.o
stat.c: In function 'print_stat':
stat.c:686:7: error: a label can only be part of a statement and a
declaration is not a statement
stat.c: At top level:
../lib/findmountpoint.h:28:1: warning: 'find_mount_point' used but never defined
make[3]: *** [stat.o] Error 1
make[3]: Leaving directory `/home/aburgemeister/code/coreutils/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/aburgemeister/code/coreutils/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/aburgemeister/code/coreutils'
make: *** [all] Error 2


Thanks,
AB

On Mon, Jul 5, 2010 at 09:53, A Burgie <address@hidden> wrote:
> Nevermind.... I understand your reasoning now to allow the failure to
> propagate out.
>
> On Mon, Jul 5, 2010 at 09:52, A Burgie <address@hidden> wrote:
>> On Mon, Jul 5, 2010 at 09:41, Jim Meyering <address@hidden> wrote:
>>> Jim Meyering wrote:
>>>> I'll push these two change-sets shortly.
>>>>
>>>> Subject: [PATCH 1/2] system.h: define ATTRIBUTE_WARN_UNUSED_RESULT
>>> ...
>>>> +/* The warn_unused_result attribute appeared first in gcc-3.4.0 */
>>>> +#undef ATTRIBUTE_WARN_UNUSED_RESULT
>>>> +#if __GNUC__ < 3 || (__GNUC__ == 3 && __GNUC_MINOR__ < 4)
>>>> +# define ATTRIBUTE_WARN_UNUSED_RESULT __attribute__ 
>>>> ((__warn_unused_result__))
>>>> +#else
>>>> +# define ATTRIBUTE_WARN_UNUSED_RESULT /* empty */
>>>> +#endif
>>>
>>> Just noticed I reversed the if/else branches above.
>>> This works a lot better:
>>>
>>> commit 61aae73f5427c987b20604fbec5772e02edc0f74
>>> Author: Jim Meyering <address@hidden>
>>> Date:   Mon Jul 5 17:16:23 2010 +0200
>>>
>>>    system.h: define ATTRIBUTE_WARN_UNUSED_RESULT
>>>
>>>    * src/system.h (ATTRIBUTE_WARN_UNUSED_RESULT): Define.
>>>
>>> diff --git a/src/system.h b/src/system.h
>>> index 859b663..9e14681 100644
>>> --- a/src/system.h
>>> +++ b/src/system.h
>>> @@ -483,6 +483,14 @@ enum
>>>  # define ATTRIBUTE_UNUSED __attribute__ ((__unused__))
>>>  #endif
>>>
>>> +/* The warn_unused_result attribute appeared first in gcc-3.4.0 */
>>> +#undef ATTRIBUTE_WARN_UNUSED_RESULT
>>> +#if __GNUC__ < 3 || (__GNUC__ == 3 && __GNUC_MINOR__ < 4)
>>> +# define ATTRIBUTE_WARN_UNUSED_RESULT /* empty */
>>> +#else
>>> +# define ATTRIBUTE_WARN_UNUSED_RESULT __attribute__ 
>>> ((__warn_unused_result__))
>>> +#endif
>>> +
>>>  #if defined strdupa
>>>  # define ASSIGN_STRDUPA(DEST, S)               \
>>>   do { DEST = strdupa (S); } while (0)
>>>
>>
>> Just to make sure I understand why something else was invalid, I
>> wrapped the print statement with an if that basically had the same
>> logic as df.c (mp=find_mount_point....; if(mp){print....})
>>
>> That, to me, seemed valid, though it would not print anything at all
>> if find_mount_point returned a null.  I suppose it would be preferred
>> for the question-mark result which is perhaps what your version is
>> doing.  Anyway, just thought I'd throw that out there.
>>
>> Sent in the e-mail for the legal side of things; waiting to hear back from 
>> them.
>>
>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]